What are they?

Android Manifest placeholders allow you to put variables into the Manifest that is otherwise completely static. Why would you need such functionality? Actually, it depends on your projects. It’s probably most useful when you have multiple build variants with different Manifest configurations.

Multiple Manifests

Of course, the easiest way to configure Manifest per build variant is to place a separate AndroidManifest.xml file in the variant-specific source directory. For example let's say we have an app module with flavor dimension called features with two flavors: paid and free. In Gradle file it could look like this:

{% highlight groovy %} android { … buildTypes { release {…} debug {…} }

flavorDimensions "features"

productFlavors {
    paid {
        dimension "features"
        ...
    }
    free {
        dimension "features"
        ...
    }
}

} {% endhighlight %}

This enables us to use different source sets, including Manifest files. If we would like to separate paid and free configurations, we could place different Manifests in the following project directories:

• app/src/paid/AndroidManifest.xml
• app/src/free/AndroidManifest.xml

We could also use fully qualified build variants (combining product flavors with build types):

• app/src/paidDebug/AndroidManifest.xml
• app/src/paidRelease/AndroidManifest.xml
• app/src/freeDebug/AndroidManifest.xml
• app/src/freeRelease/AndroidManifest.xml

Note #1: Source sets are not created automatically. You can create them by hand or using Source set dropdown menu while creating a new file or directory in Android Studio.

Note #2: If you would like to make sure how to organize the source sets, you can run Gradle sourceSets task, e.g. with ./gradlew sourceSets or Android Studio Gradle menu.

While using multiple Manifest files gives the best flexibility (you can change literally everything), the maintenance may be troublesome for several reasons, e.g.:

• changing anything requires editing every file,
• comparing multiple files and finding differences is not convenient.

Using placeholders

So instead of using multiple files I always strive to use some variables. In order to use a variable in the Manifest we must specify it in the manifestPlaceholders property in Gradle. We can do this in several places, e.g.:

• default config

{% highlight groovy %} android { … defaultConfig { manifestPlaceholders.screenOrientation = “unspecified” } } {% endhighlight %}

• product flavor

{% highlight groovy %} android { … flavorDimensions “features”

productFlavors {
    paid {
        dimension "features"
        manifestPlaceholders.hostName = "www.paid-example.com"
    }
    free {
        dimension "features"
        manifestPlaceholders.hostName = "www.free-example.com"
    }
}

} {% endhighlight %}

• build type

{% highlight groovy %} android { … buildTypes { release { … manifestPlaceholders.screenOrientation = “portrait” } debug {…} } } {% endhighlight %}

Note #1: manifestPlaceholders object is just a Map<String, Object> so you can also use its other methods like containsKey() etc.

Note #2: You can also specify all the values at once by assigning a map like this: manifestPlaceholders = [...]

Then we can use the variables in the Manifest simply by putting the variable name in curly brackets and using a dollar sign like this:

{% highlight xml %} {% endhighlight %}

Applications

I’ve come across a few common usages of the placeholders, e.g.:

• enabling/disabling application components and meta-data, including the ones that come with your app’s dependencies

{% highlight xml %} …

<provider android:name=”android.support.v4.content.FileProvider” android:authorities=”${fileProvider}” … > … {% endhighlight %}

• overriding screen orientation in portrait-only apps so that you can rotate it in debug builds which may be useful when looking for lifecycle related memory leaks

{% highlight xml %} {% endhighlight %}

• using different deep links configuration

{% highlight xml %} {% endhighlight %}

• removing SYSTEM_ALERT_WINDOW permission from React Native based release builds (this seems quite hacky though; you can find the original issue here (link))

{% highlight xml %} {% endhighlight %}

{% highlight groovy %} buildTypes { release { … manifestPlaceholders.excludeDebugPermissionName = “android.permission.SYSTEM_ALERT_WINDOW” } debug { … manifestPlaceholders.excludeDebugPermissionName = “fake.name” } } {% endhighlight %}

But there are much more possibilities, e.g. I can think of an app that uses different launcher activities.

Do you have any interesting experiences using the placeholders? Feel free to share with me in the comments :-)

By Andrzej Zabost, Android Developer @ Bright Inventions

Personal blog Email Github Stackoverflow

Originally published at brightinventions.pl