Since last year KDE’s KNotification framework has support for Android. And while that generally works, there were still a number of things to polish in order to improve the experience on Android, e.g. when using KDE Itinerary there.

Text Formatting

KNotification supports rich-text notification messages, while so far this resulted in a single line with HTML markup on Android.

  • Multi-line messages are enabled by D29323 which is part of KF 5.70. This also removes HTML markup in case we cannot display it.

  • Rich-text support in the notification message is added by D29357, assuming you have at least Android API level 24. This is still in review and should make it into KF 5.71.

KF5Notifications on Android showing a multi-line rich-text notification message.
Multi-line rich text notification message.

Updating Notifications

Still active notifications can be updated when the event they are about changed or more information becomes available. That’s way less bothersome for the user than issuing a new notification each time. KNotifications’ Android backend was however missing support for this until now, which is rectified by D29339, in time for KF 5.70.


In KF 5.58 KNotifications added support for specifying the urgency of a notification. This is a useful property in order to sort larger amount of notifications in a way that the most important ones receive the most attention. D29342 forwards this information to Android, and will become available with KF 5.71.

KF5Notifications on Android showing a low urgency message.
A low urgency notification shown at the very end of the notification list.


Another useful approach for managing larger volumes of notifications is grouping. Notifications referring to similar events can be collapsed together saving space, while still allowing the user to drill down by expanding the group when needed. KNotifications supports this by flags to control whether a notification should be considered for grouping.

Android also has the concept of grouped notification, however it’s not as simple as just forwarding some settings, on Android notification grouping is under full control of the application. D29335 implements this based on KNotifications event ids, while considering the grouping flags when present.

That’s by far the most complex one of these patches, but the screenshots below show it’s worth it. In this example we have three delay notifications from KDE Itinerary, without grouping they would occupy a considerable amount of space, while the collapsed variant is hardly bigger than a single notification.

Three notifications of the same type summarized in a collapsed group.
A collapsed group of three notifications.

Fully expanded you still have access to all details, with the ability to discard individual notifications or the entire group by swiping.

Three grouped notifications shown in full in an expanded group.
An expanded group of three notifications showing all details.

Notification grouping on Android will hopefully make it into KF 5.71.

Lock Screen Visibility

The final patch D29358 deals with controlling the level of detail of a notification shown on the phone lock screen. The challenge here isn’t the Android implementation, but the lack of frontend API in KNotifications for this. That’s being looked into for Plasma Mobile, but isn’t available yet. So far now this is implemented as a custom hint on the notification.

KF5Notifications on Android showing a message on the phone lock screen with full content.
A notification shown on the lock screen with full content.

Obviously this feature is of great interest for KDE Itinerary, its gate/platform change notifications are most useful if you can also read them while rushing to catch your connection without the need of a full phone unlock procedure. Having an option to show them on the lock screen would therefore be nice to have.


There’s more in the Android notification system that we haven’t connected to KNotification yet. Notification categories is one example, in-line reply is another one. For the latter we are also waiting for the corresponding XDG standardization to finalize the corresponding frontend API. There’s also settings for LED notification lights and vibration to look into.

Going further, there is the topic of abstracting launching of notification configuration dialogs. On Android that’s provided by the platform, on Plasma we can do both right now, in-app and out-of-process configuration. So this still needs some conceptual/API design work first.