Target api lvl 29 or 30 impossible
-
@antoinnneee what version of QTCreator do you use?
-
@J-Hilk
I'm on the last updated version of QtCreatorfrom about QtCreator :
Qt Creator 4.13.3 Based on Qt 5.15.2 (GCC 5.3.1 20160406 (Red Hat 5.3.1-6), 64 bit) Built on Nov 13 2020 12:29:31 From revision 524cad144a
and for the kit, I use 5.15.2 (5.15.1 on windows)
-
Edit androidmanifest manual
-
@NullByte I already try that, change nothing to the problem, Qt still build apk with api28
-
I just encountered this same problem. I am using:
Ubuntu 18.04.5 LTS
Qt version 5.15.0I spent the better part of a day trying to figure this out.
In the end, the only thing that worked was:
- Take the
build.gradle
that was generated by Qt during my builds... - Make a copy of that
build.gradle
and add it to my sources - Edit the
build.gradle
This is now part of my
*.pro
script:android { DISTFILES += \ $$top_srcdir/src/lib/android/AndroidManifest.xml \ $$top_srcdir/src/lib/android/build.gradle ANDROID_PACKAGE_SOURCE_DIR = $$top_srcdir/src/lib/android }
And this is the part of the
build.gradle
that I had to hand edit to target 29:defaultConfig { resConfig "en" minSdkVersion = qtMinSdkVersion targetSdkVersion = 29 }
- Take the
-
For further reference, here is the
build.gradle
from the Qt framework as of the commitba3b53cb5
(which is the tag for v5.15.0):The only part that I changed (as shown in my prior post) was to replace
qtTargetSdkVersion
with my hardcoded 29. -
@KH-219Design Thank a lot, today you're my hero, I owe you a good beer :)
I was really close to debug the probleme, I change in graddle file the build tools, but i did not notice the defaultConfig part (only change buildToolsVersion)
Can you report the problem to Qt bugtracker? I've a a weak english, I thinks you will write the report so much better than me
thanks again
-
@antoinnneee I will bask in my heroic light today. Thanks for sharing the good news!
I have set a reminder for myself to visit Qt bugtracker later today and report this (after checking against duplicate reports, of course).
I suppose I was never 100% confident which part of this was "buggy", and which part (possibly all parts?) are just "works as intended." But since others are also finding this frustrating, it seems to deserve at least a conversation over at bugreports.qt.io ... even if it only needs fixing in the documentation.
I'll come back here and paste a link to any relevant bug report that happens, so you can follow it (and perhaps add detail to it), too.
-
@antoinnneee I went to open a bug ticket just now, but I am still hesitating.
As frustrating as this problem was for me (and for you), I'm not sure that the Qt team would call it a bug.
Quoting from here:
https://doc.qt.io/qt-5/deployment-android.html#android-package-templatesThe default templates used by Qt are found in $Qt_install_dir/src/android/templates. The first step of making a custom package is to copy these files into an empty directory, for example android, under your project. Then, you need to define that path in your project's .pro file, using the variable ANDROID_PACKAGE_SOURCE_DIR:
android { ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android DISTFILES += \ android/AndroidManifest.xml \ android/build.gradle \ android/res/values/libs.xml }
^^ The above seems to encourage us to declare our own
build.gradle
for every project we create.Another bit of "evidence":
The Qt Change log for 5.15 says:
https://wiki.qt.io/New_Features_in_Qt_5.15#Platform_ChangesMove minSdkVersion & targetSdkVersion from AndroidManifest.xml to build.gradle
Based on that change log and the "deployment-android.html" document, it seems like what you and I found as a kind of "desperate workaround" is actually just the intended way of doing things.
Do you disagree? I am open to hearing other interpretations!
I often feel that tasks I accomplish in my qmake-related "pro" files are guided by a weird sorcery of reading the forum, reading the docs, reading StackOverflow, doing my own guess-work, etc etc etc.
It seems that the Qt docs definitely have notable gaps. However, in the case of Android I have more tolerance of this than I normally would, because in this case Qt is struggling with the difficult task of keeping up with constant API changes from Android. It seems that we got caught off guard by a new way to specify
targetSdkVersion
, but I'm not sure what Qt could have done better other than maybe call me up personally and warn me. (I probably would have ignored an email!) -
@KH-219Design Ok, I've better understanding of the issue. But i don't think it's a good idea to have a android version that you can't directly upload on the store. Also i was able to build an api28 apk without api28 installed, that really weird. I thinks QtCreator need an combobox to select the version that really chose the version.
It's not normal to select android build SDK android-30 in the Build Steps and at the end build a sdk is 28. A minimal patch is to add a warning in this page to say "the real version is in template, build.graddle"
Also, in the gradle file, we have a warning commentary that say variable are define in the gradle.properties. A file that is not generate with the template. In addition the comment advise us against manually modification. It doesn't seem coherent to me
/******************************************************* * The following variables: * - androidBuildToolsVersion, * - androidCompileSdkVersion * - qt5AndroidDir - holds the path to qt android files * needed to build any Qt application * on Android. * * are defined in gradle.properties file. This file is * updated by QtCreator and androiddeployqt tools. * Changing them manually might break the compilation! *******************************************************/
-
@antoinnneee said in Target api lvl 29 or 30 impossible:
Ah ha. Ok. This part 100% sounds like a bug to me:
- It's not normal to select android build SDK android-30 in the Build Steps and at the end build a sdk is 28.
I am in favor of logging that as a bug.
But I am not a Qt Creator user.
I am not joking or exaggerating when I say I have never launched Qt Creator, not even once. My qmake
*.pro
files are all maintained by hand in raw text, without using the Qt Creator GUI. I run a build using bash scripts, and my teammates all use a variety of editors of their choosing (Emacs, Vim, Sublime, Visual Studio Code).I'd encourage you to file a Qt Creator bug. Your english is stronger than you give yourself credit for! Besides, I think a lot of the Qt team does not have english as a first language.
If you do open a bug ticket, paste a link here. I'd love to follow what they have to say on this.
-
@KH-219Design I use a lot Qt, since 3years it's my favorite IDE, there is a lot of small tools that help a lot. I think a never write a qt program without qtCreator, I also use it to write non-Qt C++ program.
I made the report, here is the link : link
-
@antoinnneee thank you for doing that! I just read the bug report, and the response over there from Assam.
I agree that the advice to use
ANDROID_TARGET_SDK_VERSION = 29
in the "*.pro" file is easier than adding a gradle file.Did that work for you? I have a vague recollection that
ANDROID_TARGET_SDK_VERSION
was something that I tried along my experimentation route, and that it did not succeed for me. But I no longer fully trust my recollection (this was a couple months ago). I wonder if that also requires 5.15.2 or higher (I am using 5.15.0)Next time I deploy my Android app I will experiment some more. Thanks for all this collaboration!
-
@KH-219Design Android devlopment is not my main activity. I'm an embbeded devlopper, just making sometimes app to control our devices. I'll test this solution when I have more time. I've a ton of work more important than test this for now. I'll give a feedback when I have do the test. Maybe next week or this weekend.
thanks you too for all ;)
-
Just going to add some more recent information to this post.
As of February 2024, this problem still exists.Adding the following to the CMakeLists.txt file is only part of the solution:
set_target_properties(YourProjectName PROPERTIES QT_ANDROID_TARGET_SDK_VERSION "34" )
I'm not even sure if this is necessary. It looks like SDK 33 is the default.
But the real issue is that the API version isn't getting set by whatever scripting magic is happening under the hood.I had to modify the build.gradle file as follows:
defaultConfig { resConfig "en" // minSdkVersion qtMinSdkVersion // targetSdkVersion qtTargetSdkVersion minSdkVersion 33 targetSdkVersion 33 ndk.abiFilters = qtTargetAbiList.split(",") }
I would appear that the qtMinSdkVersion and qtTargetSdkVersion are being set to version 23 which isn't supported by the Google Play Store console. Of course, I agree that Android is a mess. The fact that there's no way to know what API version is being used until you upload it is a pain. There probably is a way to inspect the .aab file but I didn't have time to look for one. Then, there's the annoying user-interface on the Play Store console where it's a challenge to find where to actually delete an aab file. It's not in the Release screen where it should be.