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.
Disconnect devices in all states except GBDevice.State.NOT_CONNECTED.
This should fix devices getting stuck in GBDevice.State.CONNECTING state
when Bluetooth is switched off.
* Add general_reconnectonlytoconnected setting.
* Replace last_device_address shared prefs string with
last_device_addresses shared prefs string set.
Bluetooth address of a device is added to last_device_addresses when
connecting to the device.
Bluetooth address of a device is removed from last_device_addresses only
when deleting the device or explicitly disconnecting from the device
(e.g. by selecting "Disconnect" in the device tile menu).
* Adjust ExternalPebbleJSActivity to better support multiple connected
devices.
Explicitely disable the request MTU feature from the NRF DFU library to ensure that it'll send 20 bytes packets (instead of 253B, which will crash InfiniTime).
