Go to notification blacklist, allow an app if blacklisted, than configure it's behavior with the menu icon on the right hand side.
Should be pretty much self explanatory.
Database Scheme raised to 20
It seems some apps like Telegram add a lot of Unicode Control sequences
for unknown reasons. Because these strings are set by external apps, it
is safer to sanitize them. For the moment, only Unicode control
sequences are stripped.
Fixes: #1344
- 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
In case of grouped notifications, we get multiple notifications
also if the android device shows only one.
This means that with this change the most recently updated chat
will get through, but others will not.
This should help with #1062 and #657
It seems WeChat always mark its notifications as LocalOnly. The reason
may be to avoid double notifications when using Android Wear watches,
since WeChat has a standalone Android Wear app.
Do not ignore WeChat notifications even if they're marked as LocalOnly.
Pebble: Add support for dynamic Pebble background colors
- Add a couple additional icon types
- Add Lighthouse (currently unused)
- Add Transit (public transportation app)
- Tweak the colors on existing icon types
- Implement logic to grab primary (vibrant) color from app logo
- The color will be used when displaying a notification for an app
that does not have any configs bound to it.
- Alter NotificationType to support a color (named pebbleColor)
- Alter the Pebble notification poster to listen to the color from
the notification
- Alter the DeviceCommunicationService to allow for color passthrough.
- Add logic to convert HEX or Integer representations of RGB888 colors
to Pebble RGB222 format.
- make the package name retrieved lowercase.
Fixes: #815
As requested in #736, this adds an entry in the settings menu that allows to blacklist certain calendars.
To avoid confusion, all the former blacklist methods and fields have been renamed to apps_blacklist. The new entries are called calendars_blacklist.
Importing the settings has not been tested with the current changes.
Closes#736
Future improvements TODO: The new setting lives in the Pebble section, i believe in the future the blackslist functionality should be centralized and put in the sidebar.
- centralize the logic for skipping unwanted notifications
- use *Compat methods wherever possible
Leaving out the problematic parts (persistent IDs and updating)
- centralize the logic for skipping over unwanted notifications
- use *Compat methods wherever possible
- use unique and persistent ID (update notifications)
- switch to using BigText style by default (since we can now update existing notifications)
- for Pebble: delete and reinsert notification as updating is not possible
Sometimes the media notification does not contain the expected components, hence the code covered by the try/catch has been adjusted. This was reported in #533 for VLC.
In the future the whole media handling will probably be refactored.
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.
Pebble low level code had an own check for notification type being null, no we set it to UNKNOWN early
This regression was introduced in 0.15.0 though "Revamp Notification types Pebble (#453)"
Fixes#468
- Also send duration if "duration" extra is present
- If "playing" and "postion" extras are present send a music state update
treat previous state and current state as equal if position delta is <=2 seconds
(Neccessary for some players which update every second - the pebble however counts by itself)
Since Android 5.0, media players can have interactive notifications that
reside in the notification area, and offer up to 5 control buttons
(play/pause, next, previous, etc), and information about the currentlu
playing media file.
We use these notifications to get information about the currently
playing media file such as:
- artist
- track (title)
- album
- duration (length of the media file)
- play state (playing, paused, stopped)
- position
- play rate (how fast is the media file being played)
We then send this information up to the device.
On Pebble, the music app will display the title and the artist, as
well as a progress bar showing the current position. The progress bar is
animated when the media file is being played, and if it is being paused,
it displays a pause symbol.
This code will be skipped when GadgetBridge is run on a device with
Android version older than 5.0 (lollipop).
PocketCasts tells about its current media state via notifications. This
patch tries to parse incoming notifications from PocketCasts and if
successful tells the device about it. Currently supported are track and
artist.
This should improve (not fix) #214
Still, we cannot decrypt SMS, so if you use SMSSecure as the default SMS App
you should disable SMS Notifications which enables generic notifications for
SMSSecure which are already decrypted.
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.