3 ms·

IIRC, an AAB is basically a set of APK "dimensions" (base, screen size, screen density, ISA, and so on), so you end up downloading one APK per dimension and ins

IIRC, an AAB is basically a set of APK "dimensions" (base, screen size, screen density, ISA, and so on), so you end up downloading one APK per dimension and install them as one transaction. This is also possible to do through both the CLI (adb shell) and Java APIs. However, it does indeed make sideloading more troublesome (the regular graphical installer has no idea about how to do multi-APK transactions). However, you can still distribute monolithic APKs for that purpose...

tdeck 5y ago
This is basically correct. An app can be loaded as one APK or as a set of multiple APKs - these are sometimes called "split APKs". For a while the Play Store has supported sending apps as a base APK plus a bunch of "config split" APKs. The base APK contains things like DEX code (Java bytecode). The config split APKs are grouped by various device targeting dimensions (basically language, DPI, and architecture). As you can imagine, apps often have a different set of strings for each language, multiple versions of native libraries for different ARM / x86 ABIs, and assets for different DPIs. When you create a bundle, Play will build split APKs for each possible value in each group (e.g. a low-dpi APK, a high-dpi APK, an English-language APK, a Korean-language APK, etc...). When a device downloads the app, Play will send that device the base split APK and one config split APK from each group. So I will get the base DEX code, the arm64v8a native code APK, the XXHDPI APK, and the English strings APK. That means devices don't have to download or store potentially large amounts of app assets and native code that will never be used on that device. EDIT: Older devices (IIRC L and below) don't support this. So Play will build standalone APKs for their configuration. I am not sure how many possible standalone APKs it will build.

tdeck 5y ago

This is basically correct. An app can be loaded as one APK or as a set of multiple APKs - these are sometimes called "split APKs". For a while the Play Store has supported sending apps as a base APK plus a bunch of "config split" APKs. The base APK contains things like DEX code (Java bytecode). The config split APKs are grouped by various device targeting dimensions (basically language, DPI, and architecture). As you can imagine, apps often have a different set of strings for each language, multiple versions of native libraries for different ARM / x86 ABIs, and assets for different DPIs. When you create a bundle, Play will build split APKs for each possible value in each group (e.g. a low-dpi APK, a high-dpi APK, an English-language APK, a Korean-language APK, etc...). When a device downloads the app, Play will send that device the base split APK and one config split APK from each group. So I will get the base DEX code, the arm64v8a native code APK, the XXHDPI APK, and the English strings APK. That means devices don't have to download or store potentially large amounts of app assets and native code that will never be used on that device. EDIT: Older devices (IIRC L and below) don't support this. So Play will build standalone APKs for their configuration. I am not sure how many possible standalone APKs it will build.