The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Manifest Merger Rules

When Android library projects were added as an option for app development, one problem became apparent: while libraries could contribute code and resources, they could not contribute manifest entries. Developers using libraries would sometimes have to add elements to their app manifest at the request of library authors, to add permissions, define components, and the like.

The Android Gradle Plugin has a robust set of rules for “manifest merger”. While the term “manifest merger” is still used, in reality, the Android Gradle Plugin synthesizes a manifest for your app from a variety of sources, including apps, libraries, and build.gradle files, also varying based upon build types and product flavors.

This chapter will help to explain a bit more about what is possible what the rules are for the manifest merger process.


Understanding this chapter requires that you have read the chapters that introduce Gradle and cover basic Gradle/Android integration, including build variants.

Manifest Scenarios

You might be wondering “why do we need all of this?” That is a fair question. Certainly, we were able to get by for quite a while without this sort of flexibility and accompanying confusion.

Here are some scenarios which help explain what you will get out of the manifest merger capabilities.

Library Manifest and App Manifest

A library — whether one of yours or one obtained via an AAR artifact from some repository — may need to augment the app’s manifest. For example:

App Manifest and Build Types

You may have particular needs for your main application that vary based upon build type that affect the manifest versus other things (e.g., ProGuard configuration).

For example, it may be that in debug builds, you want to have an activity that you can bring up, perhaps through adb shell am, that will give you diagnostic information about the app itself, or starts some diagnostic service that you can then access through your development machine’s Web browser. In this case, that activity and that service would only be desired in debug builds, not release builds. And while the activity and the service code would simply be in the debug source set, you also need to merge in the manifest <activity> and <service> elements, plus perhaps other things (e.g., extra <uses-permission> elements that those diagnostic components need but the rest of the app does not).

App Manifest and Product Flavors

Product flavors can override values from the defaultConfig, such as defining distinct applicationId values, and that needs to be taken into account in the combined app.

Also, product flavors might need their own manifest entries to accommodate distribution channel-specific APIs, such as swapping between Play Services and Amazon equivalents for in-app purchasing or maps.

Combo Platters

And, of course, you may have some mix of all of the above.

Pieces of Manifest Generation

The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.

Examining the Merger Results

The preview of this section was lost in the sofa cushions.

Viewing Merged Manifests in Android Studio

The preview of this section was eaten by a grue.

Merging Elements and Attributes

The preview of this section was lost in the sofa cushions.

Employing Placeholders

The preview of this section was lost due to a rupture in the space-time continuum.