What Is an AAB File? Google Play's App Bundle Explained

An AAB file is an Android App Bundle: the file you upload to Google Play instead of an APK. It is a publishing format, not an installable one. Google Play reads the bundle, builds device-specific APKs from it, signs those APKs, and serves them to users and testers. Since August 2021 every new app on Google Play has been required to publish this way, and the same .aab file is what your 12-tester closed test runs on.

This guide explains what is inside an AAB, how it differs from an APK, how to build one from Android Studio, Flutter or React Native, what Play does with it after upload, and where the format touches your 14-day closed test.

What is an AAB file?

Google defines it in one line: an Android App Bundle is "a file (with the .aab file extension) that you upload to Google Play," and app bundles are "signed binaries that organize your app's code and resources into modules." Google launched the format in 2018. It is open source, so stores other than Google Play can support it as well.

A bundle contains a base module (the code and resources every install needs), optional feature modules, and asset packs. After upload, Play generates the files it serves from those pieces: a base APK, configuration APKs matching each device's screen density, CPU architecture and language, feature APKs, and multi-APKs for older devices that do not support split APKs.

The practical result is one upload instead of a matrix of builds. You stop maintaining a separate signed APK per architecture, screen density and language, and Play assembles the right combination for each install.

Two structural details are worth knowing before you build. First, you manage one versionCode in the base module, and Play assigns that same versionCode to every APK it generates from the bundle, so all splits of a single install stay in lockstep on updates. Second, you build one bundle per application ID: if product flavors each declare their own application ID, each one needs its own .aab file.

AAB vs APK: the difference that matters

Both files carry the same compiled code and resources. The difference is who finishes the job. An APK is complete and installable the moment you build it. An AAB is finished only after Play processes it.

One correction worth making early, because it circulates widely: some guides state that every app update has been AAB-only since November 2021. Google's release documentation says something narrower. Releases let developers manage "Android App Bundles (or APKs for apps created before August 2021)," and legacy apps "can add app bundles or APKs for app updates." New apps must use bundles. Apps created before August 2021 still have the APK option for updates.

Is an AAB required for Google Play?

Yes, if the app is new. Play Console Help states: "Starting August 2021, new apps are required to publish with the Android App Bundle on Google Play." Google announced the same deadline in June 2021 with a table that marked new apps as required to switch from APK to AAB in August 2021, while updates to existing apps were left unchanged. The scope has since widened at the edges: since June 30, 2023, all TV app updates must also be published with AAB.

Two follow-on requirements sit behind the format rule:

• Test tracks follow the same rule. The release workflow covers internal, closed and open testing as well as production, because a release is a release regardless of which track it targets. Your closed test upload is an .aab file for any app created after August 2021.
• Play App Signing is mandatory. Play Console Help is explicit: "To use app bundles, you must enroll in Play App Signing." You sign the bundle with an upload key, and Google signs the APKs that reach devices.

Play App Signing splits the key material into two roles: an upload key that signs what you send to Play, and an app signing key Google uses to sign delivered APKs. For a brand-new app the console enrolls you automatically when you upload your first bundle, and you keep an upload key you can regenerate if it is ever lost.

How do you build an AAB file?

The command depends on what your project is built with. All four routes below produce one .aab file for Play.

Android Studio

Use Build > Generate Signed Bundle/APK, pick Android App Bundle, create or select a keystore, and the wizard writes a signed bundle under the module's build/outputs/ directory. For an unsigned local build, Build > Build Bundle(s) / APK(s) > Build Bundle(s) is enough to inspect the output, but Play only accepts a signed bundle.

Gradle from the command line

Run the bundle task for your variant:

./gradlew bundleRelease

Google's own command-line documentation uses ./gradlew :base:bundleDebug as the debug example and notes that building an app bundle "is the best way to package your app and upload it to the Play Console," while an APK remains the right artifact when you want to "quickly test a debug build or share your app as a deployable artifact with others."

Flutter

Run flutter build appbundle. Flutter documents that "the Google Play Store prefers the app bundle format" and that the release bundle lands at [project]/build/app/outputs/bundle/release/app.aab. Flutter's deployment guide also spells out the two-key model: developers upload an .aab signed with an upload key, end users download an .apk signed with the app signing key.

React Native

Run cd android && ./gradlew bundleRelease. The React Native docs confirm the output path: "The generated AAB can be found under android/app/build/outputs/bundle/release/app-release.aab, and is ready to be uploaded to Google Play," with Play App Signing configured before Play will accept it.

Apps exported from a web or AI builder

If your project came from Replit, Lovable, Bolt or Google AI Studio, the exported web bundle is not an Android project yet. It has to be wrapped into one (as a WebView or Trusted Web Activity shell, for example) before any of the commands above exist. Once it is a real Android project, the bundle task behaves the same as any other app. Our guides cover the Replit route, why wrapper apps get rejected when testers are not engaged, and the separate question of whether AI-built apps still need 12 testers.

What happens to your AAB after you upload it?

Play treats the bundle as source material. It generates a base APK (code and resources every configuration needs), configuration APKs for each screen density, CPU architecture and language the device supports, and any feature APKs your bundle declares. When a tester installs your closed test, the device downloads the combination built from that same upload.

Three things you can do with the bundle after upload are worth knowing:

