4 ms·

> An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play.

> An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play. > Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app.[1] So a unique .apk is generated for each device configuration on demand? Goodbye to the days when a single (or a couple) .apk worked on all devices, which was easy to rehost, redistribute etc. Is the toolchain needed for compiling AAB -> APKs open source atleast? And will Google Play let end-users download the source .aab file? 1: https://developer.android.com/guide/app-bundle https://developer.android.com/guide/app-bundle

Nullabillity 5y ago
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.
UncleMeat 5y ago
App Bundles have been available and widely used for years. People are lamenting days that went away years ago but are just now complaining, which makes me think that the concerns are overblown.
iggldiggl 5y ago
Curiously enough, Google itself only recently introduced local app sharing ("Nearby Share" via Bluetooth/Wifi etc. – of course only for free apps) as an official built-in Play Store feature, while at the same time an increasing prevalence of app bundles will mean a suboptimal experience when sharing between devices with differing screen density, language, etc.

Nullabillity 5y ago

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.

UncleMeat 5y ago

App Bundles have been available and widely used for years. People are lamenting days that went away years ago but are just now complaining, which makes me think that the concerns are overblown.

iggldiggl 5y ago

Curiously enough, Google itself only recently introduced local app sharing ("Nearby Share" via Bluetooth/Wifi etc. – of course only for free apps) as an official built-in Play Store feature, while at the same time an increasing prevalence of app bundles will mean a suboptimal experience when sharing between devices with differing screen density, language, etc.