Add actions to the filter (this should help with #536)
Add "copy" constructors to MusicSpec and MusicStateSpec, and use those when receiving an updated intent, this way partial updates do not disrupt the local information.
Iterate over incoming extra keys, explicitly check the incoming type and use only known type. This could help with #533
Possible problem: this code iterates over every key of the incoming bundle.
- cleaned up the DeviceService.connect() variants
- discovery: pass the device candidate around instead of the mac address
Attempts to fix#512, #514, #518
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.
HOWTO:
1) Pair you normal Pebble (not necessary if already done), make sure it was connected once
2) Unpair your LE pebble if already paired
3) Switch on "Always prefer BLE" in Pebble Settings
4) Tap on the + in Control Center to add a new device
5) Pair your Pebble-LE XXXX or Pebble Time LE XXXX inside Gadgetbridge's Device Discovery actibity
Now Gadgetbridge will connect to your LE Pebble when tapping on Pebble XXXX if "Always Prefer BLE" option is enabled.
You can easily switch back to classic LE by turning that option off again
This commit contains the infrastructure needed for the
NotificationHandler to send music state information to the device. That
is, it introduces a call onSetMusicState(MusicStateSpec stateSpec), that
in turn sets up an intent to the service, which will then call the
encodeSetMusicState() function of the device. encodeSetMusicState is
available for pebble only. There are empty stubs for other devices.
- dynamically toggle hr sleep support when preference changes
- check hr support dynaically after device info is available to avoid false error message
NOTE:
Total allowed bytes for all replies = 512 - (reply count - 1)
TODO:
- check with Firmware 2.9.1
- remove last reply that exceeds the 512 bytes limit completly (else it will be partly truncated)
- put random id/phone number pair into limited lookup list (last 16 sms messages) when sms arrives
- lookup the phone number when replying from the a device
THIS STILL DOES NOT DO ANYTHING USEFUL
- Implement the PebbleProtocol side (2.x and 3.x)
- Add Preferences for canned replies
This can be tested by enabling untested features in Pebble Settings
It lets you see and select the replies set up in "Canned Repies" on the Pebble
You will get a "NOT IMPLENTED" message on your Pebble.
THIS DOES NOT ACTUALLY DO ANYTHING USEFUL YET.
- created and provided by DeviceHelper
- passed from UI to service
- without UI, service uses DeviceHelper directly
=> Cleaner and less duplicated code
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.
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.
- 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.
In a second step, request the version from the device (and send updated
values then)
RequestVersionInfo is either a misnomer or misused, depending on your view.
It is actually used by activities to get the current state of thde device.
We now provide this as quickly as possible, with the drawback of sometimes
sending results twice.
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)
Andreas Shimokawa
cpfeiffer
Daniele Gobbetti
ivanovlev
Uwe Hermann
Steffen Liebergeld
Kasha
Sergey Trofimov
Julien Pivotto