Qt 5.13.1 Android 32+64 Bit
-
to fullfill Google Play Requirement to deliver Apps for 32+64 Bit Support we must build 2 different APKs.
To add both APKs to Google Play each must have a different Version Code
I'll use this scheme:per ex. Version Name:
1.2.3Version Code:
210010203 (32 Bit APK for armeabi-v7a)
211010203 (64 Bit APK for arm64-v8a)where
21 Min API
0 = 32 Bit, 1 = 64 Bit
01 Major Version 1
02 Minor Version 2
03 Patch Version 3then I build releases for both architectures and upload both APK to Google Play (Betatester)
anything else to watch ?
thx -
Hi Ekke,
Did you already saw this blog post about how to comply with the new Google Play requirements ?
It's pretty nice and thorough.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Hi Ekke,
Did you already saw this blog post about how to comply with the new Google Play requirements ?
It's pretty nice and thorough.
@SGaist Hi, thx mentioning that blog post. forgot about it - so many customer projects ;-)
-
to fullfill Google Play Requirement to deliver Apps for 32+64 Bit Support we must build 2 different APKs.
To add both APKs to Google Play each must have a different Version Code
I'll use this scheme:per ex. Version Name:
1.2.3Version Code:
210010203 (32 Bit APK for armeabi-v7a)
211010203 (64 Bit APK for arm64-v8a)where
21 Min API
0 = 32 Bit, 1 = 64 Bit
01 Major Version 1
02 Minor Version 2
03 Patch Version 3then I build releases for both architectures and upload both APK to Google Play (Betatester)
anything else to watch ?
thx@ekkescorner That looks good. The only thing I would suggest is that if you ever anticipate having different versions for other device features such as screen size or multitouch, you'd want to reserve some digits for that. You've probably already read this, but here's a good article explaining version codes:
https://developer.android.com/google/play/publishing/multiple-apks#VersionCodes
-
@ekkescorner That looks good. The only thing I would suggest is that if you ever anticipate having different versions for other device features such as screen size or multitouch, you'd want to reserve some digits for that. You've probably already read this, but here's a good article explaining version codes:
https://developer.android.com/google/play/publishing/multiple-apks#VersionCodes
@Tom_H yes - I have read this.
Don't think that I'll have different builds for screen sizes. In my apps at startup I test if it's a small device, normal device or a tablet or so and then for some pages use different QML. this is easy with Loaders source.for my version code: will slightly change and use the 32/64 bit indicator as last digit
-
@Tom_H yes - I have read this.
Don't think that I'll have different builds for screen sizes. In my apps at startup I test if it's a small device, normal device or a tablet or so and then for some pages use different QML. this is easy with Loaders source.for my version code: will slightly change and use the 32/64 bit indicator as last digit
for my version code: will slightly change and use the 32/64 bit indicator as last digit
I don't think that's a good idea. I think you had it right the first time. CPU architecture is one of the Google Play Filters, and therefore should be in a more significant digit than the major.minor.patch number, which should come last. If you put it last, then it would be possible for the 32 bit version to have a higher version code than the 64 bit version (e.g. you patch the 32 bit version), and then compatible 64 bit devices would get updated with the 32 bit version (because it's compatible and has a higher version code). At least that's how I understand it.
-
for my version code: will slightly change and use the 32/64 bit indicator as last digit
I don't think that's a good idea. I think you had it right the first time. CPU architecture is one of the Google Play Filters, and therefore should be in a more significant digit than the major.minor.patch number, which should come last. If you put it last, then it would be possible for the 32 bit version to have a higher version code than the 64 bit version (e.g. you patch the 32 bit version), and then compatible 64 bit devices would get updated with the 32 bit version (because it's compatible and has a higher version code). At least that's how I understand it.
@Tom_H hmmm - seems you're right.
I was confused because most examples out there are using the last digit - even https://www.qt.io/blog/2019/06/28/comply-upcoming-requirements-google-playAre you using it this way ?
So it's no problem for Google Play to publish VersionCodes lower than existing ones ? (using your example to publish a 32 bit update where a 64 bit with higher Version Code already exists)on the other side:
if I always publish 32 + 64 bit together, using the last digit should work -
@Tom_H hmmm - seems you're right.
I was confused because most examples out there are using the last digit - even https://www.qt.io/blog/2019/06/28/comply-upcoming-requirements-google-playAre you using it this way ?
So it's no problem for Google Play to publish VersionCodes lower than existing ones ? (using your example to publish a 32 bit update where a 64 bit with higher Version Code already exists)on the other side:
if I always publish 32 + 64 bit together, using the last digit should work@ekkescorner I'm using a very simple scheme that works for me so far but could get me in trouble later. My app only has two APKs, one for 32 bit and one for 64 bit. My 32 bit version code starts at 1 and my 64 bit starts at 1000.
on the other side:
if I always publish 32 + 64 bit together, using the last digit should workSure, but still ... don't do it :) I have already had to patch my 64 bit version (because of this issue https://forum.qt.io/topic/105928/rotationsensor-busted-in-qt-5-13/8). It could have very easily been the other way around.
-
@ekkescorner I'm using a very simple scheme that works for me so far but could get me in trouble later. My app only has two APKs, one for 32 bit and one for 64 bit. My 32 bit version code starts at 1 and my 64 bit starts at 1000.
on the other side:
if I always publish 32 + 64 bit together, using the last digit should workSure, but still ... don't do it :) I have already had to patch my 64 bit version (because of this issue https://forum.qt.io/topic/105928/rotationsensor-busted-in-qt-5-13/8). It could have very easily been the other way around.
@Tom_H so you published successfully
32 bit: version code 1
64 bit: version code 1000then later:
32 bit: version code 2 -
@Tom_H so you published successfully
32 bit: version code 1
64 bit: version code 1000then later:
32 bit: version code 2@ekkescorner Yes. I'm up to version 4 and 1003 now. I had originally intended for the 64 bit code to just be
32-bit-code+1000but I got away from that. Now I just bump each release version by 1 and keep track of any notes in a text file in case I get confused :) -
@ekkescorner Yes. I'm up to version 4 and 1003 now. I had originally intended for the 64 bit code to just be
32-bit-code+1000but I got away from that. Now I just bump each release version by 1 and keep track of any notes in a text file in case I get confused :)@Tom_H thx. then I'll use my first VersionCode scheme. thanks for your input.
ekke ... Qt Champion 2016 | 2024 ... mobile business apps
5.15 --> 6.8 https://t1p.de/ekkeChecklist
QMake --> CMake https://t1p.de/ekkeCMakeMobileApps -
@Tom_H thx. then I'll use my first VersionCode scheme. thanks for your input.
@ekkescorner BTW: finally I'll use this version code:
Version Name: 1.2.3
Version Code:
210001023 (32 Bit APK for armeabi-v7a)
211001023 (64 Bit APK for arm64-v8a)where
21 Min API
0 = 32 Bit, 1 = 64 Bit
0 (reserved for screensizes)
01 Major Version 1
02 Minor Version 2
3 Patch Version 3
