Android App Bundles

If you have ever downloaded an app from the Google Play Store, you almost certainly installed an Android App Bundle (AAB) without knowing it. Since 2021, Google has required new apps and updates to be published as AABs rather than as raw APK files. The AAB is the container developers upload to Google Play, and it is not something you normally install directly on your phone. What follows explains what an AAB is, how it differs from an APK, and why the file you download from the Play Store is never the same AAB the developer uploaded.

What an Android App Bundle actually is

An Android App Bundle (AAB) is a publishing container, not an installation package. It holds the compiled code and resources of an app, but it does not contain a finished, device-ready APK. When a developer uploads an AAB to Google Play, the store generates a set of optimized APKs tailored to the user’s phone, screen density, CPU architecture, and language. This is the “device-specific APK delivery” model: the store sends only the pieces that the device needs, rather than a single universal APK.

The AAB file itself is never installed directly on a device. The Android platform does not accept .aab files as installable packages. The file is a publishing container for the developer; the user receives one or more APKs generated from it. Google Play Help states that an app bundle is a publishing container that includes all compiled code and resources, and that Google Play then uses it to generate and sign optimized APKs for each device profile (Google Play Help, 2024).

This distinction matters for the “find an APK” question. When you search for an app outside the Play Store, you are looking for an APK, not an AAB. An AAB is not something you install on your phone; it is something a developer uploads to Google Play. The Play Store then builds the device-specific APKs from it and signs them with the app’s signing key. If you see an AAB file on a random website and are told to install it, that is a misunderstanding of the container, and the file should be treated as suspicious.

How Google Play turns an AAB into device-specific APKs

When a user taps “Install” on Google Play, the store does not deliver the AAB to the phone. Instead, Google Play uses the AAB to create a set of device-specific APKs, often called “split APKs,” that contain only the assets and code needed for that particular device. This process is called “app delivery by device configuration” in the Android Developers documentation (2023). The practical result: a phone with a specific screen density, locale, and CPU architecture receives a smaller download than a universal APK would be.

Android devices cannot install an AAB directly. The Android package manager expects an APK, which contains the compiled code and assets for a specific device configuration. An AAB contains the same code and assets, but in a form that the Google Play server must process first. Google Play uses the AAB to generate a “base APK” plus configuration-specific APKs for each device, a system Google describes as “app delivery” in Android Developers documentation (2024). The store then serves the smallest combination of APKs for that device’s screen density, CPU architecture, and language.

The practical consequence: when you download an app from the Play Store, you are not downloading the AAB; you are downloading the generated APKs that Play produced from that AAB. An AAB file is a publishing artifact, not an installation artifact. You normally never install an AAB directly. If you see a file ending in .aab on a download site, it is not meant for your phone; it is meant for Google Play’s build pipeline. Installing it requires additional tooling and is outside normal Android installation flows.

What an AAB contains

An AAB contains the compiled code, assets, and manifest of an app, but it does not contain a single APK for every possible device. Instead, it holds the pieces needed to generate them:

• Base module: the core code and assets common to all devices.
• Dynamic feature modules: optional code and assets downloaded on demand after installation.
• Configuration splits: per-density and per-architecture assets.

When a user requests an app from Google Play, the store uses the AAB to generate a tailored APK for that specific device, often called a “split APK” or “configuration APK.” This is why the AAB itself is not installed directly on a phone; it is a publishing container, not an installation package. Google Play Help describes the app bundle as a publishing container that includes all compiled code and assets, and defers APK generation and signing to Google Play (Google Play Help, 2024). Android Developers documentation states that the bundle is the required publishing container for new apps on Google Play (Android Developers, 2021).

AAB versus APK: a direct comparison

The key distinction between the two file types is straightforward:

• AAB: a container used by creators to upload to Google Play; not installable on a phone.
• APK: the actual package installed on an Android device.

Because the AAB is a publishing container, not an installation package, you will not normally see an AAB file on a phone. When you download an app from the Play Store, you are receiving one or more APK files (or, in newer versions, a related container called an APK set) that Google Play has generated from the AAB for your device configuration. The AAB is the source; the APK is what your device runs.

According to Google’s official Android Developers documentation, the 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” (Android Developers, App Bundle overview, 2024). The key consequence is that a user normally never installs an .aab file directly; they receive a generated APK or a set of split APKs from the store. The AAB itself is not an installable package on a standard Android device.

Why the distinction matters for everyday users

For most people, the AAB is invisible. It is the pipeline that delivers a smaller, faster download from Google Play. The shift from APK to AAB as the required upload container happened in 2021, and since then every new app and update on the Play Store has been built from an AAB. This means the app you install today is almost certainly a set of split APKs generated from a bundle, even though you never see the .aab file.

The one practical place where the distinction surfaces is sideloading. If you download an app outside the Play Store, you are downloading an APK, not an AAB. Any site offering an .aab file for direct installation is either misinformed or untrustworthy. Treat the file as you would any unknown executable: do not install it, and delete it. The AAB belongs on a developer’s machine and in Google’s build pipeline, not on your phone.