Tools: replace not replacing in Android manifest

I am using a gradle project with many different library dependencies and using the new manifest merger. In my <application /> tag I have it set up as such:

<application tools:replace="android:icon, android:label, android:theme, android:name"
    android:name="com.example.myapp.MyApplcation"
    android:allowBackup="true"
    android:icon="@drawable/ic_launcher"
    android:label="@string/application_name"
    android:logo="@drawable/logo_ab"
    android:theme="@style/AppTheme"
    >
....
</application>

Yet I am receiving the error:

/android/MyApp/app/src/main/AndroidManifest.xml:29:9        Error:
Attribute application@icon value=(@drawable/ic_launcher) from AndroidManifest.xml:29:9
is also present at {Library Name} value=(@drawable/app_icon)
Suggestion: add 'tools:replace="android:icon"' to <application> element at AndroidManifest.xml:26:5 to override

/android/MyApp/app/src/main/AndroidManifest.xml:30:9 Error:
Attribute application@label value=(@string/application_name) from AndroidManifest.xml:30:9
is also present at {Library Name} value=(@string/app_name)
Suggestion: add 'tools:replace="android:label"' to <application> element at AndroidManifest.xml:26:5 to override

/android/MyApp/app/src/main/AndroidManifest.xml:27:9 Error:
Attribute application@name value=(com.example.myapp.MyApplication) from AndroidManifest.xml:27:9
is also present at {Another Library}

Suggestion: add 'tools:replace="android:name"' to <application> element at AndroidManifest.xml:26:5 to override

/android/MyApp/app/src/main/AndroidManifest.xml:32:9 Error:
Attribute application@theme value=(@style/AppTheme) from AndroidManifest.xml:32:9
is also present at {Library Name} value=(@style/AppTheme)
Suggestion: add 'tools:replace="android:theme"' to <application> element at AndroidManifest.xml:26:5 to override

Solution 1:

Declare your manifest header like this

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

Then you can add to your application tag the following attribute:

<application
    tools:replace="icon, label" ../>

For example I need to replace icon and label. Good luck!

Solution 2:

I fixed same issue. Solution for me:

1. add the xmlns:tools="http://schemas.android.com/tools" line in the manifest tag
2. add tools:replace=.. in the manifest tag
3. move android:label=... in the manifest tag

Example:

 <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:tools="http://schemas.android.com/tools"
              tools:replace="allowBackup, label"
              android:allowBackup="false"
              android:label="@string/all_app_name"/>

Solution 3:

Try reordering your dependencies in your gradle file. I had to move the offending library from the bottom of the list to the top, and then it worked.

Solution 4:

I just experienced the same behavior of tools:replace=... as described by the OP.

It turned out that the root cause for tools:replace being ignored by the manifest merger is a bug described here. It basically means that if you have a library in your project that contains a manifest with an <application ...> node containing a tools:ignore=... attribute, it can happen that the tools:replace=... attribute in the manifest of your main module will be ignored.

The tricky point here is that it can happen, but does not have to. In my case I had two libraries, library A with the tools:ignore=... attribute, library B with the attributes to be replaced in the respective manifests and the tools:replace=... attribute in the manifest of the main module. If the manifest of B was merged into the main manifest before the manifest of A everything worked as expected. In opposite merge order the error appeared.

The order in which these merges happen seems to be somewhat random. In my case changing the order in the dependencies section of build.gradle had no effect but changing the name of the flavor did it.

So, the only reliable workaround seems to be to unpack the problem causing library, remove the tools:ignore=... tag (which should be no problem as it is a hint for lint only) and pack the library again.

And vote for the bug to be fixed, of cause.