WIP: Support NDK r20 and Qt 5.14
Needs ReviewPublic

Authored by vkrause on Sat, Jan 18, 11:41 AM.
This revision needs review, but there are no reviewers specified.


Maniphest Tasks
T12520: Qt 5.14

This changes from using the toolchain file provided by CMake to using the
one provided by the NDK, as even recent CMake can't build successfully
with r20. However this is a rather invasive change, the interface and
variable names differ.

The Qt 5.14 changes are less risky, as most of this is parallel to the
support for older versions.

Test Plan

Local builds with 5.14/r20, 5.14/r18 work, the Docker SDK isn't tested yet, and there's some remaining issues with 5.13 and older NDKs I don't fully understand yet. The resulting apks with 5.14 install, and work for QQC2 content, but fail to start Kirigami apps.

Diff Detail

R240 Extra CMake Modules
No Linters Available
No Unit Test Coverage
Build Status
Buildable 21315
Build 21333: arc lint + arc unit
vkrause created this revision.Sat, Jan 18, 11:41 AM
Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptSat, Jan 18, 11:41 AM
Restricted Application added subscribers: kde-buildsystem, kde-frameworks-devel. · View Herald Transcript
vkrause requested review of this revision.Sat, Jan 18, 11:41 AM
vkrause retitled this revision from Support NDK r20 and Qt 5.14 to WIP: Support NDK r20 and Qt 5.14.Sat, Jan 18, 11:43 AM
vkrause edited the test plan for this revision. (Show Details)
vkrause added a task: T12520: Qt 5.14.
apol added a subscriber: apol.Sun, Jan 19, 11:21 PM
apol added inline comments.

Why's this better? Or how is it different?

vkrause added inline comments.Mon, Jan 20, 8:45 AM

It's "better" in the way that it actually works with NDK r20, while CMake 3.16 failed to even pass the basic compiler checks. For a toolchain file shipped with a toolchain making adjustments for toolchain changes is of course possible immediately, while with CMake we have to wait for the next release if such changes are necessary.

It's unfortunately different in various variable names as well in some details of what it sets or doesn't set. That's where most of the changes in this file come from.

The main reason we didn't use this right from the start, and probably also the reason the toolchain file in CMake exists is that the NDK didn't have CMake support in older versions.

flherne added a subscriber: flherne.Mon, Feb 3, 1:14 AM

Thanks for this.

ADB log of the Kirigami problem, which results in a blank screen ['gredit' is the name of the app]:

libgredit_arm64-v8a.so: QQmlApplicationEngine failed to load component
libgredit_arm64-v8a.so: qrc:/main.qml:5:1: Type Kg.ApplicationWindow unavailable
libgredit_arm64-v8a.so: file:///data/app/org.qtproject.example.gredit-n9QHCzgETccPFueeH24YPQ==/lib/arm64/ApplicationWindow.qml: No such file or directory

The --Added-by-androiddeployqt-- dir in the APK, which previously contained these QML files, is no longer created.

The file contents now seem to appear in an RCC file at assets/android_rcc_bundle.rcc, but clearly Kirigami isn't understanding this.

Icons packaged by kirigami_package_breeze_icons no longer appear under assets.

I got my Kirigami app to load by patching kirigami.{cpp,h}:

Altered resolveFilePath() to return QStringLiteral("qrc:/android_rcc_bundle/qml/org/kde/kirigami.2/") + path; and similarly for resolveFileUrl().

Added QResource::registerResource(QStringLiteral("assets:/android_rcc_bundle.rcc")); in registerTypes() [Qt is supposed to do this, but perhaps not early enough?]

https://codereview.qt-project.org/c/qt/qtbase/+/270573/24 is the relevant Qt change.

Icons are still broken.
There are probably better ways to solve this.

Excellent news! Could you post your Kirigami patch somewhere maybe? Makes this easier to test here :)

For icons we probably need a similar adjustment, I bet they got affected by the same Qt change. Same for translations I think, in ki18n.

apol added a comment.Sat, Feb 15, 9:41 PM

Patch makes sense to me overall, we could consider landing it.


I did some testing and for me it works for arm64 but not for arm32.