A lot has happened around bringing KDE applications to Android since I last wrote about that here and spoke about it at Akademy 2021. Here are some of the highlights.

Package Size Optimization

Following the discussion at Akademy we implemented a number of package size optimizations on the Craft level instead of in the individual build systems of the applications, resulting in substantial package size reductions for all apps already using Craft-based builds.

Examples:

  • Changed the Craft blueprints for a number of our 3rd party dependencies to not install API documentations and man pages. OpenSSL was a particular bad offender, putting a few thousand man pages in all our APKs.
  • Create patches for Qt Quick Controls 2 (MR 164) and Qt SVG (MR 156) to allow disabling their Qt Widgets dependencies even if the Qt Widgets library is present. This is necessary as some of our applications actually depend on Qt Widgets, but we don’t want all APKs to have to carry that extra weight.
  • Adjusted various build settings to not build (and thus package) unused Qt plugins, such as unused Qt Quick Controls styles, proprietary Qt Location backends or the QML debugging infrastructure.

Nico estimated the gain of this at about 1 GB for our entire F-Droid repository, some applications lost half their size. There is more that could be done still, but the gains to achieve are probably smaller.

Google Play Automation

Binary Factory can now automatically perform operations on Google Play content:

  • Application metadata (from Appstream files and/or Fastlane data) is updated daily, including image assets and all available translations.
  • Release APK builds are uploaded to the beta release track. Beta releases aren’t automatically created though, as that doesn’t seem possible for our multi-APK setup. With AAB packages this should become possible though.

Producing a new (beta or production) release on the Google Play store is down to a few clicks now with this, you just need to select the APKs that should be part of it.

To make use of this automation, your application needs to be set up on Google Play already and its enabled-projects.yml entry needs to contain the googlePlayId key with the corresponding Google Play application id.

Two more things remain to be done:

  • We need Binary Factory to produce AAB packages, as that’s a requirement for all newly added applications from this month on. Krita already has a solution for this, which hopefully can be generalized.
  • ECM’s Appstream to Fastlane converter needs to also extract release information and produce changelog files out of that. This would then be uploaded together with new packages and thus wouldn’t need to be managed manually in Google Play anymore.

Qt Regressions

Unfortunately we also had to deal with two rather severe regressions in Qt 5.15.2 that affected some of our applications.

The first one is Qt’s file i/o API refusing to read content: URLs on which we only have transient read permissions, despite that actually being perfectly possible. This shows in files not being loaded when opened via e.g. the file manager or Android’s sharing mechanism, rather than via the file dialog. And to make things more tricky, files that at any time before had been loaded via a file dialog have persistent read permissions and can subsequently also opened via other means.

There’s a proposed upstream patch and a pending backport to our Binary Factory builds. Affected apps are Okular and Itinerary at least.

The second issue is QTimeZone::id() returning a human readable timezone name rather than the expected IANA timezone identifier. That is particularly problematic when this method is used to persist timezone information and later load them again. The loading code is then confronted with timezone names rather than IANA identifiers and fails to associate that with the correct timezone, leading to data loss.

This is fixed in Qt6, the corresponding patches have been backported to the Binary Factory builds. Affected apps are Calindori and Itinerary.

Craft on Android

While previous work on Craft for Android focused on use in automatic builds, the interactive local use has been catching up as well now. In combination with an updated KDE Android Docker SDK image this is now rather straightforward.

One type setup:

docker pull kdeorg/android-sdk
docker run -ti --rm -v <your persistent craft path>:/home/user/CraftRoot kdeorg/android-sdk craft-bootstrap

Executing Craft commands:

docker run -ti --rm -v  <your persistent craft path>:/home/user/CraftRoot kdeorg/android-sdk craft -p itinerary

The lengthy docker command isn’t very convenient, but it’s constant all the time, so you can define a simple shell alias for that, at which point using Craft for Android becomes almost indistinguishable from local use for the host platform.

For more details, see also the Craft on Android wiki.

There is one thing to keep in mind still though: Craft’s default configuration and the configuration used on Binary Factory aren’t fully aligned yet. This can result in different local results, or even in build issues. There’s a number of pending patches to bring this closer together, but you might still need to adjust your local settings a bit to those of Binary Factory, by editing Craft’s configuration file or by using the craft --set command.

Ideally we manage to resolve those differences eventually, but some of the Binary Factory settings are very specific to KDE’s use and might not be appropriate as a general default.

KDE Frameworks on Android

A number of patches have been integrated to make KJobWidgets, KIO and KParts build without D-Bus on Android, and another change for KIO is still in review. Up to now those frameworks required a D-Bus stub library in order to build.

This doesn’t really change anything regarding actual functionality though, but that is secondary for now, as those frameworks mainly act as porting aids on Android, which we need e.g. in order to build Okular. It’s an important step forward nevertheless, as the D-Bus stub library isn’t available in the new Craft-based development environment.

This also clears the path towards ideas to turn some parts of KIO into a proper platform abstraction API.

Contribute

If you are interested in bringing KDE software to Android, make sure to join the #kde-android channel on Matrix or IRC, as well as the kde-android mailing list. There isn’t just development on the application or library level to be done, but also plenty of things to work on in the build and delivery automation.