• Test track availability. Play Console Help notes that when you publish a new Android App Bundle to the internal test track, "it becomes available to testers within minutes." Closed and open tracks use the same release flow with review and opt-in layered on top.
• Download a signed, universal APK. From the Latest releases and bundles page you can pull "a signed, universal APK," which Play defines as "a single, installable APK that is signed with the same app signing key used by Play App Signing for your app." That file is for other stores and your own distribution channels, not for counting installs in your closed test.
• Reproduce Play's build locally. Google's bundletool is the tool Android Studio, the Android Gradle plugin and Google Play themselves use to build bundles, and its build-apks command re-creates Play's server-side build. The --mode=universal option produces one APK with everything in it, which Google notes is larger than a device-optimized build but "easier to share with internal testers who, for example, want to test your app on multiple device configurations."

Size behaves differently under the bundle model. Google Play's size limits are based on the compressed download size calculated when you upload, and the total maximum compressed download size for apps published on Google Play is 34 GB. Installs above 200 MB trigger a non-blocking size warning for users on mobile data. Bundles do not support APK expansion (OBB) files at all: Google's FAQ states Play has no OBB support for AABs, and apps over 500 MB should use Play Asset Delivery or Play Feature Delivery instead.

How does the AAB affect your 12-tester closed test?

The format does not change the requirement. The 12-tester rule counts people and days, not files. Play Console Help states: "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days." Your bundle is simply what those testers install.

What the format does change is how testers get the app. You cannot hand them the .aab file, because an app bundle cannot be installed on a device. Each tester joins through your Play Console opt-in link or Google Group, and Play serves an install generated from your bundle for their device. If a tester opts out and comes back, Google's testing requirements page says the count restarts: testers "who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement," and after an opt-out and re-opt-in "the 14 days must be consecutive to count toward the requirement."

One recommendation, labelled as ours rather than Google's: a copy of the app installed directly from a file transfer never passed through your closed test track, so do not count it. Google does not publish a list of which install methods count and which do not. Make the opt-in link the only path into your test.

Our own testers run physical Samsung, Pixel, Xiaomi and OnePlus devices on Android 11 to 15 across more than 80 countries. Based on our internal records from 1,500+ closed-testing campaigns, the recurring problem in this area is not the file format, it is testers installing from somewhere other than the Play link you gave them.

If you are still assembling the pieces around the test itself, start with setting up closed testing in Play Console, then check what the 12-tester requirement actually counts and what counts as a closed tester. The full sequence from build to production lives in how to publish an Android app on Google Play in 2026.

Common AAB upload errors in Play Console

Frequently asked questions

Can I install an AAB file on my phone?

No. Google's app bundle FAQ is direct: "App bundles are only for publishing and cannot be installed on Android devices." To install something on a handset you need an APK, either built directly with Gradle or generated from your bundle with bundletool's build-apks command.

Is an AAB required for Google Play?

For new apps, yes. Google Play has required the Android App Bundle for new apps since August 2021, and Play App Signing is required to use bundles. Apps created before August 2021 are legacy apps and may still upload APKs for their updates.

Can I send my AAB file to my 12 testers?

No, and it would not help if you could. The bundle is not installable, and the 12-tester requirement counts testers who are opted in to your closed test and installed the release from Play. Have every tester join through the opt-in link, install from the Play listing that appears, and stay opted in for 14 consecutive days.

How do I convert an AAB to an APK?

Two supported routes. Locally, run bundletool build-apks --bundle=my_app.aab --output=my_app.apks and extract what you need, or add --mode=universal for a single APK covering all configurations. Through Play, download "a signed, universal APK" from the Latest releases and bundles page, which carries the same app signing key Play uses for delivered installs.

Does using an AAB change the 12-tester requirement?

No. The requirement is about testers and time: 12 testers opted in continuously for the preceding 14 days. The file format only decides how those testers receive the build.

Where is my AAB after I build it?

Android Studio writes it under the module's build/outputs/ directory. React Native puts it at android/app/build/outputs/bundle/release/app-release.aab, and Flutter at build/app/outputs/bundle/release/app.aab.

Do I need Play App Signing to upload a bundle?

Yes. Play Console Help states you must enroll in Play App Signing to use app bundles. Your upload key signs the .aab on the way up; Google's app signing key signs the APKs that reach testers and users.

Sources

Every claim above about Google's rules links to the page it came from. The Play Console Help and Android Developers pages were read while writing this article in October 2026, and a few Play Console Help quotes were checked against the Internet Archive's copy of the page because Play Console Help blocks automated requests. Google edits those pages without notice, so the live page wins if a rule has since moved on. The Flutter and React Native links are the official toolchain documentation for the build commands, not Google Play policy.

• Android App Bundle frequently asked questions - Android Developers
• The Android App Bundle format - Android Developers
• Build an Android App Bundle - Android Developers
• Build your project from the command line - Android Developers
• App signing overview - Android Developers
• bundletool - Android Developers
• Inspect app versions on the Latest releases and bundles page - Play Console Help
• Prepare and roll out a release - Play Console Help
• Use Play App Signing - Play Console Help
• Set up an open, closed, or internal test - Play Console Help
• App testing requirements for new personal developer accounts - Play Console Help
• Create and set up your app - Play Console Help
• Optimize your app's size and stay within Google Play app size limits - Play Console Help
• The future of Android App Bundles is here - Android Developers Blog
• Build and release an Android app - Flutter documentation
• Publishing to Google Play Store - React Native documentation