Bug 24809 - Add support for manifest merging when using Android libraries
Summary: Add support for manifest merging when using Android libraries
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.18.1
Hardware: PC Windows
: --- normal
Target Milestone: 5.1
Assignee: Atsushi Eno
Depends on:
Reported: 2014-11-25 11:46 UTC by Matt Setzer
Modified: 2018-08-18 06:51 UTC (History)
7 users (show)

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:

Description Matt Setzer 2014-11-25 11:46:23 UTC
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.
Comment 1 Atsushi Eno 2014-11-26 22:20:46 UTC
Could you give us example use of it? I have never seen that before.
Comment 2 Matt Setzer 2014-11-29 12:12:16 UTC
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.
Comment 3 Atsushi Eno 2014-12-05 15:10:31 UTC
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.

[master fd64098]
Comment 4 Alexander Melchers 2017-06-12 15:37:22 UTC
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" />
  <application android:name="md505582b778bb7146a6644c06482d93fc7.MyAppClass">
    <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.

Best regards,
Comment 5 Reuben Tanner 2018-02-06 20:55:47 UTC
Bump - this is a highly desirable feature for my team as well.