Android androidmanifest xml merge

Manifest Merging

In this document

See also

With Android Studio and Gradle-based builds, each app can contain manifest files in multiple locations, such as the src/main/ folder for the productFlavor , libraries, Android ARchive (AAR) bundles of Android Library projects, and dependencies. During the build process, manifest merging combines the settings from the various AndroidManifest.xml files included in your app into a single, generated APK manifest file for app packaging and distribution. Manifest settings are merged based on the manifest priority, determined by the manifest’s file location. Building your app merges the manifest elements, attributes, and sub-elements from these manifests for the specified build variant.

Merge Conflict Rules

Merge conflicts occur when merged manifests contain the same manifest element but with a different attribute value that does not resolve based on the default merge conflict rules. Conflict markers and selectors can also define custom merge rules, such as allowing an imported library to have a minSdkVersion higher than the version defined in the other higher priority manifests.

The manifest merge priority determines which manifest settings are retained in merge conflicts, with the settings in higher priority manifest overwriting those in lower priority manifests. The following list details which manifest settings are are the highest priority during the merge process:

• Highest priority: buildType manifest settings
• Higher priority: productFlavor manifest settings
• Medium priority: Manifests in the src/main/ directory of an app project
• Low priority: Dependency and library manifest settings

Manifest merge conflicts are resolved at the XML node and attribute levels based on the following merge rules.

High Priority Element	Low Priority Element	Manifest Merge Result
no attribute	no attribute	no attribute
	attribute set to default	default attribute
	attribute set to non-default	low priority attribute
attribute set to default	no attribute	default attribute
attribute set to non-default		high priority attribute
attribute set to default	attribute set to default	default attribute
attribute set to default	attribute set to non-default	low priority attribute
attribute set to non-default	attribute set to default	high priority attribute
attribute set to non-default	attribute set to non-default	Merge if settings match, otherwise causes conflict error.

Exceptions to the manifest merge rules:

• The uses-feature android:required; and uses-library android:required elements default to true and use an OR merge so that any required feature or library is included in the generated APK.
• If not declared, the elements, minSdkVersion and targetSdkVersion , default to a value of 1. When merge conflicts occur, the value in the higher priority manifest version is used.
• Importing a library with a minSdkVersion value higher than the app’s src/main/ manifest manifest generates an error unless the overrideLibrary conflict marker is used.

Note: If not explicitly declared, the targetSdkVersion defaults to the minSdkVersion value. When no element is present in any manifest or the build.gradle file, the minSdkVersion defaults to 1.

When importing a library with a targetSdkVersion value lower than the app’s src/main/ manifest, the manifest merge process explicitly grants permissions and ensures that the imported library functions properly.

The manifest element only merges with child manifest elements.

The intent-filter element is never changed and is always added to the common parent node in the merged manifest.

Important: After the manifests are merged, the build process overrides the final manifest settings with any settings that are also in the build.gradle file. For more details, see Configuring Gradle Builds.

Merge Conflict Markers and Selectors

Manifest markers and selectors override the default merge rules through specific conflict resolutions. For example, use a conflict marker to merge a library manifest with a higher minSdkVersion value than the higher priority manifest, or to merge manifests with the same activity but different android:theme values.

Merge Conflict Markers

A merge conflict marker is a special attribute in the Android tools namespace that defines a specific merge conflict resolution. Create a conflict marker to avoid a merge conflict error for conflicts not resolved by the default merge rules. Supported merge conflict markers include:

merge Merges attributes when there are no conflicts with the merge rules. The default merge action. replace Replaces attributes in the lower priority manifest with those from the higher priority manifest. strict Sets the merge policy level so that merged elements with same attributes, but different values generate a build failure, unless resolved through the conflict rules. merge-only Allows merge actions for only lower priority attributes. remove Removes the specified lower priority element from the merged manifest. remove-All Removes all lower priority elements of the same node type from the merged manifest.

By default, the manifest merge process applies the merge conflict marker to the node level. All declared manifest attributes default to a strict merging policy.

To set a merge conflict marker, first declare the namespace in the AndroidManifest.xml file. Then, enter the merge conflict marker in the manifest to specify a custom merge conflict action. This example inserts the replace marker to set a replace action to resolve conflicts between the android:icon and android:label manifest elements.

Marker attributes

Conflict markers use tools:node and tools:attr attributes to restrict merge actions at the XML node or attribute level.

The tools:attr markers use only the restrict , remove , and replace merge actions. Multiple tools:attr marker values can be applied to a specific element. For example, use tools:replace=»icon, label, theme» to replace lower priority icon , label , and theme attributes.

Merge conflict marker for imported libraries

