This works by adding the ability to pause the sending of data from the Bluetooth LE queue. While BtLEQueue is modified, unless setPaused(true) is called it behaves exactly as before so shouldn't cause any issues.
Mostly copied from the Buds Pro as those earbuds have a similar feature set and mostly the same protocol.
Co-authored-by: narektor <narektor@noreply.codeberg.org>
Co-committed-by: narektor <narektor@noreply.codeberg.org>
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
- use encryption to create data rather then replay captured BLE traffic
- use periodical data sender, as is required by the BLE module
- extract string resources
This has some advantages:
- Less stuff to download for building Gadgetbridge (CI Speedups)
- Shorter build time (no need to build shared library for all supported architectures)
- Easier debugging
- etc :P
What I did:
- remove all curves except B163 to make porting easier
- port to java with brain switched off
- fix the "java has no unsigned" bugs
- add some helpers to convert int[] to byte[] and back because java has no casts
The result is ugly, no one would write such crappy code from scratch, but I tried to
keep it as close to the C code as possible to prevent bugs. Since I did not know what
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.
