Bug 59374 - Generate one package per seleted ABI sets incorrect android:versionCode in AndroidManifest
Summary: Generate one package per seleted ABI sets incorrect android:versionCode in An...
Status: RESOLVED INVALID
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 7.4 (15.3)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2017-09-09 15:27 UTC by softlion
Modified: 2017-09-11 10:17 UTC (History)
3 users (show)

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

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.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Description softlion 2017-09-09 15:27:57 UTC
After ticking the "Generate one pavkage (.apk) per selected ABI in VS2017, and building, 5 apk are generated.
But these APK have incorrect version codes.


My AndroidManifest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:installLocation="auto" package="com.cosmoconnected.cosmoconnected" android:versionCode="7" android:versionName="0.1">



The generated AndroidManifest.xml file in obj/release/android/arm64-v8a/

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:installLocation="auto" package="com.xxx.xxx" android:versionCode="262151" android:versionName="0.1">


When archiving and publishing the package to Google Play, it fails because of these package version.


Could you please give a workaround fast ?
Ty.
Comment 2 softlion 2017-09-09 15:36:38 UTC
Plz could you make the previous comment private ?
ty.
Comment 3 softlion 2017-09-10 07:57:29 UTC
In fact there is an issue with this system:

i was able to generate a set of 4 apks, and using the publish feature of VS2017 it created 4 apks with 4 different version numbers, not matching the version code scheme recommanded by Google there: https://developer.android.com/google/play/publishing/multiple-apks.html


But when generating an update to this set, Xamarin uses the same version number, thus making publishing on Google Play impossible.


I've tryed to change the "base" version number from 6 to 7 in android manifest with no luck.


Any workaround plz ?
Comment 4 softlion 2017-09-10 07:58:30 UTC
So Xamarin should use the version code scheme described in the above article:


**Using a version code scheme**

In order to allow different APKs to update their version codes independent of others (for example, when you fix a bug in only one APK, so don't need to update all APKs), you should use a scheme for your version codes that provides sufficient room between each APK so that you can increase the code in one without requiring an increase in others. You should also include your actual version name in the code (that is, the user visible version assigned to android:versionName), so that it's easy for you to associate the version code and version name.

Note: When you increase the version code for an APK, Google Play will prompt users of the previous version to update the application. Thus, to avoid unnecessary updates, you should not increase the version code for APKs that do not actually include changes.

We suggest using a version code with at least 7 digits: integers that represent the supported configurations are in the higher order bits, and the version name (from android:versionName) is in the lower order bits. For example, when the application version name is 3.1.0, version codes for an API level 4 APK and an API level 11 APK would be something like 0400310 and 1100310, respectively. The first two digits are reserved for the API Level (4 and 11, respectively), the middle two digits are for either screen sizes or GL texture formats (not used in these examples), and the last three digits are for the application's version name (3.1.0). Figure 1 shows two examples that split based on both the platform version (API Level) and screen size.


Figure 1. A suggested scheme for your version codes, using the first two digits for the API Level, the second and third digits for the minimum and maximum screen size (1 - 4 indicating each of the four sizes) or to denote the texture formats and the last three digits for the app version.

This scheme for version codes is just a suggestion for how you should establish a pattern that is scalable as your application evolves. In particular, this scheme doesn't demonstrate a solution for identifying different texture compression formats. One option might be to define your own table that specifies a different integer to each of the different compression formats your application supports (for example, 1 might correspond to ETC1 and 2 is ATITC, and so on).

You can use any scheme you want, but you should carefully consider how future versions of your application will need to increase their version codes and how devices can receive updates when either the device configuration changes (for example, due to a system update) or when you modify the configuration support for one or several of the APKs.
Comment 5 softlion 2017-09-10 08:01:08 UTC
I would finish with why this is important:

A singke APK of "my" app is 72Mo. The google play store does make user download 72Mo even if the abi is not matching the device hardware.

While with the "multiple apk" option, the download size is shrinked to 21Mo for the same app.

So this is a show stopper bug.
Comment 6 softlion 2017-09-10 08:21:01 UTC
Well sorry, the version numbers are correctly increased by Xamarin.
For any reason, Google Play displays an error after importing it.
But the uploaded files are available in the artefact tab.

Still the version numbers you generate are not following the document defined by Google.
Comment 7 dean.ellis 2017-09-11 09:51:04 UTC
Hey softlion

So you know we implemented a new way of defining version numbers when using Apk per ABI. The old method was, as you said, generating versions which did not follow the recommended google guidelines. 

The new system was committed as part of [1]. The documentation you can take a look at in [2]. Unfortunately this did not make it in to d15-3, but it will be available in d15-4. 

[1] https://github.com/xamarin/xamarin-android/commit/0a2f008c8ac6e031df87209b76d4206bf63508eb#diff-053199a3e946b28cd7012b1c1a648041
[2] https://github.com/xamarin/xamarin-android/blob/master/Documentation/build_process.md#AndroidVersionCodePattern
Comment 8 softlion 2017-09-11 10:17:28 UTC
I missed that ty!