Android Manifest Merger Failed — Find the First Real Conflict

Diagnostic flow — conflict → sources → priority → intended result

Fix #2 — attribute conflict: determine the intended value first

Android's manifest merger uses source-set priority. For a typical variant, priority runs from the variant-specific manifest through build type and product flavors to src/main, then library dependencies; when multiple flavor dimensions exist, their declared dimension order also affects priority. Multiple libraries have their own dependency-order priority. A conflict means the default merge rules cannot safely choose between values.

Before adding a marker, ask whether the app genuinely intends to override the lower-priority value. For example, a library may declare a component property for a reason; overriding it without understanding that contract can produce a build that merges but behaves incorrectly.

If the higher-priority manifest intentionally owns the final value, a narrowly scoped tools:replace="android:…" can be appropriate. The higher-priority element must also declare the replacement value you actually intend to ship; the marker is not a magic “accept mine” switch without a deliberate final value. But a marker is not proof that the chosen value is semantically correct—it only tells the merger how to resolve the conflict. The marker belongs on the higher-priority element and requires the tools namespace.

Verify: Merged Manifest shows the intended final attribute and its source/override marker for the exact failing variant.

Fix #3 — when a library supplies the conflicting value

Do not edit files under Gradle's dependency cache. First identify the library and version, then decide whether the right repair is an app-level intentional override, a dependency upgrade/downgrade supported by the project, removal of a duplicate/obsolete dependency, or configuration required by that library.

Use the configuration corresponding to the failing variant. A transitive library may be the source even when it is absent from the top-level dependencies block.

Verify: You can trace the manifest source to a specific dependency/version and explain why the app should override it—or why the dependency itself should change.

Fix #4 — whole-node conflicts: use tools:node deliberately

Markers such as tools:node="remove", replace, merge, strict and tools:selector can operate more broadly than replacing one attribute. tools:selector can scope a marker to a particular lower-priority library rather than every matching node. The selector value identifies the lower-priority library by its manifest package name, so confirm that package/source before using it. Keep the scope as narrow as the conflict allows. Use them only when the desired final component/node is unambiguous.

Removing a provider, service, receiver, permission, uses-feature or metadata node just to make the build pass can disable library initialization/runtime behavior or change the app's permissions and device availability. Check the owning library's integration documentation before removing its node.

Verify: The Merged Manifest contains exactly the intended node set and required library components remain present. For permissions/features/components with packaging consequences, also inspect the built artifact or relevant Play/device behavior when appropriate—the merge succeeding is not the only correctness gate.

Fix #5 — debug/release/flavor-only conflicts

The final manifest is variant-specific. Inspect src/main, product-flavor, build-type and variant manifests plus manifest placeholders. A fix made only in main may not explain why release fails while debug succeeds.

Also verify placeholder values supplied by Gradle for that variant. Manifest placeholders can be configured per default config/flavor/build setup and substituted into the final manifest; two source manifests that look compatible can therefore produce different effective values after substitution. Inspect the resolved value in the Merged Manifest, not only the literal ${placeholder} in source.

Verify: Inspect the Merged Manifest for the same build variant, then rebuild that exact variant—not merely a different debug task that already worked.

Fix #6 — stop if the first concrete error belongs to another build stage

If the actionable line is Android resource linking failed, missing android:attr, malformed XML/resource syntax, or checkDebugAarMetadata platform requirements, manifest markers are the wrong tool. Follow the build stage that produced the first concrete error.

Verify: Your remediation targets manifest composition semantics, not a downstream resource-link or dependency-metadata error.

Still seeing Manifest merger failed?

Escalate with the merger evidence, not only the wrapper line. The useful report shows exactly what the merger was unable to reconcile.

Official references