from lint:
Use of scheduleAtFixedRate is strongly discouraged because it can lead to unexpected behaviour when Android processes become cached (tasks may unexpectedly execute hundreds or thousands of times in quick succession when a process changes from cached to uncached).
when multiple threads may be involved
AtomicBoolean: at least once code location tests and then sets the value
volatile boolean: test and set are in different code path
only effective in debug builds:
Test if a DeviceSupport is ready for multiple connect triggers (manual, AutoConnectIntervalReceiver, BluetoothConnectReceiver, GBCompanionDeviceService)
Device specific debugging preferences:
1) optionally call DeviceSupport.dispose() twice
2) optionally call DeviceSupport.connect() multiple times in series or in parallel
DeviceSupport asks BtBRQueue/BtLEQueue for the connectivity status as the queue knows best.
This enables the queue implementation to sidestep multi-threading issues.
When a device goes out of range and then comes back into range DeviceCommunicationService disposes DeviceSupport while trying to re-establish a connection.
This causes race conditions as there are multiple for path for reconnections that can be executed in parallel.
The DeviceService.ACTION_CONNECT path kills everything abruptly potential leaving the gadget with a broken connection.
partial backport from PR #4916
1/2:
- rename AbstractBTLEDeviceSupport to AbstractBTLESingleDeviceSupport
- apply all BtLEQueue settings before processing starts
- introduce getServiceDiscoveryDelay to support device specific delay between STATE_CONNECTED and getServices/discoverServices
2/2:
- add a new AbstractBTLEDeviceSupport as a common super class of AbstractBTLEMultiDeviceSupport and AbstractBTLESingleDeviceSupport
1/2:
- rename AbstractBTLEDeviceSupport to AbstractBTLESingleDeviceSupport
- apply all BtLEQueue settings before processing starts
- introduce getServiceDiscoveryDelay to support device specific delay between STATE_CONNECTED and getServices/discoverServices
2/2:
- add a new AbstractBTLEDeviceSupport as a common super class of AbstractBTLEMultiDeviceSupport and AbstractBTLESingleDeviceSupport
Use BluetoothDeviceFilter or BluetoothLeDeviceFilter instead of always BluetoothDeviceFilter.
While this doesn't seem to impact the associate call itself it influences how/when CompanionDeviceService picks up the gadget on some devices.
When a GATT device disconnects and supports automatic reconnection then:
1) two DeviceManager.ACTION_DEVICES_CHANGED intents are posted
2) for the first intent AutoConnectIntervalReceiver schedules a 8 sec alarm
3) for the second intent AutoConnectIntervalReceiver schedules a 16 sec alarm
However the AlarmManager replaces the 8 sec alarm with the 16 sec one.
So AutoConnectIntervalReceiver attempts to reconnect after 16 sec delay.
Redundant source of truth. The information is already available via the device parameter.
Leaving it in would complicate future improvements to the CompanionDevice handling.
If both PROPERTY_WRITE and PROPERTY_WRITE_NO_RESPONSE are supported by a BluetoothGattCharacteristic Android defaults to WRITE_TYPE_NO_RESPONSE.
This then may cause early BluetoothGattCallback.onCharacteristicWrite calls when the write has been queued on the mobile but potentially not yet actually completely reached the gadget.
Depending on the queued BtLEAction(s) and timing details this is often harmless but may sporadically cause inconsistencies.
Must be explicitly enabled in the device specific developer settings.
Android's Bluetooth rejects MACs with:
- lower letter (abcdef) instead of upper letters (ABCDEF)
- hyphens (-) instead of colons (:)
banglejs builds also support pebble emulator addresses
The BluetoothDevice.ACTION_ACL_CONNECTED intent indicating gadget or Android imitated connections is not specific to Bluetooth Classic.
So make the GBPrefs.DEVICE_CONNECT_BACK setting available to both Bluetooth Classic and BLE.
Change the method signature of GattCallback.onDescriptorRead to be memory safe. See Android 13 (Tiramisu, API 33) documentation for background.
To be memory safe onDescriptorRead should always evaluate the `value` parameter, potential in combination with BLETypeConversions, and not use:
- BluetoothGattDescriptor.getValue
- BluetoothGattDescriptor.getIntValue
- BluetoothGattDescriptor.getFloatValue
- BluetoothGattDescriptor.getStringValue
Change the method signatures of GattCallback.onCharacteristicChanged and GattCallback.onCharacteristicRead to be memory safe. See Android 13 (Tiramisu, API 33) documentation for background.
To be memory safe onCharacteristicChanged and onCharacteristicRead should always evaluate the `value` parameter, potential in combination with BLETypeConversions, and not use:
- BluetoothGattCharacteristic.getValue
- BluetoothGattCharacteristic.getIntValue
- BluetoothGattCharacteristic.getFloatValue
- BluetoothGattCharacteristic.getStringValue
Switch the Java toolchain to version 21 - the version shipped with current AndroidStudio releases.
Disable Java 1.8 warnings - see discussion in PR #4735
During one build buildGitChangelog is executed multiple times (one call per defined applicationVariant).
This slows down builds and - because it generates a resource file - blocks Android Studio's Instant Run feature.
PR #4735 inadvertently turned Android's targetCompatibility into Java's targetCompatibility thereby rendering it ineffective for Android.
As a result Android used the toolchain version (17) instead of targetCompatibility 1.8 to create *.class files.
See also: https://developer.android.com/build/jdks
- fetch only new records instead of all records while the device is connected
- added PREF_POWER_SAVING support (disables / enables SpO2 sensing)
- added HRV visualization
- unified and secured Intent handling
- added BATTERY_CHARGING_FULL support
- honour PREF_TIME_SYNC in onSetTime
- various clean-ups
includes prerequisites:
- pcom.android.tools.build update from 8.6.1 to 8.9.1
- compileSdk update from 34 to 35 (targetSdk and minSdk are unchanged)
- .gradle and .java housekeeping fixes to reduce build warnings
Thomas Kuehne
