Key Field Value in the Manifest Doesnt Match the Current Item. Upload Another Zip Cancel

This page describes how our build tools ingest manifest files to determine the ultimate look and feel of your app.

For an introduction to the app manifest file, see the app manifest overview.

Merge multiple manifest files

Your APK or Android App Bundle file tin can incorporate just one AndroidManifest.xml file, but your Android Studio project may contain several—provided by the main source fix, build variants, and imported libraries. Then when edifice your app, the Gradle build merges all manifest files into a single manifest file that'southward packaged into your app.

The manifest merger tool combines all XML elements from each file by following some merge heuristics and past obeying merge preferences that yous have defined with special XML attributes. This page describes how manifest merging works and how you can utilize merge preferences to resolve merge conflicts.

Tip: Use the Merged Manifest view to preview the results of your merged manifest and find conflict errors.

Merge priorities

The merger tool combines all the manifest files into 1 file by merging them sequentially based on each manifest file's priority. For example, if y'all have three manifest files, the lowest priority manifest is merged into the side by side highest priority, and so that is merged into the highest priority manifest, as illustrated in figure 1.

Figure 1. The process to merge three manifest files, everyman priority (left) into highest priority (right)

At that place are three basic types of manifest files that may exist merged into each other, and their merge priorities are as follows (highest priority first):

1. Manifest file for your build variant

   If you accept multiple source sets for your variant, their manifest priorities are as follows:

   1. Build variant manifest (such as src/demoDebug/)
   2. Build blazon manifest (such as src/debug/)
   3. Product flavour manifest (such as src/demo/)

      If y'all're using flavor dimensions, the manifest priorities stand for to the lodge each dimension is listed in the flavorDimensions belongings (first is highest priority).

2. Main manifest file for the app module
3. Manifest file from an included library

   If you have multiple libraries, their manifest priorities lucifer the dependency order (the order they appear in your Gradle dependencies cake).

For instance, a library manifest is merged into the main manifest, and then the main manifest is merged into the build variant manifest. Note that these are the same merge priorities for all source sets, every bit described in Build with source sets.

Important: Build configurations from the build.gradle file override any respective attributes in the merged manifest file. For example, the minSdkVersion from the build.gradle file overrides the matching attribute in the <uses-sdk> manifest element. To avoid confusion, you should but get out out the <uses-sdk> element and define these properties only in the build.gradle file. For more details, see Configure your build.

Merge conflict heuristics

The merger tool tin logically friction match every XML chemical element from i manifest to a corresponding chemical element in the other manifest. (For details about how matching works, meet the merge policies).

If an element from the lower-priority manifest does not match whatsoever elements in the higher-priority manifest, then it is added to the merged manifest. However, if there is a matching chemical element, and then the merger tool attempts to combine all attributes from each into the same chemical element. If the tool finds that both manifests contain the same attribute with different values, then a merge disharmonize occurs.

Table 1 depicts the possible outcomes when the merger tool attempts to combine all attributes into the aforementioned element.

Table i. Default merge behavior for attribute values

High priority attribute	Low priority attribute	Aspect's merged result
No value	No value	No value (use default value)
	Value B	Value B
Value A	No value	Value A
	Value A	Value A
	Value B	Conflict error—you must add a merge rule marker

However, there are a few situations in which the merger tool behaves differently to avert merge conflicts:

• Attributes in the <manifest> element are never merged together—only the attributes from the highest priority manifest are used.
• The android:required attribute in the <uses-feature> and <uses-library> elements utilise an OR merge, such that if at that place is a conflict, "truthful" is applied and the characteristic or library required past one manifest is always included.
• Attributes in the <uses-sdk> chemical element always employ the value from the college-priority manifest, except in the post-obit situations:
  • When the lower-priority manifest has a minSdkVersion value that'due south higher, an error occurs unless you utilise the overrideLibrary merge dominion.
  • When the lower-priority manifest has a targetSdkVersion value that'southward lower, the merger tool uses the value from the higher-priority manifest, just it as well adds whatsoever organisation permissions that are necessary to ensures that the imported library continues to function properly (for cases in which the higher Android version has increased permission restrictions). For more information most this behavior, come across the section about implicit system permissions.
• The <intent-filter> element is never matched between manifests. Each is treated equally unique and is added to the common parent element in the merged manifest.

