The current GATT characteristic list mentions it was up to date as of populated 2015-09-28. In the last 6 years, significantly more characteristics have been added to the Bluetooth spec. While it's not necessary to have all these constants available in Gadgetbridge, it's useful while implementing new features for a device or adding support for a new device
This was retrieved from https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf. The GATT characteristics were parsed from that PDF and converted to constants with names via:
```
String description = uuid.description.trim().toUpperCase().replace(' ', '_').replace('-', '_');
System.out.println("public static final UUID UUID_CHARACTERISTIC_" + description + " = UUID.fromString((String.format(AbstractBTLEDeviceSupport.BASE_UUID, \"" + uuid.uuid + "\")));");
```
Reasons for removal:
- I doubt we honored the offset correctly for new features anyway that are available on newer devices
- Newer devices have a display always displaying the wrong time
The issue here is the following:
- we used intents in the generic BleProfile classes to notify about the results of e.g. certain read requests
- we used to send these results asynchronously via LocalBroadcastManager.sendBroadcast(), which always used the main thread for sending
- however, we noticed that reconnecting to devices sometimes failed because the results arrived too late and the next action in the BLE queue lacked the necessary information
- the fix was to use LocalBroadcastManager.setBroadcastSync(), so that the results arrive in time
- this unfortunately meant that they were not sent in the main thread anymore, and especially, this would send all pending intents that were previously queued via sendBroadcast() also in the "wrong" thread (in order to keep the order of events)
The fix is to use a custom IntentListener callback interface for synchronous notifications of ble profile results
*without* also causing other, previously queued intents to be sent.
Fixes#1218
This should fix issues like a ConditionalWriteAction failing with an NPE when GBDevice.getFirmwareVersion() returns null even though the DeviceInfoProfile had already received the firmware version (but the intent notification has not been received yet).
Details: when we ask to fetch activity samples from date:time:tz+dst, the band,
under certain conditions, will send us back date:time:tz (without the dst offset)
We're fine with that, so we start fetching. When it's done, we take the last sample's
timestamp (still without dst offset), convert it to a unix timestamp, create a Calendar
using current tz and apply the unix timestamp. Then we send that timestamp again to the
band in order to fetch activity samples from then, but we again add the dst offset to the tz,
so send as date:time:tz+dst without changing the timestamp. That way, we may end up at the
timestamp we began with, fetching the same activity data again and not progressing.
We first need to thorougly understand how the devices behave, before we can reenable and fix
this.
(there are other places where something like this has to be done, probably also in the other direction)
related to #869
(cherry picked from commit a58e3f66ce)
