This page describes how manifest merging works and how you can apply merge
preferences to
resolve merge conflicts. For an introduction to the app
manifest file, see the
[app manifest overview](https://developer.android.com/guide/topics/manifest/manifest-intro).

## Merge multiple manifest files

Your APK or Android App Bundle file can contain just one
`AndroidManifest.xml` file, but your Android Studio project may contain
several manifest files provided by the main source set, build variants, and imported
libraries. When building your app, the Gradle build merges
all manifest files into a single manifest file that's packaged
into your app.

The manifest merger tool combines all XML elements from each file by following
merge heuristics and obeying merge preferences that you have defined
with special XML attributes.

**Tip:** Use the [**Merged Manifest**
view](https://developer.android.com/build/manage-manifests#inspect_the_merged_manifest_and_find_conflicts), described in a following section, to preview the results of your merged manifest and find conflict
errors.

### Merge priorities

The merger tool combines all the manifest files into one file
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 manifest, and then that is merged into the highest-priority
manifest, as illustrated in figure 1.
![](https://developer.android.com/static/studio/images/build/manifest-merger_2x.png) **Figure 1.** The process to merge three manifest files, lowest priority into highest priority.

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

1. Manifest file for your [build variant](https://developer.android.com/studio/build/build-variants)

   If you have multiple source sets for your variant, their
   manifest priorities are as follows:
   - Build variant manifest (such as `src/demoDebug/`)
   - Build type manifest (such as `src/debug/`)
   - Product flavor manifest (such as `src/demo/`)

     If you're using flavor dimensions, the manifest priorities
     correspond to the order each dimension is listed in the
     `flavorDimensions` property (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 match
   the order they appear in your Gradle
   `dependencies` block.

For example, a library manifest is merged into the main manifest, then the main
manifest is merged into the build variant manifest. Note that these are the same
merge priorities for all source sets, as described in
[Build with source sets](https://developer.android.com/studio/build/build-variants#sourceset-build).
| **Note:** If you're building a library module, the final merged manifest does **not** include content from the manifests of the library's dependencies.

**Important:** Build configurations from the
`build.gradle` file override any corresponding attributes in the
merged manifest file. For example, the [`minSdk`](https://developer.android.com/reference/tools/gradle-api/7.2/com/android/build/api/dsl/BaseFlavor#minSdk()) from the `build.gradle` or
`build.gradle.kts` file overrides the matching attribute in the
[`<uses-sdk>`](https://developer.android.com/guide/topics/manifest/uses-sdk-element)
manifest element. To avoid confusion, leave out the
`<uses-sdk>` element and define these properties only in the
`build.gradle` file. For more details, see
[Configure your build](https://developer.android.com/studio/build).

### Merge conflict heuristics

The merger tool can logically match every XML element from one manifest to a
corresponding element in another manifest. For details about how matching
works, see the [merge priorities](https://developer.android.com/build/manage-manifests#merge_priorities) in the preceding section.

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

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

**Table 1.** Default merge behavior for attribute
values

| High-priority attribute | Low-priority attribute |                                                     Attribute's merged result                                                      |
|-------------------------|------------------------|------------------------------------------------------------------------------------------------------------------------------------|
| No value                | No value               | No value (use default value)                                                                                                       |
| No value                | Value B                | Value B                                                                                                                            |
| Value A                 | No value               | Value A                                                                                                                            |
| Value A                 | Value A                | Value A                                                                                                                            |
| Value A                 | Value B                | **Conflict error** ---you must add a [merge rule marker](https://developer.android.com/build/manage-manifests#merge_rule_markers). |

However, there are a few situations in which the merger tool behaves differently
to avoid 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>`](https://developer.android.com/guide/topics/manifest/uses-feature-element) and [`<uses-library>`](https://developer.android.com/guide/topics/manifest/uses-library-element) elements use an *OR* merge. If there is a conflict, `"true"` is applied and the feature or library required by one manifest is always included.
- Attributes in the `<uses-sdk>` element always use the value from the higher-priority manifest, except in the following situations:
  - When the lower-priority manifest has a `minSdk` value that's higher, an error occurs unless you apply the [`overrideLibrary`](https://developer.android.com/build/manage-manifests#override_uses-sdk_for_imported_libraries) merge rule.
  - When the lower-priority manifest has a `targetSdkVersion` value that's lower, the merger tool uses the value from the higher-priority manifest, and it also adds any system permissions that are necessary to ensure that the imported library continues to function properly (for cases in which the higher Android version has increased permission restrictions). For more information about this behavior, see the section about [implicit system
    permissions](https://developer.android.com/build/manage-manifests#implicit_system_permissions).
- The `<intent-filter>` element is never matched between manifests. Each is treated as unique and is added to the common parent element in the merged manifest.

For all other conflicts between attributes, you receive an error and you must
instruct the merger tool how to resolve it by adding a special attribute in
the higher-priority manifest file. See the following section about
[merge rule markers](https://developer.android.com/build/manage-manifests#merge_rule_markers).

**Do not depend on default attribute values.** Because 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 attribute without declaring it. For example, if the higher-
priority manifest doesn't declare the `android:launchMode`
attribute, then it uses the default value of `"standard"`---but if the
lower-priority manifest declares this attribute with a different value, that
value is applied to the merged manifest, which overrides the default value. You
should explicitly define each attribute as you want it to be. Default values
for each attribute are documented in the
[manifest reference](https://developer.android.com/guide/topics/manifest/manifest-intro).

### Merge rule markers

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:  

```xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp"
    xmlns:tools="http://schemas.android.com/tools">
```
| **Caution:** For app modules, `tools` merge markers are removed after the merge; however, for library modules, `tools` merge markers are **not** removed after the merge and may affect merges in a downstream module.

#### 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), use 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](https://developer.android.com/build/manage-manifests#merge_conflict_heuristics). This is the default behavior for elements.

    Low-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:windowSoftInputMode="stateUnchanged">
        <intent-filter>
            <action android:name="android.intent.action.SEND" />
            <category android:name="android.intent.category.DEFAULT" />
        </intent-filter>
    </activity>
    ```  
    High-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:screenOrientation="portrait"
        tools:node="merge">
    </activity>
    ```

    Merged manifest result:

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

`tools:node="mergeOnlyAttributes"`
:   Merge attributes in this tag only; don't merge nested elements.

    Low-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:windowSoftInputMode="stateUnchanged">
        <intent-filter>
            <action android:name="android.intent.action.SEND" />
            <data android:type="image/*" />
            <category android:name="android.intent.category.DEFAULT" />
        </intent-filter>
    </activity>
    ```  
    High-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:screenOrientation="portrait"
        tools:node="mergeOnlyAttributes">
    </activity>
    ```

    Merged manifest result:

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

`tools:node="remove"`
:   Remove this element from the merged manifest. Used when
    you discover an element in your merged manifest that you don't need that
    was provided by a lower-priority manifest file that's out of your control
    (such as an imported library).

    Low-priority manifest:  

    ```xml
    <activity-alias android:name="com.example.alias">
      <meta-data android:name="cow"
          android:value="@string/moo"/>
      <meta-data android:name="duck"
          android:value="@string/quack"/>
    </activity-alias>
    ```  
    High-priority manifest:  

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

    Merged manifest result:

    ```xml
    <activity-alias android:name="com.example.alias">
      <meta-data android:name="duck"
          android:value="@string/quack"/>
    </activity-alias>
    ```

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

    Low-priority manifest:  

    ```xml
    <activity-alias android:name="com.example.alias">
      <meta-data android:name="cow"
          android:value="@string/moo"/>
      <meta-data android:name="duck"
          android:value="@string/quack"/>
    </activity-alias>
    ```  
    High-priority manifest:  

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

    Merged manifest result:

    ```xml
    <activity-alias android:name="com.example.alias">
    </activity-alias>
    ```

`tools:node="replace"`
:   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.

    Low-priority manifest:  

    ```xml
    <activity-alias android:name="com.example.alias">
      <meta-data android:name="cow"
          android:value="@string/moo"/>
      <meta-data android:name="duck"
          android:value="@string/quack"/>
    </activity-alias>
    ```  
    High-priority manifest:  

    ```xml
    <activity-alias android:name="com.example.alias"
        tools:node="replace">
      <meta-data android:name="fox"
          android:value="@string/dingeringeding"/>
    </activity-alias>
    ```

    Merged manifest result:

    ```xml
    <activity-alias android:name="com.example.alias">
      <meta-data android:name="fox"
          android:value="@string/dingeringeding"/>
    </activity-alias>
    ```

`tools:node="strict"`
:   Generate a build failure any time this element in the lower-priority
    manifest doesn't exactly match the element in the higher-priority manifest (unless
    resolved by other merge rule markers). This overrides the [merge conflict heuristics](https://developer.android.com/build/manage-manifests#merge_conflict_heuristics). For
    example, if the lower-priority manifest includes an extra attribute,
    the build fails (whereas the default behavior adds the extra attribute to
    the merged manifest).

    Low-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:windowSoftInputMode="stateUnchanged">
        <intent-filter>
            <action android:name="android.intent.action.SEND" />
            <category android:name="android.intent.category.DEFAULT" />
        </intent-filter>
    </activity>
    ```  
    High-priority manifest:  

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

    **This creates a manifest merge error.** The two manifest elements
    cannot differ at all in strict mode. You must apply other merge rule markers
    to resolve these differences. (Without `tools:node="strict"`, these
    two files can merge together without errors, as shown in the example for
    `tools:node="merge"`.)

#### Attribute markers

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

`tools:remove="`<var translate="no">attr, ...</var>`"`
:   Remove the specified attributes from the merged manifest.
    Used when the lower-priority manifest file includes these
    attributes and you want to ensure they don't go into the merged
    manifest.

    Low-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:windowSoftInputMode="stateUnchanged">
    ```  
    High-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:screenOrientation="portrait"
        tools:remove="android:windowSoftInputMode">
    ```

    Merged manifest result:

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:screenOrientation="portrait">
    ```

`tools:replace="`<var translate="no">attr, ...</var>`"`
:   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.

    Low-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:theme="@oldtheme"
        android:exported="false"
        android:windowSoftInputMode="stateUnchanged">
    ```  
    High-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:theme="@newtheme"
        android:exported="true"
        android:screenOrientation="portrait"
        tools:replace="android:theme,android:exported">
    ```

    Merged manifest result:

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

`tools:strict="`<var translate="no">attr, ...</var>`"`
:   Generate a build failure any time these attributes in the
    lower-priority manifest don't exactly match the attributes in the higher-priority
    manifest. This is the default behavior for all attributes, except for
    those with special behaviors as described in the [merge conflict heuristics](https://developer.android.com/build/manage-manifests#merge_conflict_heuristics).

    Low-priority manifest:  

    ```xml
    <activity android:name="com.example.ActivityOne"
        android:screenOrientation="landscape">
    </activity>
    ```  
    High-priority manifest:  

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

    **This creates a manifest merge error.** You must apply other merge rule
    markers to resolve the conflict. This is the default behavior, so
    the same result occurs with explicitly adding
    `tools:strict="screenOrientation"`.

You can also apply multiple markers to one element, as shown in the following example:  
Low-priority manifest:  

```xml
<activity android:name="com.example.ActivityOne"
    android:theme="@oldtheme"
    android:exported="false"
    android:allowTaskReparenting="true"
    android:windowSoftInputMode="stateUnchanged">
```  
High-priority manifest:  

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

Merged manifest result:  

```xml
<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 only a specific
imported library, add the `tools:selector` attribute with
the library package name.

For example, with the following manifest, the `remove`
merge rule is applied only when the lower-priority manifest file is from the
`com.example.lib1` library:  

```xml
<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 use this with one of the attribute markers,
then it applies to all attributes specified in the marker.

#### Override \<uses-sdk\> for imported libraries

By default, when importing a library with a `minSdk` value
that's higher than the main manifest file, an error occurs and the
library cannot be imported.

To make the merger tool ignore this conflict and
import the library while keeping your app's lower `minSdk`
value, add the `overrideLibrary` attribute to the `<uses-sdk>` tag.
The attribute value can be one or more library package names
(separated by commas), indicating the libraries that can override the main
manifest's `minSdk`.

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

```xml
<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"/>
...
```

Then the following manifest can be merged without an error regarding
the `<uses-sdk>` tag, and the merged manifest keeps
`minSdk="2"` from the app manifest.  

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

#### Implicit system permissions

Some Android APIs that were once freely accessible by apps have become
restricted by [system permissions](https://developer.android.com/guide/topics/security/permissions) in
recent versions of Android.

To avoid breaking apps that expect access to these
APIs, the recent versions of Android let apps continue accessing those APIs
without the permission if the `targetSdkVersion` is set to a value lower
than the version where the restriction was added. This behavior
grants the app an implicit permission to allow access to the APIs. The merged
manifests that have different values for
`targetSdkVersion` can be affected.

If the lower-priority manifest file has a lower value for
`targetSdkVersion` that provides it an implicit permission,
and the higher-priority manifest doesn't have the same 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 example, if your app sets `targetSdkVersion` to 4 or higher and imports a
library with `targetSdkVersion` set to 3 or lower, the merger tool adds the
[`WRITE_EXTERNAL_STORAGE`](https://developer.android.com/reference/android/Manifest.permission#WRITE_EXTERNAL_STORAGE)
permission to the merged manifest.
| **Note:** If you've set your app's `targetSdkVersion` to 23 or higher, then you must perform runtime permission requests for any dangerous permissions when your app attempts to access the APIs protected by those permissions. For more guidance, see [Permissions on Android](https://developer.android.com/training/permissions).

Table 2 lists all the possible permissions
that could be added to your merged manifest:

**Table 2.** List of permissions the merger tool
might add to the merged manifest

|                                                         Lower-priority manifest declares                                                         |                                                                                            Permissions added to the merged manifest                                                                                            |
|--------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `targetSdkVersion` is 3 or lower                                                                                                                 | [WRITE_EXTERNAL_STORAGE](https://developer.android.com/reference/android/Manifest.permission#WRITE_EXTERNAL_STORAGE), [READ_PHONE_STATE](https://developer.android.com/reference/android/Manifest.permission#READ_PHONE_STATE) |
| `targetSdkVersion` is 15 or lower and using [READ_CONTACTS](https://developer.android.com/reference/android/Manifest.permission#READ_CONTACTS)   | [READ_CALL_LOG](https://developer.android.com/reference/android/Manifest.permission#READ_CALL_LOG)                                                                                                                             |
| `targetSdkVersion` is 15 or lower and using [WRITE_CONTACTS](https://developer.android.com/reference/android/Manifest.permission#WRITE_CONTACTS) | [WRITE_CALL_LOG](https://developer.android.com/reference/android/Manifest.permission#WRITE_CALL_LOG)                                                                                                                           |

### Inspect the merged manifest and find conflicts

Even before you build your app, you can see a preview of what your merged
manifest looks like. To see a preview, do the following:

1. In Android Studio, open your `AndroidManifest.xml` file.
2. Click 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 about 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 color is
specified under **Manifest Sources**.

![](https://developer.android.com/static/studio/images/build/manifest-merged-view_2x.png)

**Figure 2.** The Merged Manifest view.

<br />

Manifest files that were part of the build but didn't contribute elements or
attributes are listed under **Other Manifest Files**.

To see information about where an element came from, click it in the left
pane, and the details appear under **Merging Log**.

If any conflicts occur, they appear under **Merging Errors**
with a recommendation for how to resolve the conflict using
[merge rule markers](https://developer.android.com/build/manage-manifests#merge_rule_markers).

The errors are also printed in the **Event Log** window. To view them, select
**View \> Tool Windows \> Event Log**.

To see a complete log of the merging decision tree, you can find
the log file in your module's `build/outputs/logs/` directory, named
`manifest-merger-`<var translate="no">buildVariant</var>`-report.txt`.

## Merge policies

The manifest merger tool can logically match every XML element from one manifest
file to a corresponding element in another file. The merger matches each element
using a *match key* , either a unique attribute value (such as `android:name`) or
the natural uniqueness of the tag itself (for example, there can be only one
`<supports-screen>` element).

If two manifests have the same XML element, then
the tool merges the two elements together using one of three merge policies:

Merge
:   Combine all non-conflicting attributes into the same tag and merge
    child elements according to their respective merging policy. If any attributes
    conflict with each other, merge them together with the [merge rule markers](https://developer.android.com/build/manage-manifests#merge_rule_markers).

Merge children only
:   Do not combine or merge the attributes (keep only the attributes provided
    by the highest-priority manifest file) and merge
    child elements according to their merging policy.

Keep
:   Leave the element as-is and add it to the common parent element in the
    merged file. This is used only when it is acceptable for there to be several
    declarations of the same element.

Table 3 lists each element type, the type of merge policy used, and the
key used to determine an element match between two manifests:

**Table 3.** Manifest element merge policies and
match keys

|         Element          |    Merge policy     |                                             Match key                                             |
|--------------------------|---------------------|---------------------------------------------------------------------------------------------------|
| `<action>`               | Merge               | `android:name` attribute                                                                          |
| `<activity>`             | Merge               | `android:name` attribute                                                                          |
| `<application>`          | Merge               | There is only one per `<manifest>`.                                                               |
| `<category>`             | Merge               | `android:name` attribute                                                                          |
| `<data>`                 | Merge               | There is only one per `<intent-filter>`.                                                          |
| `<grant-uri-permission>` | Merge               | There is only one per `<provider>`.                                                               |
| `<instrumentation>`      | Merge               | `android:name` attribute                                                                          |
| `<intent-filter>`        | Keep                | No matching; several declarations within the parent element are allowed.                          |
| `<manifest>`             | Merge children only | There is only one per file.                                                                       |
| `<meta-data>`            | Merge               | `android:name` attribute                                                                          |
| `<path-permission>`      | Merge               | There is only one per `<provider>`.                                                               |
| `<permission-group>`     | Merge               | `android:name` attribute                                                                          |
| `<permission>`           | Merge               | `android:name` attribute                                                                          |
| `<permission-tree>`      | Merge               | `android:name` attribute                                                                          |
| `<provider>`             | Merge               | `android:name` attribute                                                                          |
| `<receiver>`             | Merge               | `android:name` attribute                                                                          |
| `<screen>`               | Merge               | `android:screenSize` attribute                                                                    |
| `<service>`              | Merge               | `android:name` attribute                                                                          |
| `<supports-gl-texture>`  | Merge               | `android:name` attribute                                                                          |
| `<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` attribute)               |
| `<uses-library>`         | Merge               | `android:name` attribute                                                                          |
| `<uses-permission>`      | Merge               | `android:name` attribute                                                                          |
| `<uses-sdk>`             | Merge               | There is only one per `<manifest>`.                                                               |
| Custom elements          | Merge               | No matching; these are unknown to the merger tool and are always included in the merged manifest. |

## Inject build variables into the manifest

If you need to insert variables into your `AndroidManifest.xml` file that are
defined in your `build.gradle` file, you can do so with the
`manifestPlaceholders` property. This property takes a map of key-value pairs,
as shown here:  

### Groovy

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

### Kotlin

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

You can then insert one of the placeholders into the manifest file as an
attribute value:  

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

By default, the build tools also provide your app's
[application ID](https://developer.android.com/studio/build/configure-app-module#set-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 want to use a unique namespace for identifiers
such as an intent action, even between your build variants.

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

### Groovy

```groovy
android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    flavorDimensions "type"
    productFlavors {
        free {
            applicationIdSuffix ".free"
            dimension "type"
        }
        pro {
            applicationIdSuffix ".pro"
            dimension "type"
        }
    }
}
```

### Kotlin

```kotlin
android {
    defaultConfig {
        applicationId = "com.example.myapp"
    }
    flavorDimensions += "type"
    productFlavors {
        create("free") {
            applicationIdSuffix = ".free"
            dimension = "type"
        }
        create("pro") {
            applicationIdSuffix = ".pro"
            dimension = "type"
        }
    }
}
```

Then you can insert the application ID in your manifest like this:  

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

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

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

For more information, read
[Set the application ID](https://developer.android.com/studio/build/configure-app-module#set-application-id).