Only commit gap time to awakeSleepDuration when sleep actually resumes
(bridge confirmed), instead of speculatively counting all non-sleep
time as awake. Fixes total duration exceeding session span.
Fix dead code bug where MAX_WAKE_PHASE_LENGTH could never trigger
because Block A unconditionally nulled sleepStart before Block B
could check it. Non-sleep samples now only break a session if the
user has step activity or the gap exceeds 1 hour. Bridged gaps are
counted as awake sleep duration.
See: #5757
- Enable supportsInstalledAppManagement() to show the Apps tab in App Manager
- Fix RPK install protocol: include versionCode (field 2 of RpkInfo) in the
install request; the band silently ignores requests with versionCode=0
- Fix CMD_RPK_INSTALLED (subtype=2): handle band's post-install notification
to refresh the app list at the right time
- Fix deleteRpk() UUID comparison: use .equals() instead of ==
- Refresh app list after delete (band sends no explicit delete response)
- Read versionCode from RPK manifest.json in XiaomiFWHelper
- Fix various wrong proto field reads (watchface fields used for RPK responses)
getActivityKindForSample was written before AWAKE_SLEEP existed in
ActivityKind (April 2024 vs August 2024), so decoded stage 5 (awake
during sleep) fell through to UNKNOWN. This caused the sleep overlay
to skip awake periods, which may fragment sleep sessions in
SleepAnalysis and result in missing or truncated Health Connect
sleep records.
See: https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/5920
The device setting was conflated with "third_party_apps_set_settings" in c3d76477ec, but after reviewing PebbleKitSupport class, the allowed PebbleKit actions are not capable of changing settings on the android device as all of them are just piping data to and from the Pebble device.
PebbleKit messages can change settings on a Pebble device, though, this is possibly the source of the original confusion.
It looks like the 'NOT_CONNECTED' state does not get intercepted, change it to 'CONNECTING' as Gadgetbridge will attempt a reconnection immediately after disconnect
Use the standard field encoding for coordinates. Untested as my watch does not show the contents of the coordinate fields, but verified that they used to be invalid in the test cases and are now properly populated.
Also update test cases to match.