Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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 ?
Plz could you make the previous comment private ?
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 ?
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.
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.
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.
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 . The documentation you can take a look at in . Unfortunately this did not make it in to d15-3, but it will be available in d15-4.
I missed that ty!