This affects InfiniTime and Huami
For InfiniTime it probably resulted in the wrong time being displayed
For Huami is resulted to request the wrong data from the band/watch
We used timezone.getDSTOffset() which always returns the DST offset (also in non
DST time)
We need to pass the time being observed to calendar.getOffset() to get the real
offset including DST at that specfic time which then either includes DST offset or not.
BLE protocol only sends a UTC offset which combines the TZ with DST, if we take
a local timezone as a base and add a raw offset with DST included, DST might
be added again.
This is to fix problems with recorded data on Huami devices where we cannot know
in which timezone data was recorded - only the offset, where we do not know if a
part of it is DST.
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).
