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.
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 + "\")));");
```
Reasons for removal:
- I doubt we honored the offset correctly for new features anyway that are available on newer devices
- Newer devices have a display always displaying the wrong time
TODO:
- Fix alarm widget (how can we get the deviceId?)
- Get rid of GBAlarm in favour of DAO generated Alarm class
- Find better defaults
- Bonus: migrate old preferece based shared settings
This removes misuse of testNewFunctionality() and support fetching GPS data and debug logs
Fetching debug logs (Amazfit Bip/Cor) is now accessible in the debug activity
Fetching GPS data can be done by swiping in the list activity.
TODO: actually refresh list when fetching data is done :P
Also fix some android studio warnings on the go...
Based on the profile version which is 0x2000700 for both the bug reporter on a Mi Band 1 and for me on a Mi Band 1s
this either expects packets with length 20 (old firmwares) or 16 for HR enabled bands and 18 for non-HR enabled bands (new firmwares)
We check for profile version >=0x02000000 which is guessed, that needs confirmation for older firmwares and untested ones
Fixes#915
Most of the code is generic, so it could be implemented by other devices.
I dont know what happens if multiple messages arrive in the same notification.
So, this is experimental.
