Saturday, 13 June 2026
@vkrause:kde.orgQuite a few things have happened around the Android platform support for KDE applications in recent months, so high time for another update on that.
Qt 6.11
As already mentioned previously, we have updated the Qt version to 6.11. That has the unfortunate consequence of losing support for Android 8 and older. Due to that we also removed the ARM32 builds, as devices running Android 9 or higher are very likely capable of using ARM64 builds anyway, cutting down the CI cost by a third.
The previously often annoying interactions between input focus and the virtual keyboard seems to have improved somewhat with Qt 6.11. Changes in how the back key/gesture is handled however also caused a few regressions, like a double page pop in more deeply nested applications (Kirigami MR 2100).
SafeArea support
While the previous focus of dealing with “safe” screen areas (ie. parts of the application window not being covered by screen cutouts or system controls like the Android status and navigation bars) had been on not breaking horribly due to Android’s changed default behavior we have meanwhile been working on polishing this to actually look decent.
- Fixed misplaced drawer handles (Kirigami MR 2102).
- Fixed NeoChat’s chat bar being placed behind the bottom navigation bar (NeoChat MR 2893).
- Fixed a double bottom margin in NeoChat (Kirigami MR 2107).
- Fixed floating buttons in Itinerary getting misplaced (Kirigami MR 2105).
- Fixed Alligator global drawer expanding into the status bar (Alligator MR 172).
- Fixed runtime warnings in Tokodon when computing safe margins (Kirigami MR 2110).
If you spot places where this still doesn’t work correctly, let us know in the #kde-android Matrix channel!
Notifications
There’s also a number of improvements and extensions for notification handling:
- Fixed interactions with notification actions or the notification itself having no effect (MR 200).
- Implemented confirming inline replies (MR 202). This fixes the notification showing a spinner animation indefinitely after submitting an inline reply.
- Improved icon handling. We can now properly distinguish between what Android calls the “small” and “big” notification icons, a symbolic application icon and an image of e.g. a chat avatar. This will require small changes to applications to get the best result, in most cases providing a symbolic application icon should be enough already (MR 201).
- A new API for cross-platform notification configuration is in review (MR 203). This will also benefit Flatpak applications.
Safe JNI usage
Interaction between our C++ code and Android’s Java platform APIs happens via the so-called Java Native Interface (JNI). That’s a rather low-level C interface with little to no type safety and the need for error-prone handwritten arcane signature strings. Already back in the Qt 5 era I had therefore written a few helpers for a more type-safe use of this in KAndroidExtras.
Much of this functionality is meanwhile available in Qt 6 in a very similar fashion, with the JNI array support being the latest addition in Qt 6.9. Compared to raw JNI use this is already a massive improvement, see e.g. MR 204 making use of this in KNotifications. It avoids practically all hand-written JNI signatures as well as much of the manual type conversion.
One part is still missing though, type-safe wrappers so that function arguments and property types are checked at compile-time. That has been extracted and rebased on top of Qt’s JNI code in KJniExtras now. It’s only 10% of the code, with most of the complex template magic gone.
As a small downside we are unfortunately losing the ability to test JNI code on Linux with this, as the old approach provided a mock implementation when not building for Android.
Calendar access
With the type-safe JNI wrappers small enough now to be copied as a single header file, this finally unblocked the move of the Android platform calendar backend from Itinerary upstream to KCalendarCore (MR 242).
Together with the calendar runtime permission API already in Qt, this should make e.g. an “add to calendar” feature for Kongress or KTrip easy to add now.
File dialogs and remote files
An often reported issue against several of our applications is that they seemingly don’t do anything when opening a file via the platform file dialog. This happens for files on a cloud share, which the Qt Quick file dialog silently discards due to not being local files, making this look like as if the user has canceled the dialog to the application. Therefore just nothing happens and no error message is shown either.
Interestingly enough, that problem also happens on KDE Plasma, where the native file dialog also can select remote files, it’s just much less common there. But since we can tell the Plasma file dialog to only allow selecting local files, this one is easy to fix (CR 742273, available in Qt 6.12).
On Android we don’t have that option, nor would that be really satisfying anyway, opening files from a cloud share is a very valid usecase. Therefore there’s now also a proposed change to the Qt Quick file dialog to optionally allow selecting arbitrary URLs, similar to what its Qt Widgets counter-part already offers (CR 743681). This wont automatically fix the problem, but it would at least give applications a chance to do something about this.
Locale-aware sorting
Something fairly basic that Qt on Android so far didn’t do properly (at least when not bundling it with multi-10MB worth of ICU libraries) was locale-aware sorting. When using English you might not notice that, but in many other languages this results in weird and confusing lists. In German for example the letter “Ä” gets basically treated like “A” for sorting, while so far it ended up after “Z” on Android.
There’s now a proposed Qt patch (CR 741548) implementing a QCollator backend for Android
using platform infrastructure. This uses Android’s native ICU flavor when available and otherwise falls back to the less efficient and less featureful Java API.
Crash reporting
While we have automatic crash reporting on Linux since some time (see e.g. Harald’s LAS talk for more details), crashes on Android were not handled at all by our applications so far.
Based on discussions at the Graz Sprint in April this has now changed, KCrash can now detect a previous crash when starting an application, and offers to submit an automatic crash report to KDE’s Sentry instance.
Those reports have been very helpful on Linux already, providing very important information about issues and allowing to prioritize those with the most impact, but it’s nevertheless crucial we don’t submit anything without user consent.
The bulk of the implementation is in KCrash MR 101, a few changes are necessary for integrating this into applications as well though.
In your build.gradle, add sentry-android-core as a dependency:
dependencies {
...
implementation 'io.sentry:sentry-android-core:8.43.0'
}In your AndroidManifest.xml, add a meta-data entry configuring the Sentry DSN for your application:
<application ...>
<meta-data android:name="io.sentry.dsn" android:value="https://<token>@crash-reports.kde.org/<app-id>"/>
</application>And finally, remove the build system and preprocessor conditions excluding KCrash use on Android. Note that verifying this part is crucial, without KCrash you’ll get the aggressive default behavior of Sentry, uploading without user consent.
Inhibition
Earlier this year KGuiAddons got a new API for inhibiting system actions such as locking the screen. The obvious usecase for this is a video player, but e.g. Itinerary uses this as well for ensuring your screen stays on while showing a barcode to be scanned at a ticket check.
Android platform support for this has also been added (MR 203), allowing the removal of corresponding code in applications.
Outlook
While all of that is good progress, things are likely about to change. Later this year Google is planning to roll out measures making it significantly harder to provide and install applications on Android.
For more information check out Keep Android Open, a campaign supported by the KDE e.V. among many other organizations.
Regardless of how this will eventually materialize, the direction is clear, Android isn’t going to be a viable long-term platform for FOSS software, not even in its Google-free form. I have mostly considered it a stop-gap solution until Linux on the phone is ready anyway, so this is another reason to increase the effort into that direction.
ngraham
GSoC