The overrideLibrary conflict marker applies to the manifest declaration and is used to import a library even though the library’s values, such as minSdkVersion are set to different values than those in the other higher priority manifests.

Without this marker, library manifest merge conflicts from the values cause the merge process to fail.

This example applies the overrideLibrary conflict marker to resolve the merge conflict between minSdkVersion values in the src/main/ manifest and an imported library manifest.

Note: The default merge process does not allow importing a library with a higher minSdkVersion than the app’s src/main/ manifest unless the overrideLibrary conflict marker is used.

Marker Selectors

Marker selectors limit a merge action to a specific lower priority manifest. For example, a marker selector can be used to remove a permission from only one library, while allowing the same permission from other libraries.

This example uses the tools:node marker to remove the permisionOne attribute, while the tools:selector selector specifies the specific library as com.example.lib1. The permisionOne permission is filtered from only the lib1 library manifests.

Injecting Build Values into a Manifest

Manifest merging can also be configured to use manifest placeholders to inject property values from the build.gradle file into the manifest attributes.

Manifest placeholders use the syntax $ for attribute values, where name is the injected build.gradle property. The build.gradle file uses the manifestPlaceholders property to define the placeholder values.

Note: Unresolved placeholder names in apps cause build failures. Unresolved placeholder names in libraries generate warnings and need to be resolved when importing the library into an app.

This example shows the manifest placeholder $ used to inject the build.gradle applicationId property value in to android:name attribute value.

Note: Android Studio provides a default $ placeholder for the build.gradle applicationId value that is not shown in the build file.

Gradle build file:

Merged manifest value:

The manifest placeholder syntax and build file manifestPlaceholders property can be used to inject other manifest values. For properties other than the applicationId , the manifestPlaceholders property is explicitly declared in the build.gradle file. This example shows the manifest placeholder for injecting activityLabel values.

Gradle build file:

Placeholder in the manifest file:

Note: The placeholder value supports partial value injection, for example android:authority=»com.acme.$.foo» .

Manifest Merging Across Product Flavor Groups

When using the GroupableProductFlavor property, the manifest merge priority of any manifests in the product flavor groups follows the order in which the product flavor groups are listed in the build file. The manifest merge process creates a single merged manifest for the product flavor groups based on the configured build variant.

For example, if a build variant references the product flavors x86 , mdpi , 21 , and paid from the respective product flavor groups ABI , Density , API , and Prod , listed in this order in the build.gradle file, then the manifest merge process merges the manifests in this priority order, which follows how the product flavors are listed in the build file.

To illustrate this example, the following table shows how the product flavors are listed for each product flavor group. This combination of product flavors and groups defines the build variant.

Product Flavor Group	Product Flavor
ABI	x86
density	mdpi
API	22
prod	paid

Manifest merge order:

• prod-paid AndroidManifest.xml (lowest priority) merges into API-22 AndroidManifest.xml
• API-22 AndroidManifest.xml merges into density-mpi AndroidManifest.xml
• density-mpi AndroidManifest.xml merges into ABI-x86 AndroidManifest.xml (highest priority)

Implicit Permissions

Importing a library that targets an Android runtime with implicitly granted permissions may automatically add the permissions to the resulting merged manifest. For example, if an application with a targetSdkVersion of 16 imports a library with a targetSdkVersion of 2, Android Studio adds the WRITE_EXTERNAL_STORAGE permission to ensure permission compatibility across the SDK versions.

Note: More recent Android releases replace implicit permissions with permission declarations.

This table lists the importing library versions and the declared permissions.

Importing this library version	Declares this permission in the manifest
targetSdkVersion WRITE_EXTERNAL_STORAGE
targetSdkVersion WRITE_EXTERNAL_STORAGE , READ_PHONE_STATE
Declared WRITE_EXTERNAL_STORAGE	READ_EXTERNAL_STORAGE
targetSdkVersion READ_CONTACTS permission	READ_CALL_LOG
targetSdkVersion WRITE_CONTACTS permission	WRITE_CALL_LOG

Handling Manifest Merge Build Errors

During the build process, the manifest merge process stores a record of each merge transaction in the manifest-merger-

-report.txt file in the module build/outputs/logs folder. A different log file is generated for each of the module’s build variants.

When a manifest merge build error occurs, the merge process records the error message describing the merge conflict in the log file. For example, the android:screenOrientation merge conflict between the following manifests causes a build error.

Источник

Working with the Android Manifest

AndroidManifest.xml is a powerful file in the Android platform that allows you to describe the functionality and requirements of your application to Android. However, working with it is not easy. Xamarin.Android helps to minimize this difficulty by allowing you to add custom attributes to your classes, which will then be used to automatically generate the manifest for you. Our goal is that 99% of our users should never need to manually modify AndroidManifest.xml.

