Fixes a typo in the weather forecast characteristic writer that causes
Gadgetbridge to send the current weather twice rather than sending the
forecast.
Zepp OS 3 firmware upgrades are big (200MB+). Gadgetbridge was crashing,
since the entire firmware file would be pulled into memory.
This commit unifies all the logic for Zepp OS firmware handling.
However, since the needed refactor was big, this commit duplicates some
of the code from Huami classes, namely:
- ZeppOsFirmwareUpdateOperation clones UpdateFirmwareOperation2020
- ZeppOsFwInstallHandler clones AbstractMiBandFWInstallHandler
This avoids changes to older device logic and introducing regressions.
Lost functionality:
- Repackaging firmwares as UIHH (does not seem to be needed, and was not
used anyway). Code can be recovered from this commit if needed in the
future
- Whitelisted firmwares by checksum (we do not have a lot of them at
this point anyway)
Other misc changes:
- Rename ZipFile to GBZipFile not to clash with the java class
Tested by updating the Amazfit GTR 4 to Zepp OS 3.
Initial support for sony wi-sp600n reported working . minor difference with the inspiring wf-sp800n
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3522
Co-authored-by: Denis Pitzalis <denics@free.fr>
Co-committed-by: Denis Pitzalis <denics@free.fr>
If the device connection state is updated from two threads simultaneously
(as in, from the main looper and from the thread that handles
BluetoothDevice.connectGatt), a second update may get overridden by the
first update if the broadcasts are handled out-of-order by the
LocalBroadcastManager.
By updating the device state through a handler on the main looper, the
broadcasts are sent in order as they are processed from the looper's
queue.
This may be a potential solve for issue #3524.
- Some devices send a random int 0, which would prevent sleep stage
parsing
- Some devices send the details as a file of type summary, but same
structure
- It is still not stable for all devices
Thanks to @opcode for the parsing logic
Not all communication was moved to services, and some might not be
respecting the encryption flag sent during initialization implemented
in 3a2b02df2. Some services are encrypted or not across different
watches - see #3308.
This allows sleep stage detection to work by parsing
some of the data sent in SleepDetails.
It's still missing parsing the summary contained inside SleepDetails.
and decoding the large amount of other mostly unknown data.