For all other conflicts between attributes, you'll receive an error and you must instruct the merger tool how to resolve it past adding a special attribute in the college-priority manifest file (see the adjacent department almost merge rule markers).

Do not depend on default attribute values. Considering all unique attributes are combined into the same element, this might cause unexpected results if the higher-priority manifest actually depends on the default value of an aspect without declaring information technology. For example, if the higher- priority manifest does not declare the android:launchMode attribute, then it uses the default value of "standard"; but if the lower-priority manifest declares this aspect with a different value, that value is practical to the merged manifest (overriding the default value). So y'all should explicity define each attribute as you desire information technology to exist. (Default values for each aspect are documented in the Manifest reference.)

Merge rule markers

A merge rule marking is an XML attribute you can use to express your preference well-nigh how to resolve merge conflicts or remove unwanted elements and attributes. Yous can use a marker to either an entire element or to just specific attributes in an element.

When merging ii manifest files, the merger tool looks for these markers in the higher-priority manifest file.

All markers belong to the Android tools namespace, so y'all must first declare this namespace in the <manifest> element as shown here:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"     package="com.case.myapp"          xmlns:tools="http://schemas.android.com/tools">        

Node markers

To apply a merge rule to an entire XML element (to all attributes in a given manifest element and to all its child tags), utilize the following attributes:

tools:node="merge"

Merge all attributes in this tag and all nested elements when there are no conflicts using the merge conflict heuristics. This is the default behavior for elements.

Depression priority manifest:

<action android:name="com.example.ActivityOne"     android:windowSoftInputMode="stateUnchanged">     <intent-filter>         <action android:name="android.intent.action.Ship" />         <category android:name="android.intent.category.DEFAULT" />     </intent-filter> </action>                

High priority manifest:

<activity android:proper name="com.instance.ActivityOne"     android:screenOrientation="portrait"                  tools:node="merge"> </activity>                

Merged manifest upshot:

<activity android:name="com.example.ActivityOne"     android:screenOrientation="portrait"     android:windowSoftInputMode="stateUnchanged">     <intent-filter>         <activeness android:name="android.intent.action.Send" />         <category android:name="android.intent.category.DEFAULT" />     </intent-filter> </activity>            

tools:node="merge-merely-attributes"

Merge attributes in this tag only; practice not merge nested elements.

Low priority manifest:

<activity android:name="com.example.ActivityOne"     android:windowSoftInputMode="stateUnchanged">     <intent-filter>         <action android:name="android.intent.action.Send" />         <data android:blazon="prototype/*" />         <category android:proper name="android.intent.category.DEFAULT" />     </intent-filter> </activity>                

High priority manifest:

<activity android:name="com.instance.ActivityOne"     android:screenOrientation="portrait"                  tools:node="merge-merely-attributes"> </activity>                

Merged manifest upshot:

<activity android:name="com.example.ActivityOne"     android:screenOrientation="portrait"     android:windowSoftInputMode="stateUnchanged"> </activeness>            

tools:node="remove"

Remove this element from the merged manifest. Although information technology seems like you should instead but delete this element, using this is necessary when you notice an element in your merged manifest that y'all don't demand, and it was provided by a lower-priority manifest file that's out of your control (such equally an imported library).

Low priority manifest:

<action-alias android:name="com.example.alias">   <meta-data android:proper noun="cow"       android:value="@cord/moo"/>   <meta-data android:name="duck"       android:value="@string/quack"/> </activeness-alias>                

High priority manifest:

<activity-alias android:name="com.example.allonym">   <meta-data android:name="cow"                  tools:node="remove"/> </activity-allonym>                

Merged manifest outcome:

<activity-allonym android:name="com.case.alias">   <meta-data android:proper noun="duck"       android:value="@string/quack"/> </activity-allonym>            

tools:node="removeAll"

Like tools:node="remove", but it removes all elements matching this element type (within the same parent element).

Low priority manifest:

<activeness-alias android:name="com.case.allonym">   <meta-data android:proper name="moo-cow"       android:value="@string/moo"/>   <meta-data android:proper name="duck"       android:value="@string/quack"/> </activity-allonym>                

High priority manifest:

<activity-alias android:name="com.example.alias">   <meta-information                  tools:node="removeAll"/> </activity-alias>                

Merged manifest effect:

<activity-alias android:proper noun="com.instance.alias"> </activeness-allonym>            

tools:node="replace"

Replace the lower-priority chemical element completely. That is, if at that place is a matching element in the lower-priority manifest, ignore it and employ this element exactly equally it appears in this manifest.

