Wake lock with around 10 second timeout is a quick and dirty solution,
however as the time sync should happen once per several days the 10
second wake time should not be an issue.
Ensure TimeChangeReceiver alarm is scheduled when enabling
datetime_synconconnect and registering TimeChangeReceiver broadcast
receiver.
It is important to re-schedule the alarm after registering broadcast
receiver, because:
1. if broadcast receiver was unregistered while previous alarm arrived,
there is no alarm scheduled;
2. re-scheduling the alarm resets the periodic time sync timer when
first device is connected (which is desired).
It is important to re-schedule the alarm when datetime_synconconnect
gets enabled, because there might be no alarm scheduled.
Call onSetTime() when enabling datetime_synconconnect.
Sync time every 43 hours, 53 minutes and 23 seconds.
Interval is a bit smaller than 2 days.
Interval is a prime (in seconds) so time of sync will slide over time.
If next DST change is less than 48 hours in future, wait for it.
- communication protocols
- device support implementation
- download FIT file storage
Features:
- basic connectivity: time sync, battery status, HW/FW version info
- real-time activity tracking
- fitness data sync
- find the device, find the phone
- factory reset
Features implemented but not working:
- notifications: fully implemented, seem to communicate correctly, but not shown on watch
Features implemented partially (not expected to work now):
- weather information (and in future possibly weather alerts)
- music info
- firmware update: only the initial file upload implemented, not used
Things to improve/change:
- Device name hardcoded in `VivomoveHrCoordinator.getSupportedType`, service UUIDs not available
- Download FIT file storage: Should be store (and offer the user to export?) the FIT data forever?
- Obviously, various code improvements, cleanup, etc.
Previously we used an integer (in meters) but when using
Google Maps navigation, Google Maps picks units based on locale *and*
the distance - it might report "100m" or "20km". Then we carefully undo
all that work, and for PineTime we just as "m" so you may well have "20000m"
or more displayed, which is not ideal.
I imagine at some point that will change, but we probably want to
be able to handle that in the OSMAnd side of Gadgetbridge so all watches
that implement navigation will benefit (and won't duplicate code).
Add extra 'ETA' field to NavigationInfoSpec
Allow Local Notifications from Google Maps to be parsed into NavigationInfoSpec by GoogleMapsNotificationHandler
Moved notification handling after blacklist check as per https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3136#issuecomment-920095
Ensure we don't create a nav message for 'Location Shared with you' messages.
Recognise 'ft' as a distance unit and convert accordingly
Google Maps navigation: Adding new recognised icons, and removing warnings/errors from file
Updates WeatherSpec to v3 to add fields for UV index and precipitation probability
Co-authored-by: Enrico Brambilla <enricobilla@noreply.codeberg.org>
Co-committed-by: Enrico Brambilla <enricobilla@noreply.codeberg.org>
This also touches parts of the app not only used for bangle.js.
E.g. pending intents gets new flags from SDK 23 inclusive.
Bluetooth permissions are updated to work on SDK 31.
Permission handling is updated to the new way for doing it with
introduction of a new function. This is called for newer sdk versions.
bump Bangle.js flavor targetSdkVersion to 31
update comments re SDK 31
set the 'exported=true' I introduced to false instead - except for three places
add uses-permission for handling bluetooth in order to work on api >30
add if-blocks adding FLAG_IMMUTABLE to PendingIntents on api >30
add link to bluetooth documentation
Add comment to banglejs manifest. Add requirement annotation to ControlCenterv
bump compileSdkVersion to 31
add "OpenAppSettings" permission popup while working out individual permission popups on android 13
if SDK < 31 do permissions one by one, else send user to app info page to switch permissions manually
working solution, but needs cleaning
do some cleaning, not done though
remove some logging
remove import Log
tweak and remove toasts in new permissions handling
Change conditions `> Build.VERSION_CODES.Q` to `>= Build.VERSION_CODES.R` matching the style used everywhere else
Revert "Change conditions `> Build.VERSION_CODES.Q` to `>= Build.VERSION_CODES.R` matching the style used everywhere else"
This reverts commit 2929629ff43fbb685eb3d15e42459f321f68fa11.
Revert "add if-blocks adding FLAG_IMMUTABLE to PendingIntents on api >30"
This reverts commit ed8e1df7bb8b71fee745fbf9d10747d47c8f6cb8.
Pending intents gets `PendingIntent.FLAG_IMMUTABLE` if `(Build.VERSION.SDK_INT >= Build.VERSION_CODES.R)`.
Bangle.js: undo `@RequiresApi` code R
... to remove error in Android Studio where declared required api was
higher then minSDK version.
Use FLAG_MUTABLE for reply to test notification
This should fix Gadgetbridge crashing when replying to the test
notification from the debug activity. As reported here:
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2924#issuecomment-917282
Change to use FLAG_IMMUTABLE/_MUTABLE from SDK 23
... as suggested by Android Studio. This is supposed to make the app
more secure by not allowing certain changes to pending intents where
they are not expected. If I understood correctly.
Add PendingIntentUtils class to manage mutability
