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.
Android libraries may have their own AndroidManifest.xml file describing permissions and settings specific to the components in the library. These settings generally need to get merged into the application AndroidManifest.xml in order for the library to function properly. The Android toolchain has an option to do this automatically, but as near as I've been able to determine there's no similar setting in the Xamarin toolchain, so we have to merge the manifest files manually.
Could you give us example use of it? I have never seen that before.
Here's a link to the docs from the Gradle-based build system; I haven't been able to find anything useful from the Ant-based build system, although there are references to manifest merging scattered throughout the documents.
For an example of a library that declares some properties (although not all of the required properties) see https://github.com/AzureAD/azure-activedirectory-library-for-android. Enabling manifest merge pulls the activity into the application manifest without having to explicitly declare it.
Thanks for the feedback.
Implementing the full spec version of manifest merger is a lot of work, so we have implemented somewhat simplified version of it. Basically, library manifests (when packaged as LibraryProjectZip) are merged, and missing activities in application element are appended to the app manifest.
When we have less important tasks, we would revisit the complete manifest merger.
It will be part of the new features in post-5.0 release.
I would like to re-open this call, since the basic merge functionality that is now available in Xamarin.Android/msbuild has become insufficient as of June 1st, when Google updated its acceptance criteria for submissions to the Google Play Developer Console such that its is no longer permitted to upload a new APK with a manifest file that requests a certain permission more than once.
As Matt describes in the original report, this is due to our using two libraries (NuGet-packages) that include the same permission (in this case ACCESS_COARSE_LOCATION), yet defining the permission request in different ways: the one library requests the permission using the "uses-permission"-element, whereas the other does so by using the "uses-permission-sdk-23"-element (with SDK 23 lying within our supported range of API-levels). Thus resulting in the below (abbreviated) AndroidManifest.xml:
--- AndroidManifest.xml ---
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="myPackage" android:versionCode="0001" android:versionName="0.1" android:installLocation="preferExternal">
<uses-sdk android:minSdkVersion="18" android:targetSdkVersion="23" />
<activity android:name="md505582b778bb7146a6644c06482d93fc7.MainActivity" />
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission-sdk-23 android:name="android.permission.ACCESS_COARSE_LOCATION" />
--- AndroidManifest.xml ---
From the context of our application, the "uses-permission-sdk-23"-request could simply be removed from the Android manifest, as it is already implied by the other permission request. Normally, with a gradle-build, one would do this by:
1. adding a reference to the "tools"-namespace to the manifest root element as such: xmlns:tools="http://schemas.android.com/tools"; and
2. defining a node in the main manifest file to match the node to be removed, and add an attribute 'tools:node="remove"' as such: <uses-permission-sdk-23 android:name="android.permission.ACCESS_COARSE_LOCATION" tools:node="remove" />.
(See https://developer.android.com/studio/build/manifest-merge.html for more information on manifest merging)
Unfortunately, this mechanism does not work at the moment, however. What's more, I've observed MSBuild actually removing the "tools:node"-attribute while leaving the remainder of the element intact, in effect inserting another copy of the unwanted element!
As we can currently no longer upload our App and are stuck in our release cycle, this has now become a critical issue for us (and we are not alone, judging from the rise in StackOverflow-posts covering this topic as of June 1st). We are thus forced to look for a work-around, yet the complex nature of the MSBuild-process makes progress extremely slow going and definitely not suited for a broader audience.
I hope this information is useful to help further investigate and - hopefully - resolve this issue soon.
Bump - this is a highly desirable feature for my team as well.