Low priority manifest:

<activity-alias android:name="com.example.alias">   <meta-data android:name="moo-cow"       android:value="@string/moo"/>   <meta-data android:proper noun="duck"       android:value="@cord/quack"/> </activeness-alias>                

Loftier priority manifest:

<activity-allonym android:name="com.example.alias"                  tools:node="replace">   <meta-data android:proper name="play a trick on"       android:value="@string/dingeringeding"/> </activity-alias>                

Merged manifest outcome:

<activity-alias android:name="com.case.alias">   <meta-data android:name="fox"       android:value="@cord/dingeringeding"/> </activity-alias>            

tools:node="strict"

Generate a build failure any time this element in the lower-priority manifest does not exactly match it in the higher-priority manifest (unless resolved by other merge rule markers). This overrides the merge conflict heuristics. For case, if the lower-priority manifest but includes an extra attribute, the build fails (whereas the default beliefs adds the actress attribute to the merged manifest).

Low priority manifest:

<activeness android:name="com.example.ActivityOne"     android:windowSoftInputMode="stateUnchanged">     <intent-filter>         <activity android:name="android.intent.action.Transport" />         <category android:name="android.intent.category.DEFAULT" />     </intent-filter> </activity>                

Loftier priority manifest:

<activity android:proper noun="com.example.ActivityOne"     android:screenOrientation="portrait"                  tools:node="strict"> </activity>                

This creates a manifest merge mistake. The two manifest elements cannot differ at all in strict mode. So you must apply other merge dominion markers to resolve these differences. (Ordinarily, these two will merge together fine every bit shown in the above case for tools:node="merge".)

Aspect markers

To instead employ a merge rule but to specific attributes in a manifest tag, use the following attributes. Each aspect accepts one or more attribute names (including the aspect namespace), separated by commas.

tools:remove="attr, ..."

Remove the specified attributes from the merged manifest. Although it seems similar you could instead just delete these attributes, it's necessary to use this when the lower-priority manifest file does include these attributes and you want to ensure they do not get into the merged manifest.

Low priority manifest:

<action android:name="com.example.ActivityOne"     android:windowSoftInputMode="stateUnchanged">                

Loftier priority manifest:

<activity android:proper noun="com.example.ActivityOne"     android:screenOrientation="portrait"                  tools:remove="android:windowSoftInputMode">                

Merged manifest result:

<activeness android:proper noun="com.example.ActivityOne"     android:screenOrientation="portrait">            

tools:replace="attr, ..."

Replace the specified attributes in the lower-priority manifest with those from this manifest. In other words, always keep the higher-priority manifest's values.

Depression priority manifest:

<activity android:name="com.example.ActivityOne"     android:theme="@oldtheme"     android:exported="simulated"     android:windowSoftInputMode="stateUnchanged">                

High priority manifest:

<activity android:name="com.example.ActivityOne"     android:theme="@newtheme"     android:exported="truthful"     android:screenOrientation="portrait"                  tools:supplant="android:theme,android:exported">                

Merged manifest consequence:

<activeness android:name="com.example.ActivityOne"     android:theme="@newtheme"     android:exported="true"     android:screenOrientation="portrait"     android:windowSoftInputMode="stateUnchanged">            

tools:strict="attr, ..."

Generate a build failure any fourth dimension these attributes in the lower-priority manifest do not exactly friction match them in the higher-prority manifest. This is the default behavior for all attributes, except for those with special behaviors as described in the merge conflict heuristics.

Low priority manifest:

<activity android:name="com.case.ActivityOne"     android:screenOrientation="mural"> </activity>                

Loftier priority manifest:

<activity android:name="com.example.ActivityOne"     android:screenOrientation="portrait"                  tools:strict="android:screenOrientation"> </activity>                

This creates a manifest merge fault. Y'all must employ other merge rule markers to resolve the conflict. (Call up: This is the default behavior, so the above example has the aforementioned result if you lot remove tools:strict="screenOrientation".)

Y'all tin can also apply multiple markers to one element equally follows.

Low priority manifest:

<activity android:proper noun="com.example.ActivityOne"     android:theme="@oldtheme"     android:exported="faux"     android:allowTaskReparenting="true"     android:windowSoftInputMode="stateUnchanged">            

High priority manifest:

