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.
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.
Gradle for Android has a robust
set of rules for “manifest merger”. While the term “manifest merger” is
still used, in reality, Gradle for Android synthesizes a manifest for your
app from a variety of sources, including apps, libraries, and
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 the new project structure and Gradle dependencies.
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.
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:
INTERNETpermission, so that apps that do not directly use the Internet still wind up requesting that permission
<activity>element that you can use without requiring the developer to add it manually
minSdkVersionthat it requires, which might supersede the value specified by the app, so the combined whole uses the most conservative value
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
debug builds, not
release builds. And while the activity and the
service code would simply be in the
debug sourceset, you also need to merge
in the manifest
<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).
Product flavors can override values from the
defaultConfig, such as
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.
And, of course, you may have some mix of all of the above.
The preview of this section was lost in the sofa cushions.
The preview of this section was whisked away by a shark-infested tornado.
The preview of this section took that left turn at Albuquerque.
The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.
The preview of this section is in the process of being translated from its native Klingon.