- dynamically toggle hr sleep support when preference changes
- check hr support dynaically after device info is available to avoid false error message
Also supports double firmware upgrade for Mi1S.
- so far, only hr firmware upgrade is tested for 1S
- adds junit testcases for firmware recognition and handling
This avoids a lot of problems because java
- does not know unsigned values
- jvm and dalvic do not internally support byte and short
- sqlite does not know them either
- listen to notifications early -- the band then actually tells us that
authentication is required
- check for this after sending user info
- add authentication states to GBDevice
- workaround for event problems in pairing activity (delivered although
already unregistered)
- BtLEQueue now deals with gatt events coming *before* connectGatt()
actually returned (namely the connection event)
Created a new device-independent class ActivityUser to hold the data
Moved the constants from the miband constant class to the ActivityUser class
Removed the miband-specific in favor of common-prefixed preferences (with upgrade support for legacy values)
Changed the way the gender is stored to an integer value
Removed the hardcoded default values for user data in favor of static fields of the ActivityUser class
(i.e. bluetooth-level pairing). Previously the pairing appeared to
happen automagically, but this doesn't work (anymore). So now we first
pair on the bluetooth-level, then application level.
- created and provided by DeviceHelper
- passed from UI to service
- without UI, service uses DeviceHelper directly
=> Cleaner and less duplicated code
I hope I didn't break firmware upgrades on some Mi 1 models
other than mine (my hardware revision is 2).
Upgrades for Mi 1S are currently disabled, we need some brave
souls who can help us test this.
Closes#173
Also see: #169
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.