<activity android:name="com.example.ActivityOne"     android:theme="@newtheme"     android:exported="true"     android:screenOrientation="portrait"              tools:supplant="android:theme,android:exported"              tools:remove="android:windowSoftInputMode">            

Merged manifest event:

<activity android:name="com.example.ActivityOne"     android:theme="@newtheme"     android:exported="true"     android:allowTaskReparenting="true"     android:screenOrientation="portrait">        

Marker selector

If you want to apply the merge rule markers to simply a specific imported library, add the tools:selector attribute with the library package name.

For case, with the following manifest, the remove merge dominion is applied just when the lower-priority manifest file is from the com.example.lib1 library.

<permission android:name="permissionOne"     tools:node="remove"          tools:selector="com.example.lib1">        

If the lower-priority manifest is from any other source, the remove merge rule is ignored.

Note: If you utilise this with one of the attribute markers, then it applies to all attributes specified in the marking.

Override <uses-sdk> for imported libraries

By default, when importing a library with a minSdkVersion value that's college than the chief manifest file, an error occurs and the library cannot be imported. To brand the merger tool ignore this conflict and import the library while keeping your app's lower minSdkVersion value, add the overrideLibrary attribute to the <uses-sdk> tag. The attribute value tin can be one or more library package names (comma-separated), indicating the libraries that can override the main manifest's minSdkVersion.

For instance, if your app's main manifest applies overrideLibrary like this:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"           package="com.example.app"           xmlns:tools="http://schemas.android.com/tools">   <uses-sdk tools:overrideLibrary="com.example.lib1, com.example.lib2"/> ...        

So the post-obit manifest tin can be merged without an error regarding the <uses-sdk> tag, and the merged manifest keeps minSdkVersion="2" from the app manifest.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"           package="com.example.lib1">    <uses-sdk android:minSdkVersion="4" /> ...        

Implicit organization permissions

Some Android APIs that were one time freely accessible by apps have become restricted by arrangement permissions in recent versions of Android. To avert breaking apps that expect access to these APIs, the contempo versions of Android permit apps to continue accessing those APIs without the permission if they have ready the targetSdkVersion to a value lower than the version in which the restriction was added. This behavior effectively grants the app an implicit permission to allow admission to the APIs. So, this can affect merged manifests that have different values for targetSdkVersion in the post-obit way.

If the lower-priority manifest file has a lower value for targetSdkVersion that provides it an implicit permission, and the higher-priority manifest does not have the aforementioned implicit permission (because its targetSdkVersion is equal to or higher than the version in which the restriction was added), then the merger tool explicitly adds the system permission to the merged manifest.

For case, if your app sets targetSdkVersion to four or higher and imports a library with targetSdkVersion gear up to 3 or lower, the merger tool adds the WRITE_EXTERNAL_STORAGE permission to the merged manifest. Table 2 lists all the possible permissions that could be added to your merged manifest.

Table 2. Listing of permissions the merger tool may add together to the merged manifest

Lower-priority manifest declares	Permissions added to the merged manifest
targetSdkVersion is three or lower	WRITE_EXTERNAL_STORAGE, READ_PHONE_STATE
targetSdkVersion is 15 or lower and using READ_CONTACTS	READ_CALL_LOG
targetSdkVersion is 15 or lower and using WRITE_CONTACTS	WRITE_CALL_LOG

Inspect the merged manifest and find conflicts

Even earlier you build your app, you can meet a preview of what your merged manifest looks by opening your AndroidManifest.xml file in Android Studio, and then clicking the Merged Manifest tab at the bottom of the editor.

The Merged Manifest view shows the results of the merged manifest on the left and information nigh each merged manifest file on the right, as shown in figure 2. The elements that were merged in from lower-priority manifest files are highlighted in different colors on the left. The key for each colour is specified under Manifest Sources on the right.

Figure ii. The Merged Manifest view

Manifest files that were part of the build only did non contribute elements or attributes are listed under Other Manifest Files on the right.

To run across information about where an element came from, click it on the left and the details announced under Merging Log on the correct.

If whatever conflicts occur, they appear nether Merging Errors on the right side with a recommendation for how to resolve the conflict using the merge rule markers. The errors are too printed in the Outcome Log window (select View > Tool Windows > Result Log).

If yous'd like to run into a complete log of the merging decision tree, you can notice the log file in your module's build/outputs/logs/ directory, named manifest-merger-buildVariant-report.txt.

Merge policies

