Using the UUID version instead of BluetoothGattCharacteristic version ensures that, if a characteristic is missing on the gadget GB actually logs what characteristic is missing.
Introduce new Settings / User interface / Screenshots to optionally prevent screenshots and viewing on non-secure displays.
Toggling this setting requires a GB restart to become fully effective.
Starting with version 14 Android tries to negotiate MTU 517 when GB requests any MTU > 23.
If the negotiated MTU is larger than 515 the DeviceSupports may try to write 513 or 514 (MTU-3) bytes at once.
Writing more than 512 bytes into a characteristic with one BLE write action is always going to fail (Bluetooth specification).
This is especially relevant for Android 14
https://developer.android.com/about/versions/14/behavior-changes-all#mtu-set-to-517
AbstractBTLEDeviceSupport.calcMaxWriteChunk:
new function to properly calculate chunk size
TransactionBuilder.writeChunkedData:
if required automatically resize the chunk size
TransactionBuilder.write and TransactionBuilder.writeLegacy:
for now log an error but still attempt to write the data
1) replace DeviceSupport's performConnected and performImmediately with TransactionBuilder's queueConnected and queueImmediately - perform* couldn't prevent repeatedly queueing the same transaction
2) improve JavaDoc for btle+br TransactionBuilders
3) improve error handling for btle's TransactionBuilder
Some vendors customized timing aspects so that the old and new writeCharacteristic calls behave differently.
On vanilla Android there is no difference.
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.
Thomas Kuehne
