Debugging log · Manifest

"Manifest merger failed" — two components disagreed

I added a library, hit build, and got Manifest merger failed with a complaint about an attribute I'd never touched. I hadn't edited my manifest at all. The conflict was between my app's manifest and one buried inside the library I'd just pulled in — and Android's merger stops rather than guess which one wins.

The short version: your final manifest is merged from your app plus every library. When two of them set the same attribute to different values, the merge fails. You resolve it by telling the merger which value wins, usually with tools:replace (or tools:remove).

The error

Manifest merger failed : Attribute application@allowBackup
value=(false) from AndroidManifest.xml is also present at
[com.example:some-lib] AndroidManifest.xml value=(true).
Suggestion: add 'tools:replace="android:allowBackup"' ...

The message is verbose but it hands you the answer. It names the attribute in conflict (allowBackup here), your value, the library that disagrees, and its value — plus a suggested fix. Read those four facts and the resolution is mechanical.

What the merged manifest is

You never ship the manifest you wrote. At build time Android merges your app manifest with the manifest that every dependency contributes, producing one final file. Most of the time this is invisible and helpful — a library declares the permission or component it needs and it just appears. The trouble starts when two sources set the same thing to incompatible values, because there's no safe way to pick automatically.

The fix: declare who wins

Add the tools namespace to your manifest's root, then override the conflicting attribute on the element the error names:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application
        android:allowBackup="false"
        tools:replace="android:allowBackup">
        ...
    </application>
</manifest>

tools:replace tells the merger "use my value for this attribute and ignore the library's." That's the right move when you have a deliberate reason for your value — turning off backup, setting a theme, fixing a label.

Other tools you'll reach for

tools:replace="attrA,attrB" — override several attributes at once, comma-separated.
tools:remove="android:someAttr" — strip an attribute a library added that you don't want at all.
tools:node="remove" — drop an entire component or <uses-permission> a dependency injected that you'd rather not ship.

Before you override — understand the conflict

Overriding silences the error, but make sure your value is actually the one you want. If a library sets allowBackup="true" and you force false, that's a real behavior decision, not just noise. When you're unsure who should win, open the Merged Manifest view in Android Studio (a tab on the manifest editor). It shows the final result and, for every line, which source contributed it — so you can see exactly what each dependency is trying to set.

Don't blanket-tools:replace everything to make errors disappear. Each override is you overruling a library's stated requirement; do it deliberately, attribute by attribute, so you don't quietly break something the library needed.

Attribute, library and value names above are examples — the merger error names the exact ones in your build; act on those.