Introduction

When Android Studio reports manifest merger failed with multiple errors, the build system found incompatible declarations across app and library manifests. These conflicts are usually deterministic and traceable once you inspect merge sources properly. The fastest path is to identify each conflicting node, decide intended ownership, and resolve with explicit manifest rules.

What Gets Merged During Build

Manifest merge combines declarations from:

• app src/main/AndroidManifest.xml
• flavor and build-type manifests
• dependency AAR manifests
• generated manifest entries from tools and plugins

Because many teams import several SDKs, multiple components may define the same authority, permission, metadata key, or app attribute. Without explicit conflict resolution, merger stops.

Inspect Errors in the Right Place

Relying only on one-line Gradle output is slow. Use Android Studio Merged Manifest tab and inspect each highlighted conflict source.

You can also run:

./gradlew :app:processDebugMainManifest --stacktrace

This produces detailed logs that reference file paths and offending attributes.

Common Conflict Types and Fixes

Duplicate provider authority

Two providers cannot share same authority string.

1<provider
2    android:name="androidx.core.content.FileProvider"
3    android:authorities="${applicationId}.fileprovider"
4    android:exported="false"
5    android:grantUriPermissions="true">
6</provider>

Using ${applicationId} usually avoids collisions across flavors.

Conflicting application attributes

If dependency and app both set attributes such as icon or allow backup with different values, choose explicitly with tools:replace.

1<application
2    android:allowBackup="false"
3    tools:replace="android:allowBackup">
4</application>

Duplicate metadata keys

Use tools:node to remove or replace duplicate entries when one source should win.

<meta-data
    android:name="com.example.analytics.API_KEY"
    tools:node="remove" />

Set Up tools Namespace Correctly

Resolution attributes require tools namespace on root manifest tag.

1<manifest xmlns:android="http://schemas.android.com/apk/res/android"
2    xmlns:tools="http://schemas.android.com/tools"
3    package="com.example.app">
4</manifest>

Without this declaration, merge directives are ignored or cause parse errors.

Dependency Hygiene Prevents Many Merge Failures

Multiple SDK versions can produce duplicate manifest blocks. Keep dependency graph clean.

1dependencies {
2    implementation("com.example:sdk-a:1.4.0") {
3        exclude group: "com.example", module: "legacy-core"
4    }
5    implementation "com.example:sdk-b:2.1.0"
6}

Use dependency reports to detect duplicated modules and transitive conflicts.

./gradlew :app:dependencies

Flavor and Build Variant Gotchas

Conflicts may only appear in one variant due to flavor-specific placeholders or manifest overlays.

1android {
2    defaultConfig {
3        manifestPlaceholders = [authHost: "prod.example.com"]
4    }
5
6    productFlavors {
7        staging {
8            manifestPlaceholders = [authHost: "staging.example.com"]
9        }
10    }
11}

If placeholder values are missing for one flavor, merger can fail only on that build, making issue look intermittent.

Step-by-Step Resolution Playbook

1. Run failing variant build and capture full logs.
2. Open Merged Manifest for same variant.
3. Fix one conflict class at a time.
4. Rebuild after each change.
5. Run dependency tree if duplicate libraries are suspected.
6. Add tests or lint checks for recurring conflict patterns.

Treat each conflict as a schema ownership decision, not just a syntax patch.

Example Minimal App Manifest with Safe Defaults

1<manifest xmlns:android="http://schemas.android.com/apk/res/android"
2    xmlns:tools="http://schemas.android.com/tools"
3    package="com.example.app">
4
5    <application
6        android:label="@string/app_name"
7        android:icon="@mipmap/ic_launcher"
8        tools:replace="android:label">
9
10        <activity
11            android:name=".MainActivity"
12            android:exported="true">
13            <intent-filter>
14                <action android:name="android.intent.action.MAIN" />
15                <category android:name="android.intent.category.LAUNCHER" />
16            </intent-filter>
17        </activity>
18
19    </application>
20</manifest>

This shows explicit namespace and one controlled replace directive pattern.

Common Pitfalls

• Adding tools directives without deciding which source should be authoritative.
• Fixing direct manifest conflicts while ignoring transitive dependency duplicates.
• Forgetting flavor-specific placeholders and seeing failures only in certain variants.
• Deleting conflicting entries blindly and breaking required runtime components.
• Debugging from short IDE messages instead of full merge output and merged-manifest view.

Summary

• Manifest merger errors are traceable compatibility conflicts, not random failures.
• Use Merged Manifest view and detailed Gradle task output to locate exact sources.
• Resolve conflicts intentionally with tools:replace, tools:node, or dependency cleanup.
• Validate each build variant because manifest overlays differ per flavor and build type.
• Keep dependency graph clean to prevent recurring merge conflicts.