Read the first actionable conflict
Open the build output and the merged-manifest view for the failing variant. Identify the element, attribute, value and source file named in the error. A library manifest, flavor manifest or generated file may be involved.
The manifest-merger documentation explains source priority and merge markers. The final result is not simply the text of your main manifest.
Classify common conflicts
| Conflict | First action |
|---|---|
| Different application attribute values | Determine which value the release should actually use |
| Library minimum SDK exceeds the app's | Check dependency compatibility rather than blindly overriding |
| Missing exported declaration | Decide whether the component should be externally reachable |
| Duplicate or incompatible component declarations | Trace the contributing dependency or source set |
| Unresolved placeholder | Check variant-specific placeholder configuration |
A fix should explain why the chosen value is correct, not merely make the build pass.
Use merge markers narrowly
If an override is justified, apply it to the specific element and attribute. Avoid replacing an entire component when only one attribute conflicts. Review the resulting manifest to ensure permissions, intent filters and metadata were not unintentionally removed.
For a minSdk conflict, overriding a library's minimum can lead to runtime calls unavailable on older devices. Prefer a compatible library version or a deliberate minimum-SDK change with testing.
Rebuild the exact variant
A debug build passing does not prove the release or another flavor is fixed. Run the affected build task and inspect the merged output. Keep the dependency and manifest change together in code review so the reason for the override remains visible.
Use APKLint after resolving the merge
The Manifest Checker can review the final XML for structural and risky configuration issues. It cannot reconstruct every Gradle source priority from a pasted fragment. Use the build's merger report to diagnose the conflict, then APKLint as an additional review of what the app will ship.
Resolve one conflicting application attribute
Imagine the application's manifest and a library manifest supply different values for an application attribute. Open the merger report for the failing variant and identify both source files. Decide which value the application must ship and why. If an override is justified, use a narrowly scoped merge marker on that attribute, then inspect the merged result. Replacing the entire application element would risk discarding unrelated metadata and component declarations.
The manifest merging reference describes priority and merge rules. Source priority is not simply the order in which files appear in an editor. A flavor manifest or generated input may participate, so use the report's source attribution rather than assuming the main manifest is the only relevant file.
Check placeholders in the exact failing flavor
For a provider authority defined through a placeholder, compare the placeholder map for the failing flavor and build type. A debug variant may supply a value that release never defines. Add the intended variant value at its owning configuration location and rebuild that same task. Do not replace the placeholder with one hardcoded authority shared across independently installable variants unless that identity is deliberate.
Inspect the final authority, exported state and granted URI access behavior together. A merge correction can produce syntactically valid XML while changing external access. Exercise the application's legitimate provider flow and an unauthorized test access when relevant. Keep the test scoped to the app and fixtures you control.
If the conflict concerns a library's higher minimum SDK, examine its published compatibility requirements before using an override marker. The merger cannot prove that its runtime calls are safe on older systems. Prefer a supported dependency version or a deliberate support-boundary change with device testing. After any correction, compare permissions, components and metadata in the old and new merged manifests, explaining the intended differences. Save the report and selected variant with the fix so a future library update can be reviewed against the same ownership decision instead of accumulating unexplained merge overrides.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
