Use a more robust cast approach to prevent application crashes in some corner cases (e.g. when writing Math.round()ed values)
Since I don't own a VivoMoveHR device I couldn't test for regressions on the watch.
Allow for support classes to send a write request response to the
device, fi requested. The standard actually expects this to happen, but
Gadgetbridge did not originally support it, so there are concerns that
enabling this globally will cause issues for devices that do not expect
the response.
See also: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2831#issuecomment-941568
- Remove notification on unneeded characteristics for Zepp OS devices
- Reset MTU before initializing device, since the support class is
reused when reconnecting, and keeping the previous high MTU before
renegotiating again can make the initialization fail sometimes
(band will never reply)
- If any of the chunked characteristics is null during initialization,
mark the device as waiting for reconnect, which will make it retry the
connection later with a backoff delay.
HuamiSupport handles configurations with performInitialize, which may
trigger a device reinitialization if called while the device is already
initializing.
Handle fitness goals in Huami2021Support, which should be one of the
last settings still missing.
Since we now handle chunked acks as of 74dac3f5c, these may happen
during device initialization. We must not use performInitialized, or
initializeDevice will be called twice, since the device will still not
be in INITIALIZING state.
Now that the target SDK was changed to 31, the `no.nordicsemi.android:dfu`
library needs to be updated, as the current version dies on Android 12+.
However, the fixed version (1.12.0) also fixed MTU handling: The previous
versions ignored the MTU settings completely for legacy DFU.
<https://github.com/NordicSemiconductor/Android-DFU-Library/pull/260>
And while our `PineTimeJFSupport` code always tried to set MTU to 517, it was
ignored. Which was good because PineTime does not support larger MTUs. So that
we need to set the correct low MTU now the library really applies it.
Note that the current version of the DFU library cannot be used right now, it
does not even compile because of androidx dependency mismatch.
Fixes#3203
- rename service identifiers for clarity
- define BLE scan filter in the coordinator (even though GB does not use those currently)
- rename `DownloadedFitFile` to `GarminFitFile`
- bump DB schema version to 49
- use `BLETypeConversions`, added the missing functions there (+ unit tests for all)
- change Java package of Protobuf definitions so that they are not discarded by Proguard
-- +add subpackages to the Proguard rules so we can subdivide the classes
+ disable device-specific settings for Vivomove (no settings yet)
- 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.
Extract handling of packet types with large code blocks.
Incidentally fixes "intent" packets launching a full calendar sync if
intents are disabled in GB settings.
