Bug 51618 - Enabling the "Generate one package per selected ABI" feature produces APKs with random versionCode
Summary: Enabling the "Generate one package per selected ABI" feature produces APKs wi...
Status: RESOLVED DUPLICATE of bug 51620
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild (show other bugs)
Version: 7.0 (C8)
Hardware: Macintosh Mac OS
: High normal
Target Milestone: 15.4
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2017-01-18 18:18 UTC by Keith Rome
Modified: 2017-07-12 22:43 UTC (History)
4 users (show)

See Also:
Tags: bb
Is this bug a regression?: ---
Last known good build:


Attachments
Sample project to demonstrate bug. (48.16 KB, application/zip)
2017-06-23 22:27 UTC, Tom Opgenorth
Details

Description Keith Rome 2017-01-18 18:18:38 UTC
When this option is selected, the IDE does not offer a way to individually assign unique versionCode values to the various output APK manifests. It seems to randomly generate them instead.

Example:
  Setting versionCode ("Version number") in the Android Application options page to "29"
  Enabling "Generate one package (.apk) per selected ABI" in the Android Build options page
  Selecting "armeabi-v7a", "x86", and "arm64-v8a" ABIs to support

In this example, I ended up with three APK files (as expected) with versionCodes of "262173", "196637", "131101" (not expected). The IDE and build process did not prompt for this information at any time.

And of course, if you make the mistake of uploading these to Google Play (even to Alpha or Beta) then this has the potential to completely break any formal version numbering system you might have been using since Google does not allow packages to be deleted (only unpublished). I learned this the hard way :(
Comment 1 MSiccDev 2017-01-19 18:21:48 UTC
I had the same problem. Opted in for the one apk for each abi method, resulting in random version numbers to be thrown in into the single apks. 

As I distributed the archive via Visual Studio, the damage was already done there.

Now I have to manually built the apk for the abis with correct versioning (following this scheme https://developer.xamarin.com/guides/android/advanced_topics/build-abi-specific-apks/#Creating_the_Version_Code_for_the_APK), which means editing the Manifest and the project file manually every time again. Loosing up to an hour because Release builds are taking some time.
Comment 2 Tom Opgenorth 2017-06-23 22:27:04 UTC
Created attachment 23095 [details]
Sample project to demonstrate bug.
Comment 3 Tom Opgenorth 2017-06-23 22:31:15 UTC
Seeing the same issue.  

Steps to duplicate:

1. Open the attached sample. Notice that the versionCode is set to 29, and that "ABI per APK" is selected.
2. In Visual Studio for Mac, select Build > ARchive for Publishing to create the APKS.
3. Examine the versionCode of each APK (I used aapt dump badging NAME_OF_APK.apk).
4  If you examine the output of aapt dump badging, you will see that the versionCode for each APK is different, and not version 29.

Expected result:

The APK would be build with versionCode 29 assigned to it.
Comment 4 dean.ellis 2017-06-26 09:31:22 UTC
At the moment this is by design if you select the "per Abi apk" option.  You can see the code that is executed in [1]

So a version code if 29 will result in 

29 | 5 << 16  = 327709

This is because each apk (per abi) cannot have the same version code. This is a google play restriction. 

That said looking at the docs 65535 is no longer the max value for the version code. 
It is 2100000000 so our code needs to be updated to allow this. 




[1] https://github.com/xamarin/xamarin-android/blob/master/src/Xamarin.Android.Build.Tasks/Utilities/ManifestDocument.cs#L819
[2] https://developer.android.com/studio/publish/versioning.html
Comment 5 Keith Rome 2017-06-26 14:14:01 UTC
If this is by design, then the behavior should be documented clearly and called out as a warning in the project options page. There are very real ramifications to this for app developers (see the final paragraph of the initial report).
Comment 6 Cody Beyer (MSFT) 2017-07-12 22:43:23 UTC

*** This bug has been marked as a duplicate of bug 51620 ***

Notice (2018-05-21): bugzilla.xamarin.com will be switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.

Please join us on Visual Studio Developer Community and GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs and copy them to the new locations as needed for follow-up. The See Also field on each Bugzilla bug will be updated with a link to its new location when applicable.

After Bugzilla is read-only, if you have new information to add for a bug that does not yet have a matching issue on Developer Community or GitHub, you can create a follow-up issue in the new location. Copy and paste the title and description from this bug, and then add your new details. You can get a pre-formatted version of the title and description here:

In special cases you might also want the comments:

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Note You need to log in before you can comment on or make changes to this bug.