- 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)
Due to a bug in DeviceCommunicationService.isConnected(), devices using the
INITIALIZED state only worked when they had useAutoConnect set to true (Mi Band)
Now setting devices to INITIALIZED state to allow any action send to
DeviceCommunicationService is mandatory. As an exception only
REQUEST_VERSIONINFO will be also be allowed for CONNECTED state.
This also fixes a problem when notifications came in on the Pebble with 3.x
FW before we actually knew it was FW 3.x (INITZALIZED state on the Pebble
now implies that we know the FW version)
It's still very much possible to leak the descriptor (when an exception occurs
somewhere in between or anything else goes wrong). So maybe the whole thing
should be redesigned to be independent of files.
- 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
There are some inconsistencies across ROMs: some need the mimetype filter to be present in order to match the file extension, other refuse to do so if the filter is present. Current strategy is to satisfy both requirements by duplicating the filter element.
At the moment the progress bar code is not useful because the FW preparation is almost instantly done, and is the BT transfer that takes time.
The transfer happens when the getQueue method is called, and there is no progress info that I can find.
Andreas Shimokawa