1) The AutoConnectIntervalReceiver was completely disabled when a device went into WAITING_FOR_RECONNECT state
2) The logic inside AutoConnectIntervalReceiver was broken, so that a timer never got started
this PR aims to add device for multiple connected devices at once.
A lot of stuff already works, some things need to be done:
- [x] change DeviceCommunicationService to hold multiple devices and supports
- [x] implement connect / disconnect logic
- [x] widgets, not really suited for multiple devices, so far
- [x] change the notification to show multiple devices
- [ ] change GBDeviceService#onFindDevice and similar API functions to target individual devices, not all connected.
- [x] move auto-reconnect setting to device settings
- [x] fix music event crash
- [x] work out behaviour when pressing "connect" from notification
- [ ] handle service crashes
- [ ] suit coordinator methods for multiple devices of same kind
- [x] change ACL_CONNECTED receiver to connect to devices that are not currently registered in DeviceCommunicationService
- [ ] adjust after-boot auto-connection logic
- [ ] fix hanging device support. Device says disconnected, GB says connected
- [x] firmware updater doesn't work
My attempt to make onFindDevice work was to change the arguments to ```EventHandler#onFindDevice(GBDevice device, boolean start)```.
The Problem is that this forces the device-specific implementations to also accept GBDevice as an argument.
Co-authored-by: Daniel Dakhno <dakhnod@gmail.com>
Co-authored-by: Andreas Shimokawa <shimokawa@fsfe.org>
Co-authored-by: dakhnod <dakhnod@gmail.com>
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2526
Co-authored-by: dakhnod <dakhnod@noreply.codeberg.org>
Co-committed-by: dakhnod <dakhnod@noreply.codeberg.org>
* Handle all notifications via GB.
* Create all notification channels in one place.
* Lazily init notification channels.
* Re-create notification channels to update their localized names.
This happened when sending a notification while doing authentication.
The reason the notification came though is the "auto connect" code that is
supposed to connect when a message arrives, so that it does not get lost.
This code and DeviceSupport::useAutoConnect() is probably totally useless by now
and could be removed in favor of the "waiting for reconnect" state.
The bug could have been solved by setting the device busy during authentication
in Huami code, but I did it by...
Note to self:
"Block everything except a disconnect request in DeviceCommunicationService
if the device is not yet initialzed but connected, assuming it is somewhere in
the middle doing something important"
This commit refactors code and implements a custom device specific string
filter, which does nothing by default.
The implementation in HuamiSupport does the custom emoji conversion.
The setting has been moved from devicesettings_amazfitbip.xml to an extra file
As soon as there is a custom font for Mi Band 2/3/4 it is sufficient to add
"devicesettings_custom_emoji_font.xml" to the list of supported settings
in the appropriate coordinator and everything will work.
Some devices don't support emoji's and display a series of `?` chars.
Instead of that, replace them by `:<emoji>:` text, e.g. `A 🐱` is
replaced by `A 🐱`.
This is done by using 'android-emojify' project and their
`EmojiUtils.shortCodify(text);` function.
For more details about this lib released under MIT license:
https://anitrend.github.io/android-emojify/
- Fixes "Mute, Open, Dismiss" to work again on pebble
- Greatly reduces complexity in PebbleProtocol, since all logic for adding specific reply actions to notification have been moved to generic code
Fixes the rest of #1336 (the part that says "Additionally, dismissing a notification on the watch no longer dismisses it on the Android device")
Prevent duplicate notifications with a dedicated data structure (not reusing
the anti-burst one) #1062, #657
Pebble: Forward the actions attached to notifications (not only reply)
inspired by the work of dnastase #705