The manifest merger tool tin logically match every XML element from one manifest file to a corresponding element in another file. The merger matches each element using a "match cardinal": either a unique attribute value (such equally android:name) or the natural uniqueness of the tag itself (for example, there tin can be merely i <supports-screen> chemical element). If two manifests have the same XML element, and so the tool merges the ii elements together using i of three merge policies:

Merge

Combine all non-alien attributes into the aforementioned tag and merge child elements according to their respective merging policy. If any attributes disharmonize with each other, merge them together with the merge rule markers.

Merge children only

Exercise not combine or merge the attributes (keep only the attributes provided by the highest priority manifest file) and merge child elements co-ordinate to their merging policy.

Keep

Leave the chemical element "as is" and add together information technology to the common parent element in the merged file. This is used only when information technology is acceptable for in that location to be several declarations of the aforementioned element.

Table 1 lists each chemical element type, the type of merge policy used, and the fundamental used to decide an element match between two manifests.

Tabular array 3. Manifest element merge policies and match keys

Element	Merge policy	Lucifer key
<action>	Merge	android:name attribute
<activity>	Merge	android:name attribute
<application>	Merge	In that location is only ane per <manifest>
<category>	Merge	android:name attribute
<data>	Merge	In that location is only i per <intent-filter>
<grant-uri-permission>	Merge	There is only one per <provider>
<instrumentation>	Merge	android:proper name attribute
<intent-filter>	Go along	No matching; several declarations within the parent chemical element are allowed
<manifest>	Merge children only	At that place is only one per file
<meta-data>	Merge	android:name attribute
<path-permission>	Merge	There is but one per <provider>
<permission-grouping>	Merge	android:name attribute
<permission>	Merge	android:name attribute
<permission-tree>	Merge	android:name attribute
<provider>	Merge	android:name attribute
<receiver>	Merge	android:proper name aspect
<screen>	Merge	android:screenSize attribute
<service>	Merge	android:name aspect
<supports-gl-texture>	Merge	android:proper name aspect
<supports-screen>	Merge	There is only one per <manifest>
<uses-configuration>	Merge	There is only one per <manifest>
<uses-feature>	Merge	android:name attribute (if not present, then the android:glEsVersion aspect)
<uses-library>	Merge	android:name attribute
<uses-permission>	Merge	android:proper name attribute
<uses-sdk>	Merge	In that location is only one per <manifest>
Custom elements	Merge	No matching; these are unknown to the merger tool so they are ever included in the merged manifest

Inject build variables into the manifest

If you need to insert variables into your AndroidManifest.xml file that are divers in your build.gradle file, you tin can do then with the manifestPlaceholders property. This property takes a map of cardinal-value pairs, every bit shown here:

Groovy

android {     defaultConfig {         manifestPlaceholders = [hostName:"www.instance.com"]     }     ... }            

Kotlin

android {     defaultConfig {         manifestPlaceholders["hostName"] = "www.example.com"     }     ... }            

You can then insert one of the placeholders into the manifest file as an aspect value like this:

          <intent-filter ... >     <data android:scheme="https" android:host="${hostName}" ... />     ... </intent-filter>                  

By default, the build tools likewise provide your app's application ID in the ${applicationId} placeholder. The value always matches the final application ID for the current build (including changes by build variants. This is useful when you lot desire to use a unique namespace for identifiers such as an intent activeness, even between your build variants.

For example, if your build.gradle file looks similar this:

Slap-up

android {     defaultConfig {         applicationId "com.example.myapp"     }     productFlavors {         free {             applicationIdSuffix ".gratuitous"         }         pro {             applicationIdSuffix ".pro"         }     } }            

Kotlin

android {     defaultConfig {         applicationId = "com.case.myapp"     }     productFlavors {         create("free") {             applicationIdSuffix = ".free"         }         create("pro") {             applicationIdSuffix = ".pro"         }     } }            

Then y'all can insert the application ID in your manifest similar this:

          <intent-filter ... >     <activeness android:name="${applicationId}.TRANSMOGRIFY" />     ... </intent-filter>                  

And the manifest effect when you build the "free" product flavor is this:

          <intent-filter ... >    <action android:name="com.example.myapp.costless.TRANSMOGRIFY" />     ... </intent-filter>                  

For more than information, read Ready the application ID.

blakelytherip.blogspot.com

Source: https://developer.android.com/studio/build/manage-manifests

Share this post