Implement support for Sleep As Android with an usable example for ZeppOs
devices
Sleep as Android documentation:
https://docs.sleep.urbandroid.org/devs/wearable_api.html
Signed-off-by: Marcel Alexandru Nitan <nitan.marcel@protonmail.com>
Introduce the concept of primary and secondary weathers:
* Primary weather keeps the same behavior as previously across all weather providers, so it's non-breaking. This location is not necessarily the current location, just the primary weather location set by the user.
* The GenericWeatherReceiver now has a new extra WeatherSecondaryJson, that receives a json list with secondary weather locations.
It's guaranteed that the primary weather always exists, so the list of WeatherSpecs provided to devices is never empty. Update all support classes accordingly.
Activity data fetching on Huami devices was filled with duplicated code,
and the handleActivityFetchFinish was called from multiple places where
it did not make sense. This made us signal to the band that activity
fetch was finished when it sometimes was not, causing some race
condititions that would make activity fetch fail or get stuck.
This refactor defines a clear "processBufferedData" that is called
upstream, signaling to the fetch operation that we have received all
data and the buffer can be processed. All handling of metadata and ack
messages is also delegated to the upstream class.
Gadgetbridge can be configured to perform an action when a
Huami device is taken off or the user was detected to fall asleep or
wake up. This functionality was specific to Huami devices, but this
changeset moves this upstream to the AbstractDeviceSupport class in
combination with new GBDeviceEvents.
Now that the ADS has centralized support for this functionality, the
same logic can be used for other devices. In this case, an
implementation is added for supported Xiaomi devices.
- 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.
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.
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...
Moved to AbstractDeviceSupport so each device support class can override them if required. This change helps to keep the code base clean by not requiring every (Device)Support class to implement these methods even when they don't need them.
The config refactor in addf7ff6a broke health settings on GTR3 and GTS3
- GTS 3 and GTR 3 health configs use protocol v1. The only difference
seems to be that the steps goal is a SHORT instead of an INT.
- It needs a refactoring from the ground up to better handle different
versions, but this is enough to get the GTR 3 and GTS 3 working.
- File uploads are split in chunks, with the size dictated by the
watches. There seem to be 2 protocol versions, without any noticeable
differences
- Extract the file upload logic to a standalone class. This makes it
easier to keep track of concurrent requests, each of which have their
own session id
- Icons larger than 8KB will end up split in multiple chunks - we now
handle that correctly
- Notification icons are also requested in 2 different formats, but
the actual encoding seems to be the same, with only a different id
The previous one was too long, now that we loop it.
This one should be a sane default, even for devices that do not support
it (eg. Bip), as the total time is 1.5s.
