This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
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 ***

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