Qt 6 with CMake for Android. How?
-
wrote on 26 Jan 2023, 09:34 last edited by
Hello all!
Is there any example of using Java native code with CMake for Qt 6 Application? The example "Qt Android Notifier" from Qt Creator official examples using QMake. Haven't found any of it yet.
The second question - Is there Android Extras Ok with Qt 6 now? There were a lot of troubles before.
-
wrote on 26 Jan 2023, 13:27 last edited by KenAppleby 0
I can't offer an example but after a day or three of wandering in the dark I can offer a few beginners' tips for CMake for Android apps in Qt6.4. I hope they are helpful.
-
let QtCreator create the initial CMakeLists.txt file for an executable, not a library. I.e. don't handcraft one.
-
use Ninja generator, not Ninja Multi-Config or Makefile: with Ninja Multi-Config the Ninja makefiles contain a syntax error.
-
if it complains that ANDROID_PLATFORM is not set, add it to the "Initial Configuration" and set it to the SDK version, e.g. 33.
-
make sure the CMakeLists.txt contains:
set_property(TARGET <yourexecutable> APPEND PROPERTY QT_ANDROID_PACKAGE_SOURCE_DIR
${CMAKE_CURRENT_SOURCE_DIR}/android) -
to avoid a build failure "No target architecture defined in json" make sure that under the Project Run wizard you have the executable selected as the run target, not a library.
-
sign the package
After that it seems best to conform to the Android pattern of Activity-Intent-Action and making use of the JNI for C++ to Java and
Java to C++ calls. But beware the problem with native (Java to C++) calls when your app is closed. See my earlier post.I switched to CMake from qmake because it seems that .aab bundles containing executables for multiple ABIs can only be generated using
CMake. I found CMake to be confusing at first, but once up and running it is far more efficent, fast and less error-prone.To generate the multi-abi .aab, set the QT_ANDROID_BUILD_ALL_ABIS variable and check "Build Android App Bundle" in the project build settings under "Build Android APK". Leave single values for the QT_ANDROID_ABIS and ANDROID_ABI Cmake variables.
I believe the way the .aab build works is to build the one APK for the selected ABI and also build the android .so libraries for all other architectures it can find support for in your Qt installation. The latter are then included in the .aab together with the principal APK one.
Android Studio's new logcat tool is very useful for seeing Log and qDebug/sDebug output. You can now easily filter the output to see that from your app only.
On your second question: Android Extras is useful as a reference, but I think it's better to follow Qt and use the 6.2+ QQJniObject, QJniEnvironment et al.
-
-
I can't offer an example but after a day or three of wandering in the dark I can offer a few beginners' tips for CMake for Android apps in Qt6.4. I hope they are helpful.
-
let QtCreator create the initial CMakeLists.txt file for an executable, not a library. I.e. don't handcraft one.
-
use Ninja generator, not Ninja Multi-Config or Makefile: with Ninja Multi-Config the Ninja makefiles contain a syntax error.
-
if it complains that ANDROID_PLATFORM is not set, add it to the "Initial Configuration" and set it to the SDK version, e.g. 33.
-
make sure the CMakeLists.txt contains:
set_property(TARGET <yourexecutable> APPEND PROPERTY QT_ANDROID_PACKAGE_SOURCE_DIR
${CMAKE_CURRENT_SOURCE_DIR}/android) -
to avoid a build failure "No target architecture defined in json" make sure that under the Project Run wizard you have the executable selected as the run target, not a library.
-
sign the package
After that it seems best to conform to the Android pattern of Activity-Intent-Action and making use of the JNI for C++ to Java and
Java to C++ calls. But beware the problem with native (Java to C++) calls when your app is closed. See my earlier post.I switched to CMake from qmake because it seems that .aab bundles containing executables for multiple ABIs can only be generated using
CMake. I found CMake to be confusing at first, but once up and running it is far more efficent, fast and less error-prone.To generate the multi-abi .aab, set the QT_ANDROID_BUILD_ALL_ABIS variable and check "Build Android App Bundle" in the project build settings under "Build Android APK". Leave single values for the QT_ANDROID_ABIS and ANDROID_ABI Cmake variables.
I believe the way the .aab build works is to build the one APK for the selected ABI and also build the android .so libraries for all other architectures it can find support for in your Qt installation. The latter are then included in the .aab together with the principal APK one.
Android Studio's new logcat tool is very useful for seeing Log and qDebug/sDebug output. You can now easily filter the output to see that from your app only.
On your second question: Android Extras is useful as a reference, but I think it's better to follow Qt and use the 6.2+ QQJniObject, QJniEnvironment et al.
@KenAppleby-0 thx sharing this. will need these kind of infos later when moving from qmake to cmake. just preparing my 5.15 apps for Qt6.
-
-
I can't offer an example but after a day or three of wandering in the dark I can offer a few beginners' tips for CMake for Android apps in Qt6.4. I hope they are helpful.
-
let QtCreator create the initial CMakeLists.txt file for an executable, not a library. I.e. don't handcraft one.
-
use Ninja generator, not Ninja Multi-Config or Makefile: with Ninja Multi-Config the Ninja makefiles contain a syntax error.
-
if it complains that ANDROID_PLATFORM is not set, add it to the "Initial Configuration" and set it to the SDK version, e.g. 33.
-
make sure the CMakeLists.txt contains:
set_property(TARGET <yourexecutable> APPEND PROPERTY QT_ANDROID_PACKAGE_SOURCE_DIR
${CMAKE_CURRENT_SOURCE_DIR}/android) -
to avoid a build failure "No target architecture defined in json" make sure that under the Project Run wizard you have the executable selected as the run target, not a library.
-
sign the package
After that it seems best to conform to the Android pattern of Activity-Intent-Action and making use of the JNI for C++ to Java and
Java to C++ calls. But beware the problem with native (Java to C++) calls when your app is closed. See my earlier post.I switched to CMake from qmake because it seems that .aab bundles containing executables for multiple ABIs can only be generated using
CMake. I found CMake to be confusing at first, but once up and running it is far more efficent, fast and less error-prone.To generate the multi-abi .aab, set the QT_ANDROID_BUILD_ALL_ABIS variable and check "Build Android App Bundle" in the project build settings under "Build Android APK". Leave single values for the QT_ANDROID_ABIS and ANDROID_ABI Cmake variables.
I believe the way the .aab build works is to build the one APK for the selected ABI and also build the android .so libraries for all other architectures it can find support for in your Qt installation. The latter are then included in the .aab together with the principal APK one.
Android Studio's new logcat tool is very useful for seeing Log and qDebug/sDebug output. You can now easily filter the output to see that from your app only.
On your second question: Android Extras is useful as a reference, but I think it's better to follow Qt and use the 6.2+ QQJniObject, QJniEnvironment et al.
wrote on 1 Feb 2023, 10:52 last edited by@KenAppleby-0
Another issue:- When testing on more than one target device you have to ensure that only the one physical target device you are currently testing on is available in the "Devices" list. In Edit->Preferences->Devices remove all physical devices except the one you are currently testing on, and make that one the default. The Run configuration seems to stick with a previous default device if it exists in the list, even if it is disconnected. The result is a failure to launch. When you come to swap devices, remove the previous one from the list then add the new one.
-
-
@KenAppleby-0
Another issue:- When testing on more than one target device you have to ensure that only the one physical target device you are currently testing on is available in the "Devices" list. In Edit->Preferences->Devices remove all physical devices except the one you are currently testing on, and make that one the default. The Run configuration seems to stick with a previous default device if it exists in the list, even if it is disconnected. The result is a failure to launch. When you come to swap devices, remove the previous one from the list then add the new one.
@KenAppleby-0 thx for the info. doesn't sound like a smooth workflow ;-) I'm having device lists with 10 or more devices, connected via USB or WiFi, so always deleting all other devices ? ...
Please create a bug report, so we'll get it fixed.
I just created some issues about Managing Android Hardware devices: https://bugreports.qt.io/browse/QTCREATORBUG-28735 and https://bugreports.qt.io/browse/QTCREATORBUG-28736
-
@KenAppleby-0 thx for the info. doesn't sound like a smooth workflow ;-) I'm having device lists with 10 or more devices, connected via USB or WiFi, so always deleting all other devices ? ...
Please create a bug report, so we'll get it fixed.
I just created some issues about Managing Android Hardware devices: https://bugreports.qt.io/browse/QTCREATORBUG-28735 and https://bugreports.qt.io/browse/QTCREATORBUG-28736
wrote on 6 Feb 2023, 15:51 last edited by@ekkescorner I think you have it covered in your first bug report.
So far I have only three physical devices to deal with and it's manageable. I'm just thankful that Qt development for multi-platform projects works as well as it does!
1/6