AndroidManifest.xml is generated as part of the build process, and the XML found within Properties/AndroidManifest.xml is merged with XML that is generated from custom attributes. The resulting merged AndroidManifest.xml resides in the obj subdirectory; for example, it resides at obj/Debug/android/AndroidManifest.xml for Debug builds. The merging process is trivial: it uses custom attributes within the code to generate XML elements, and inserts those elements into AndroidManifest.xml.

The Basics

At compile time, assemblies are scanned for non- abstract classes that derive from Activity and have the [Activity] attribute declared on them. It then uses these classes and attributes to build the manifest. For example, consider the following code:

This results in nothing being generated in AndroidManifest.xml. If you want an element to be generated, you need to use the [Activity] custom attribute:

This example causes the following xml fragment to be added to AndroidManifest.xml:

The [Activity] attribute has no effect on abstract types; abstract types are ignored.

Activity Name

Beginning with Xamarin.Android 5.1, the type name of an activity is based on the MD5SUM of the assembly-qualified name of the type being exported. This allows the same fully-qualified name to be provided from two different assemblies and not get a packaging error. (Before Xamarin.Android 5.1, the default type name of the activity was created from the lowercased namespace and the class name.)

If you wish to override this default and explicitly specify the name of your activity, use the Name property:

This example produces the following xml fragment:

You should use the Name property only for backward-compatibility reasons, as such renaming can slow down type lookup at runtime. If you have legacy code that expects the default type name of the activity to be based on the lowercased namespace and the class name, see Android Callable Wrapper Naming for tips on maintaining compatibility.

Activity Title Bar

By default, Android gives your application a title bar when it is run. The value used for this is /manifest/application/activity/@android:label . In most cases, this value will differ from your class name. To specify your app’s label on the title bar, use the Label property. For example:

This example produces the following xml fragment:

Launchable from Application Chooser

By default, your activity will not show up in Android’s application launcher screen. This is because there will likely be many activities in your application, and you don’t want an icon for every one. To specify which one should be launchable from the application launcher, use the MainLauncher property. For example:

This example produces the following xml fragment:

Activity Icon

By default, your activity will be given the default launcher icon provided by the system. To use a custom icon, first add your .png to Resources/drawable, set its Build Action to AndroidResource, then use the Icon property to specify the icon to use. For example:

This example produces the following xml fragment:

Permissions

When you add permissions to the Android Manifest (as described in Add Permissions to Android Manifest), these permissions are recorded in Properties/AndroidManifest.xml. For example, if you set the INTERNET permission, the following element is added to Properties/AndroidManifest.xml:

Debug builds automatically set some permissions to make debug easier (such as INTERNET and READ_EXTERNAL_STORAGE ) – these settings are set only in the generated obj/Debug/android/AndroidManifest.xml and are not shown as enabled in the Required permissions settings.

For example, if you examine the generated manifest file at obj/Debug/android/AndroidManifest.xml, you may see the following added permission elements:

In the Release build version of the manifest (at obj/Debug/android/AndroidManifest.xml), these permissions are not automatically configured. If you find that switching to a Release build causes your app to lose a permission that was available in the Debug build, verify that you have explicitly set this permission in the Required permissions settings for your app (see Build > Android Application in Visual Studio for Mac; see Properties > Android Manifest in Visual Studio).

Advanced Features

Intent Actions and Features

The Android manifest provides a way for you to describe the capabilities of your activity. This is done via Intents and the [IntentFilter] custom attribute. You can specify which actions are appropriate for your activity with the IntentFilter constructor, and which categories are appropriate with the Categories property. At least one activity must be provided (which is why activities are provided in the constructor). [IntentFilter] can be provided multiple times, and each use results in a separate element within the . For example:

This example produces the following xml fragment:

Application Element

The Android manifest also provides a way for you to declare properties for your entire application. This is done via the element and its counterpart, the Application custom attribute. Note that these are application-wide (assembly-wide) settings rather than per-Activity settings. Typically, you declare properties for your entire application and then override these settings (as needed) on a per-Activity basis.

For example, the following Application attribute is added to AssemblyInfo.cs to indicate that the application can be debugged, that its user-readable name is My App, and that it uses the Theme.Light style as the default theme for all activities:

This declaration causes the following XML fragment to be generated in obj/Debug/android/AndroidManifest.xml:

In this example, all activities in the app will default to the Theme.Light style. If you set an Activity’s theme to Theme.Dialog , only that Activity will use the Theme.Dialog style while all other activities in your app will default to the Theme.Light style as set in the element.

There are many application-wide attributes that you can configure in the element; for more information about these settings, see the Public Properties section of ApplicationAttribute.

Источник