Set up your build for configuration APKs

You can reduce your app's APK size on each user's device by setting up your
build for configuration APKs (config APKs for short).
This places your app's DEX code and device-agnostic resources in one APK and
each set of device-dependent native code and resources in separate APKs.
Devices then request only the APKs needed to run your app. This allows you to reduce the
downloaded size of your app by creating APKs that contain files for specific screen densities, ABIs,
and/or languages.

Configuration APKs are similar to
Multiple APKs, with a few important
differences:

Currently, Multiple APKs are available only for installed apps, and configuration APKs
are only for instant apps.

With Multiple APKs, one APK is built for each combination of attributes. With
configuration APKs, there is one base APK with device-independent DEX code, and one APK for
each value of each varying dimension (i.e., one APK per supported language, density, or ABI). For
example, consider an app that varies by density and language, supporting four
densities and three languages. With Multiple APKs, the developer would upload 3 * 4 = 12
APKs. With configuration APKs, they would upload 1 (base) + 3 + 4 = 8 APKs. With
Multiple APKs, exactly one APK is delivered to any given device. With
configuration APKs, the device receives a base APK plus, potentially, one or more resource
APKs in each of the supported dimensions (currently language, density, and ABI).

With Multiple APKs, version codes are used to select among multiple compatible APKs for a
given device. Configuration APKs do not use a developer-specified ordering. The ordering
is determined by the targeting of the available APKs.

Configuration APKs support the new targeting dimension language.
Multiple APKs do not.

Prerequisites

Before you set up your build for configuration APKs, review the following
steps to make sure your build is ready, and verify you have the
tool configuration you need in Android Studio:

Set your instant app module's minimum SDK version to 21 or higher

Use Android Studio 3.0 or higher.

Set up your build for configuration APKs

To set up your build for configuration APKs based on languages, add a
language block
to the splits block of your feature module, and specify
generatePureSplits = true in the android block. For
more information about configuring the splits block, see
Configure your build for
multiple APKs.

Serving configuration APKs

Unlike using Multiple APKs, developers do not define an ordering over multiple equivalent
configuration APKs. So how does Play decide which to serve?

For ABI, Play chooses from among the compatible APKs using a fixed ordering that is the same for
every device. That ordering is x86_64, x86, mips64,
mips, arm64-v8a, armeabi-v7a, armeabi. For
example, if a device supports both x86 and armeabi-v7a, and APKs are
available for both, then the x86 APK will be served (along with the base).

For density, Play chooses the APK closest to the device’s density among those available.

Selection of APKs by language is more complicated.

Special concerns for language targeting

One might expect that Play tries to match the user’s locale exactly. If that’s
en-GB, then maybe it serves an APK targeted to en-GB, if available,
otherwise falling back to en. There would be two problems with that approach:

There’s no requirement that a configuration APK has to contain translations of every string,
just as there's no such requirement for a strings.xml file. It's acceptable
(and even common) to add a language for just one string or a few strings. For example,
en/strings.xml might contain “car” and “truck”, and
en-rGB/strings.xml might contain just “lorry”. So, just as the necessary set of
translations for any device might lie across multiple strings.xml files, those
files may be contained in multiple configuration APKs.

Android devices have widely varying fallback graphs. Android releases can change the
fallback graph (see, for example,
Language and Locale).
Moreover, OEMs customize the fallback order. (For example, whether “zh” prefers
“zh-TW” or “zh-CN” depends on the OEM.) Play doesn't always know
what fallback order is used by the requesting device.

Play works around the problems by serving all the configuration APKs targeted to languages
whose language subtag (the part before the dash) matches that of the user’s selected locale(s).
This relies on the observation that fallback algorithms usually do not fall back across
languages. Here's an example:

User’s locale is de-CH.
Available APKs are de, de-CH, de-AT, and
fr.
Play will serve de, de-CH, and de-AT, but not
fr.

Play also handles certain well-known cases where languages should be grouped together despite
having mismatched language subtags, such as fil/tag.

The grouping is done by Play at serving time and requires no action on the part of the
developer.

Troubleshooting and frequently asked questions

Gradle did not produce configuration APKs, and instead, printed the
following message

Variant ..., MinSdkVersion 18 is too low (<21) to support pure splits,
reverting to full APKs

Feature size is calculated by adding the feature APK size, the base feature APK size, and the
largest possible set of configuration APKs that could be delivered to a device. For example,
if a feature has three language APKs on the base APK, two density APKs on the base, and
two density APKs on the feature APK, the final feature size is derived by adding the feature
APK size, base APK size, the largest language and largest density APKs for the base, and the
largest density APK for the feature.

Known issues

Currently, the build tools aren't capable of creating multi-dimensional configuration APKs.
For example, a project may contain a resource in res/drawable-fr-xhdpi for
xhdpi devices in French, but Gradle cannot put such a resource into
configuration APKs. Any such resources are placed in the base or feature APKs.