Version code numbering

[mjames]

I just tried to push an update to the Play Store, and got this error You can’t rollout this release because it doesn’t allow any existing users to upgrade to the newly added app bundles.

I did some research, and it seems that this often shows up when the Version Code numbering is out of order.

Indeed, I checked things and found that:

1. The previous release (from May) had Version Code number 9005. Inside of SAB I had set it as “5”, so somehow the program also added on a 9000. I take it this helps keep different architectures separate, though that no longer seems necessary with .aab bundles.
2. The new version I created had number 2006. The “6” was set inside SAB, but I don’t know where the 2000 came from.
3. If I uncheck Generate device-specific APKs to reduce the APK size inside of SAB, then the version I upload just is “6” with no thousands.

Is there any way to go back to using the 9000 number? Or, if not, is there anyway to convince the Play Store to accept a new bundle which is out-of-order?

[csiandal]

Similarly, I encountered the issue of prefixing the build version with “20,” “30,” “80,” “90,” and so on. For the App Bundle, the build number was prefixed with “20.” For example, if my build version was 12, the generated build version came up with “2012.”

This issue has not been resolved in SAB version 11.0.4 yet.

In the screenshot below, my build version was 5.

There are also other issues, such as asset packages not including audio packages, drawer images, and so on. I hope that they are incrementally fixing and releasing it.

[mjames]

There is logic behind the numbering. I was actually working on this today, tearing apart the .aab file to see if I could fix the problem manually since no one has given a solution, and I saw the code which defined how it’s set up. I can’t remember where I saw it, and it doesn’t seem worth going back and looking for.

The idea is that each different architecture (arm, arm64, x86, etc) gets its own thousand number, so that you can update each architecture on the Play Store and don’t have to worry about the number from one architecture overlapping with a different one.

But I thought that we could no longer upload .apks to the Play Store, which makes me wonder why you’re seeing what you’re seeing.

And, as far as I know, the .aab files should have been getting their consistent thousand numbering. So I don’t understand why previously my .aab files were in the 9000s and now they’re in the 2000s.

[ChrisHubbard]

History

Before Android App Bundles (AABs), the recommended way to reduce the file size of an APK, especially if you had large native-code libraries included (like FFmpeg or GeckoView), was to build multiple APKs.

Although it is better to build a single APK to support all your target devices whenever possible, that might result in a very large APK due to files supporting multiple screen densities or Application Binary Interfaces (ABIs). One way to reduce the size of your APK is to create multiple APKs that contain files for specific screen densities or ABIs.

There was support in the Gradle build system to build multiple APKs. To publish these apps on Google Play, each would have its own version code. To do it correctly, each ABI (e.g. armabi-v7a, arm64-v8a, x86, x86_64) needs its own versionCode range.

The recommendation was to separate them by about 1000 numbers. App Builders uses this starting number for these ABIs

• ‘armeabi’: 1000
• ‘armeabi-v7a’: 2000
• ‘arm64-v8a’: 3000
• ‘mips’: 5000
• ‘mips64’: 6000
• ‘x86’: 8000
• ‘x86_64’: 9000

When it builds multiple APKs, then it builds for x86, armeabi-v7a, x86_64, arm64-v8a. So if you specify 5 as the versionCode in the AppBuilder with building multiple APKs, then you will get:

• armeabi-v7a at 2005
• arm64-v8a at 3005
• x86 at 8005
• x86_64 at 9005

Any time that you release a new version, there has to be a new APK with a versionCode higher than each of these ranges so that upgrades can happen on the device.

Android App Bundles

Now that we have AABs, Google Play can repackage an APK¹ specific to the hardware platform and version of Android being downloaded to. There is no need for Multiple APKs.

So how do you switch from Multiple APKs to AABs? I don’t know for sure, but I have a reasonable guess. I suspect that if you use a versionCode larger than any of the existing multiple APKs that have been published to Google Play, then it should work. Unfortunately, the App Builders code has min=1 and max=1000 for version code. So I will have to talk to @richard about this. From Android documentation on versioning states:

Note: The greatest value Google Play allows for versionCode is 2100000000.

As a work-around, you can set the versionCode in the .appDef manually (while SAB is closed) and then open the project in SAB and build it.

  <version code="9006" name="11.0.4"/>

If you want, I can work with you to experiment with your project. Contact me at via email.

Chris Hubbard (chris_hubbard@sil.org)

Endnotes

¹Technically, some versions of Android allow the app to be delivered as multiple APKs. So with older versions of Android it will be delivered as a single Single APK optimized to the ABI and screen size of the device. On newer versions of Android, it. will be delivered as multiple APKs.

[mjames]

Thank you. With a bit of experimentation, the manually editing the .appDef file worked and I can finally upload files on Google Play (in time for the Nov 1st deadline).

---

I use GeckoView, and as a result I’ve used the ‘multiple apk’ option for a long time. I’ve now discovered that if I leave the ‘multiple apk’ option checked, then my .aab files get 2000 added to the version code… I discovered this after manually setting the code to ‘9035’ but it then showing up as ‘11035’. If I un-check the multiple apk box, then the version code is whatever the .appDef file says (so no extra thousands added on).

Based on my Play story history, I suspect that leaving the ‘multiple apk’ option checked used to add on 9000, not 2000, and that the code somehow changed in the past few months.

What I think should happen:

1. Checking or un-checking the ‘multiple apk’ box shouldn’t affect .aab bundles either way. You should get the same result in both cases.
2. Future versions of SAB need to have a way to deal with this, so that I don’t have to manually set the version code of all the different apps I build.
   a) My first suggestion would be to have all .aab files have a version code number with 10,000 added on. This seems like it would overrule all previous versions. I can’t think of any backward compatibility problem this would cause for anyone else, but that does need to be considered very carefully.
   b) A second option would be to allow people like me, who actually have this problem, to manually set the number inside of SAB and to overrule all hidden adjustments (of adding on extra 1000s).

What I don’t understand is how I’m the first person running across this problem.

[ChrisHubbard]

You should only have one AAB. There is no point in having multiple AABs. These build strategies (Multiple APKs by ABI and AAB) are two mutually exclusive way of dealing with the problem of large APK size.

So you should uncheck the “Generate device-specific APKs to reduce the APK size” and build an AAB. When building an AAB, it doesn’t use adding of thousands (if it does, then it is a bug – I just tested it and it didn’t for me).

[mjames]

My point is that I shouldn’t have to check or uncheck the button when building AABs. It should build the exact same AAB file regardless of that particular checkbox.

I do have the button checked when testing, since I send the apks to people for testing (although, admittedly, I do this less and less now that this particular app has a good beta testing area in the Play Store). I leave this box checked out of laziness, not because I think it’s going to affect the AAB build (which, obviously, doesn’t ever result in multiple AABs).

Based on your reply, I think there is a bug. IF the button is checked, then I’m getting an AAB with version numbering in the 2000s.