At Emerge, we think it's most important to track exactly what your users will see when it comes to app size.

Emerge's Android app size metric is roughly equivalent to the compressed download size of your app on a Pixel 5 running Android 8 with English as the primary language. Emerge chose this benchmark configuration to give a single number that is reflective of compressed size on a wide range of devices, but specific users can experience different size numbers based on their device, configuration and more.

Since download size is what users will see before downloading your app on Google Play, we think it’s the most important metric to track and reduce on Android.

What do users see?

Users will see different numbers concerning app size depending on the location they download from or where they are on their device.

Play Store

The Play Store could show users two different numbers for download size depending on where they view your app from.

Play Store app

The Play Store app shows the exact download size of the install-time features a user will receive. Usually install-time features just means the main application users will interact with. Dynamic feature modules, Instant apps and other just-in-time content delivery methods won't be included in this measure.

If the app a user downloads is from a developer-uploaded APK (universal APK or a single APK), the number they'll see on the Play Store is the download size of the single APK. If the developer uploaded an AAB for distribution (now required as of August 2021), the Play Store will show the combined size of the split APKs their specific device will receive when downloading.

Google Play splits APKs for delivery using the bundletool, with the end user receiving a combination of APKs specific to their device's density, ABI, and language. This splitting optimizes your app so users download only what their specific device needs. Read more about AABs below.

Web

On the Play Store website, users will see the max size of your uploaded artifact. If you uploaded an APK, this will simply be the size of the single APK (or largest APK split) you uploaded.

If you uploaded an AAB, this number will be representative of the universal APK generated from the AAB, the largest single APK that can be produced from the bundle. This is an APK that includes all resources, assets, language, compiled dex and native libraries for all architectures, so any device can use the APK.

On device

Once downloaded, users will be able to view the install size of your application. The install size users see is dynamic and influenced by many different factors, including:

• Compressed APK (or split APKs) size (APKs are not extracted on install!)
• Extracted native libraries if present in the app
• AOT compiled Dex generated from Baseline profiles, cloud profiles or a combination.
• Cache size, including cached network requests, images, etc.
• File size, including local databases, files and other app-specific dynamic data that's not packaged with the APK(s).

You can view the install size of your app by going to Settings > "Apps" > {your_app}, and looking for the "App size" measure.

APKs vs AABs

The app size that your users see is quite different for APK vs AAB formats.

APKs

APKs are the primary executable delivered to a user's device. Before Android Lollipop (21), developers would upload APKs to the Play Store, and end-users would receive the uploaded APK (or specific APK for their device if split APKs were uploaded). It is also still used as the primary deliverable for many 3rd party app stores.

Any assets packaged in an APK will be delivered to users. In the past, this led to size issues as all densities, native libraries and languages would be packaged. Split APKs were added to mitigate this issue, but required setup and maintenance by developers in their build flows to produce split APKs, and uploading multiple split APKs to support users' broad ranges of devices and locales became cumbersome.

To mitigate this, Google supported the AAB format with Lollipop (21). This made producing split APKs automatic and performed by Google when users downloaded an app.

Emerge supports uploading APKs, but we recommend uploading AABs, as they lead to a far more optimized app size and are recommended by Google/required as of August 2021.

AABs

AABs, or the app bundle, is a newer and more optimized format developers can ship to the Play Store and are now required for new apps as of August 2021.

Users don't actually download your AAB, rather when a user downloads your app from the Play Store from an uploaded AAB, they'll receive a grouping of split APKs produced from your AAB that pertain to their device. APKs are split from your uploaded AAB using the bundletool, with the end-user receiving a combination of APKs specific to their device's density, ABI (Application binary interface, i.e. CPU architecture), and language.

Split APKs

Split APKs are generated for users for each feature module in an AAB. By default, all AABs have a base module. If your app has dynamic features, instant apps or other modules, split APKs will also be generated for these additional modules.

Emerge will automatically track sizes for all features, not just the base module, for any AAB uploaded!

Main split

The main split (ex: base-master.apk), is the APK users will download that contains the compiled dex code, as well as resources that are used agnostic of device config. This is usually just one APK, but some large apps might have multiple main splits depending on how many dex files are bundled.

The main split will sometimes contain density-specific resources as well, even those that don't pertain to a user's specific density config. This occurs if no matching resources were found in their corresponding density split.

Density

Density-specific splits (ex: base-xxdpi.apk) are generated for the device's specific density. This density-specific APK contains just assets that pertain to the density of a user's device. Universal assets or resources that don't use a density qualifier will be included in the main split.

ABIs/Native libraries

The ABI splits (ex: base-arm64-v8a.apk) are generated for the device's specific ABI (application binary interface - i.e. CPU architecture). This APK contains only native libraries, compiled for the specific CPU architecture the user's device supports.

Language

Language splits (ex: base-en.apk/base-de.apk) are generated for the languages selected by the user in their device settings. These will include string definitions for the specified languages, as well as any localized assets or resources with language qualifiers.