THIS STILL REQUIRES MI FIT AND YOUR EXTRACTED KEY
HOWTO:
1) press + button in Gadgerbridge
2) LONG PRESS Mi Band 4
3) Tap "Auth Key"
4) Enter your key prefixed with 0x (eg. 0x112233445566778899aabbccddeeff00)
5) Go back
6) Tap Mi Band 4
Success? You tell me.
This allows to construct per-device settings by device type very easily
device coordinators just do the following to declare which setting they support,
the settings activity is then composed at runtime.
@Override
public int[] getSupportedDeviceSpecificSettings(GBDevice device) {
return new int[]{
R.xml.devicesettings_miband3,
R.xml.devicesettings_swipeunlock,
R.xml.devicesettings_pairingkey
};
}
When connecting to a new device, a random key gets generated, which can be
looked up from the device specific settings (accessible via the gear icon in
the device card in the main activity). Old devices keep their 0123456789@ABCDE
key, they have to be re-paired to change that.
During pairing, long-pressing the device candidate in the discovery activity
will also start the device specific settings activity, where the auth key
can be set manually priror to pairing. This is usefull to keep the ability to
pair one device with multiple android devices.
Fixes#1308
So we do need to set the language both on change and onCreate()
For some reason, the title bar of the SettingsActivity is not updated on recreate().
Closes#787
- cleaned up the DeviceService.connect() variants
- discovery: pass the device candidate around instead of the mac address
Attempts to fix#512, #514, #518
- pass service uuids to GBDeviceCandaidate so that DeviceCoordinators
can detect devices by their services.
Note: they should not rely on service uuids being available
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.
- model package contains mostly shared interfaces (UI+service), not named GB*
- impl package contains implementations of those interfaces, named GB*
the impl classes should not be used by the service (not completely done)
- the service classes should mostly use classes inside the service and deviceevents
packages (tbd)
Every device now has two packages:
- devices/[device name] for UI related functionality
- service[device name] for lowlevel communication
