This updates the parser to interpret more FIT information and display it in the FIT file viewer.
Actually using the available information isn't part of this PR.
DeviceSupports in master already use the modern methods.
DeviceSupports outside of the master branch either already use the modern methods or have know fix-ups (#5318).
Add a "CMF Watch Pro 2" test device manually and then open device specific settings results in following exception because supportedLanguages is null:
Uncaught exception in mainjava.lang.NullPointerException: Attempt to get length of null array
at nodomain.freeyourgadget.gadgetbridge.activities.devicesettings.DeviceSpecificSettingsFragment.setChangeListener(DeviceSpecificSettingsFragment.java:419)
at nodomain.freeyourgadget.gadgetbridge.activities.devicesettings.DeviceSpecificSettingsFragment.onCreatePreferences(DeviceSpecificSettingsFragment.java:244)
at androidx.preference.PreferenceFragmentCompat.onCreate(PreferenceFragmentCompat.java:161)
at nodomain.freeyourgadget.gadgetbridge.activities.AbstractPreferenceFragment.onCreate(AbstractPreferenceFragment.java:81)
Adds support for receiving weights from standard Bluetooth Weight scales:
0000181d-0000-1000-8000-00805f9b34fb - org.bluetooth.service.weight_scale
00002a9d-0000-1000-8000-00805f9b34fb - org.bluetooth.characteristic.weight_measurement
https://www.bluetooth.com/specifications/specs/weight-scale-service-1-0-1/
When receiving the broad cast action `nodomain.freeyourgadget.gadgetbridge.ACTION_GENERIC_WEATHER`
Try to decode bundle extra `WeatherGz` (ByteArray containing GZiped UTF-8 encoded JSON array of weather specifications) first.
If not present fall back to bundle extras `WeatherJson` (String containing one JSON weather specification) and optional `WeatherSecondaryJson` (String containing JSON array of weather specifications).
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
Thomas Kuehne
