lightbulb_outline Help shape the future of the Google Play Console, Android Studio, and Firebase. Start survey

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 don't 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.

android {
  ...
  generatePureSplits = true
  splits {
    abi {
      enable = true
    }
    density {
      enable = true
    }
    language {
      enable = true
      include “es-rMX”, ”zh”, “en”
    }
  }
}

Language values are in the format described in Providing alternative resources.

Serving configuration APKs

Unlike using Multiple APKs, developers don't 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 is 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:

  1. 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.
  2. Android devices have widely varying fallback graphs. Android releases can change the fallback graph (see, for example, the Language and locale guide). 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 serves 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
    

    Specify minSdkVersion = 21 in your instant app module’s build.gradle file

  • The Gradle plugin prints the following message:
    > Configure project :base
    Pure splits are not supported by PlayStore yet.
    

    This is a known issue. Please ignore this message.

  • How do configuration APKs affect the 4MB limit?

    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

  • Gradle fails to build ABI APKs for some incremental builds (https://issuetracker.google.com/69680755 ). The issue can be worked around by cleaning and building again.
  • 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.