Allow for support classes to send a write request response to the
device, fi requested. The standard actually expects this to happen, but
Gadgetbridge did not originally support it, so there are concerns that
enabling this globally will cause issues for devices that do not expect
the response.
See also: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2831#issuecomment-941568
- Remove notification on unneeded characteristics for Zepp OS devices
- Reset MTU before initializing device, since the support class is
reused when reconnecting, and keeping the previous high MTU before
renegotiating again can make the initialization fail sometimes
(band will never reply)
- If any of the chunked characteristics is null during initialization,
mark the device as waiting for reconnect, which will make it retry the
connection later with a backoff delay.
- use `BLETypeConversions`, added the missing functions there (+ unit tests for all)
- change Java package of Protobuf definitions so that they are not discarded by Proguard
-- +add subpackages to the Proguard rules so we can subdivide the classes
+ disable device-specific settings for Vivomove (no settings yet)
This affects available features (eg. Alexa). Defaults to the previous
value of "unknown" for now, and no UI. Alexa requires a region where it
is available, such as Germany ("de").
Moved to AbstractDeviceSupport so each device support class can override them if required. This change helps to keep the code base clean by not requiring every (Device)Support class to implement these methods even when they don't need them.
This works by adding the ability to pause the sending of data from the Bluetooth LE queue. While BtLEQueue is modified, unless setPaused(true) is called it behaves exactly as before so shouldn't cause any issues.
This PR adds support for the flipper zero device.
It's main purpose currently is to provide an Intent-based API to Tasker and similar apps to play sub-GHz files.
In the future, file management and other features might be useful.
Co-authored-by: Daniel Dakhno <dakhnod@gmail.com>
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2840
Co-authored-by: dakhnod <dakhnod@noreply.codeberg.org>
Co-committed-by: dakhnod <dakhnod@noreply.codeberg.org>
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 + "\")));");
```
