Your APK file can contain just one
AndroidManifest.xml file, but your Android Studio project may contain several—provided by the main source set, build variants, and imported libraries. So when building your app, the Gradle build merges all manifest files into a single manifest file that’s packaged into your APK.
The manifest merger tool combines all XML elements from each file by following some merge heuristics and by obeying merge preferences that you have defined with special XML attributes. This page describes how manifest merging works and how you can apply merge preferences to resolve merge conflicts.
The merger tool combines all the manifest files into one file by merging them sequentially based on each manifest file’s priority. For example, if you have three manifest files, the lowest priority manifest is merged into the next highest priority, and then that is merged into the highest priority manifest, as illustrated in figure
Figure 1. The process to merge three manifest files, lowest priority (left) into highest priority (right)
A merge rule marker is an XML attribute you can use to express your preference about how to resolve merge conflicts or remove unwanted elements and attributes. You can apply a marker to either an entire element or to just specific attributes in an element.
When merging two manifest files, the merger tool looks for these markers in the higher-priority manifest file.
All markers belong to the Android
tools namespace, so you must first declare this namespace in the
<manifest> element as shown here:
To apply a merge rule to an entire XML element (to all attributes in a given manifest element and to all its child tags), use the following attributes:
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.
Merge attributes in this tag only; do not merge nested elements.
Remove this element from the merged manifest. Although it seems like you should instead just delete this element, using this is necessary when you discover an element in your merged manifest that you don’t need, and it was provided by a lower-priority manifest file that’s out of your control (such as an imported library).
Remove the specified attributes from the merged manifest. Although it seems like 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 go into the merged manifest.
Like tools:node=”remove”, but it removes all elements matching this element type (within the same parent element).
Replace the lower-priority element completely. That is, if there is a matching element in the lower-priority manifest, ignore it and use this element exactly as it appears in this manifest.
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.
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 example, if the lower-priority manifest simply includes an extra attribute, the build fails (whereas the default behavior adds the extra attribtue to the merged manifest).
Generate a build failure any time these attributes in the lower-priority manifest do not exactly 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.
Note : You can also apply multiple markers to one element as follows.