- 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.
More robost toJSON that deals with unicode and null
Log messages when converting words to images so we can debug when words are being converted that shouldn't be
- Make ChartsHost independent from ChartsActivity
- Rename ChartsActivity to ActivityChartsActivity
- Rename AbstractChartFragment to AbstractActivityChartFragment
- Pull common charts logic to parent classes:
- From ActivityChartsActivity to AbstractChartsActivity
- From AbstractActivityChartFragment to AbstractChartsFragment
It is 2023, it should work, if not it can be turned off.
For newer devices with big firmwares and apps (like Mi Band 7), people just wonder how slow Gadgetbridge installs stuff...
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).
