It should fix installation of all .pbl files (tested with Spanish, German, French and the inofficial Japanese language pack)
This also marks the return of the infamous STM32CRC, this time with hopefully fixed tail code.
NOTES:
- YOU SHOULD NOT TRY THIS YET ;)
- This was only tested with the unoffical japansese language pack
- Problably needs proper crc calculation (I just hardcoded the one for the japanese language pack)
The notfification APIs now use NotificationSpec as their only parameter, which
contains all information (required and optional ones).
We no longer have separate methods and actions for SMS/EMAIL/GENERIC anymore.
The type of notification is important now, not how we received them technically.
Fixes#102
We could also use a whitelist approach instead, but we can't be sure that the user installs a file with .fw extension, hence i preferred to only avoid loading files which are known to be of the wrong type.
Previously, the DeviceCommunicationService was invoked directly,
via
Intent intent = new Intent(foo, bar);
intent.setExtra(EXTRA_BAZ, baz);
startService(...);
and this was scattered throughout GadgetBridge.
Now there is a "frontend" available, so that you can call
the service more easily, like
GBApplication.deviceService().connect();
For a start, this client interface (DeviceService) actually
implements the same interface (EventHandler) as the receiving side
(DeviceSupport). This may change in the future.
This will also make testing much easier, because we can use
this client interface to invoke the test service as well.
- make FwAppInstallerActivity wait for a completely initialized device
- check basalt/aplite compatibility with pbw to be installed and report intead of crashing
- fix crash when trying to install pbw with all app slots full
- version information is now provided implicitly by device initialization
- ACTION_REQUEST_VERSIONINFO is now ACTION_REQUEST_DEVICEINFO and it will
return the current device state of the service without asking any DeviceSupport
instance.
- ACTION_CONNECT now implicitly answers with a device update intent if it
IS already connected.
- the BASE_UUID is shared between all BTLE devices, not miband specific. So are the UUID DESCRIPTORS. Hence these have been moved to AbstractBTLEDeviceSupport
- the gatt-characteristic-property-constants used previously in MiBandNotifyAction are also general, and exposed by the gatt subsystem, hence the specific action has been dropped moving the logic to the NotifyAction class
- the logic for checking the gatt-characteristic-property-constants has been extended also to the ReadAction and WriteAction class, this way we won't try to read (or write) a characteristic that isn't readable (or writeable)