An Android App Bundle (AAB) is the file format you upload to Google Play to publish an Android app. It holds your compiled code and resources, and Google Play then builds and signs the optimised APKs that users actually install. You cannot install an AAB on a phone. It exists for publishing only, and new apps on Google Play have had to use it since August 2021.
This guide explains how AAB differs from APK, what happens to your bundle after upload, what to check before release, and how the Google Play Data safety form fits into the same submission. It is written for the businesses, charities and agencies that commission apps, as well as the teams that build them.
TL;DR
- An AAB is a publishing format, not an installable file. Google Play uses it to generate APKs tailored to each device.
- An APK is what runs on a device. You still use APKs for direct testing and sideloading, but Google Play expects an AAB for new apps.
- For most apps, building an AAB takes about the same effort as building an APK, so the switch is rarely a project risk.
- Every app published on Google Play needs a completed Data safety form, even if it collects no user data. Only apps live solely on internal testing are exempt.
- Your Data safety answers must match your privacy policy and your UK GDPR duties, including data handled by third-party SDKs.
Table of Contents
- What is an Android App Bundle?
- AAB vs APK: the difference that matters
- How Google Play uses your bundle
- Signing: where AAB changes your process
- Before you publish: a release checklist
- The Google Play Data safety form
- Data safety and UK data protection
- Our perspective
- Getting your app to Google Play with Pocket App
- Common AAB problems and how to avoid them
- FAQ
- Sources
What is an Android App Bundle?
Google describes the Android App Bundle as a publishing format that includes all your app's compiled code and resources and defers APK generation and signing to Google Play. In practice, your developers build one bundle. Google Play takes it, signs it and produces the APKs each user's device needs.
The file extension is .aab. Inside, the bundle is organised into modules, with a base module holding the core of the app and optional feature modules for extras. The structure is documented in Google's description of the app bundle format, which is worth sharing with anyone on your side who needs to review technical deliverables.
For a business commissioning an app, the practical point is simple: the AAB is the artefact your development partner hands over for release, and it is the file that goes into Play Console.
AAB vs APK: the difference that matters
An APK (Android Package) is Android's installable, executable format. An AAB cannot be installed on a device at all: Google's FAQ states that app bundles are only for publishing, whereas an APK is what runs.
| APK | AAB | |
|---|---|---|
| Purpose | Installing and running the app | Publishing to Google Play |
| Installable on a phone | Yes | No |
| Contains | Code and resources for one build | All code and resources for all device configurations |
| Who generates the final installable files | Your build process | Google Play |
| Signing | You sign the APK | Google Play signs the generated APKs |
| Typical use | Internal testing, direct sharing, other stores | Uploading to Google Play |
The difference shows up most clearly in the build. With a single universal APK, every user downloads code and assets for every screen density, language and processor type, whether their device needs them or not. With an AAB, Google Play generates APKs that contain only what each device requires.
Will switching cost you more?
Generally no. Google's own position is that, for most apps, building an AAB is equivalent in effort to building an APK. The work that does need planning is signing set-up, testing on bundle-generated builds, and any decision to split features into dynamic modules. Those are one-off tasks at the start of a project, not ongoing costs.
The Google search "how much does the Google app bundle cost" has a short answer: the format itself carries no price. Your costs sit in the development, testing and Play Console account, not in choosing AAB over APK.
How Google Play uses your bundle
When you upload an AAB, Google Play generates and serves optimised APKs for each device configuration, so only the code and resources needed for that specific device are downloaded. A phone with a high-density screen and an English language setting does not receive assets for other screen types or languages.
This is called dynamic delivery. The benefit for your users is a smaller download and a faster install. The benefit for you is that app size stops being a trade-off between supporting many devices and keeping downloads light. That matters for retail and consumer apps, where a heavy download costs installs, and for charities and healthcare organisations whose audiences may be on older phones or limited data plans.
Older devices
Not every device can take split APKs. For devices running Android 4.4 (API level 19) and lower, Google Play serves a single multi-APK optimised for the device's configuration. You do not build anything extra for this: Google Play handles it from the same bundle.
Feature modules and larger apps
Because the bundle is modular, a feature that only some users need, such as a scanner, an in-depth help centre or a rarely used booking flow, can sit in its own module and be delivered later. The mechanism is called Play Feature Delivery. It is optional, and many apps never need it. If your app is simple, a single base module is perfectly sound. If you are planning a larger product with distinct user groups, ask your development partner whether modular delivery earns its added complexity.
Signing: where AAB changes your process
With an AAB, signing works differently. Google Play signs the APKs it generates, using Play App Signing. Google's guidance for a first release is to follow the instructions to configure Play App Signing, and it warns that once an app is published to an open track, its signing key is fixed.
That second point is the one to take seriously. Decide who holds the keys and which Play Console account owns the app before the first public release. If your agency publishes under its own developer account and the relationship ends, moving the app later is far harder than setting it up properly at the start. Whatever route you choose, put ownership of the Play Console account and signing arrangements in writing in your contract.
Before you publish: a release checklist
Google's release guidance says that before you start, you should set up the app's store listing, prepare the app for review and configure app pricing. Translated into a working checklist:
- Build the release AAB from a release configuration, with code shrinking and resource optimisation switched on unless your team has a reason to disable them.
- Test the bundle, not just a debug APK. Generate device-specific APKs from the bundle and install them on real handsets, covering at least one older and one recent Android version.
- Set up Play App Signing and record who holds upload keys.
- Complete the store listing: description, screenshots, icon, contact details and privacy policy URL.
- Complete the App content declarations, including the Data safety form.
- Start on a testing track before production. Closed testing lets you check the full install path with a controlled group.
- Roll out in stages where the app is business-critical, so a problem reaches a small share of users first.
Steps 4 and 5 are where releases most often stall, usually because the business side and the technical side each assume the other has the answers.
The Google Play Data safety form
The Data safety section is the part of your Google Play listing that tells users, before they install, what data your app collects, shares and protects. Google defines it as a way for developers to transparently inform users about what data is collected, shared and protected. You complete it as a form in Play Console, and the answers appear on your store listing.
It is separate from uploading your AAB, but you cannot sensibly publish without it. The same review process looks at both.
Who has to complete it
If your app is published on Google Play, you need the form. That includes apps on closed, open or production tracks. Apps active only on internal testing tracks are exempt. Apps that collect no user data must still complete the form to say so.
What you must declare
Developers must disclose the types of user data collected or shared, whether it is encrypted in transit, and whether users can request deletion. This extends to data handled by third-party libraries and SDKs, such as analytics, crash reporting, advertising and login tools. If you use these, check each provider's own published Data safety information rather than guessing.
This is the trap for most businesses. The app you commissioned may collect more than you realise, because every SDK added during development can gather device identifiers, usage events or location. Ask your development partner for a full list of SDKs and what each one collects before anyone fills in the form.
Where to complete it
In Play Console, open the App content page, answer the questions on data collection and handling, preview how the information will appear, and submit the form for Google review. Plan to revisit it whenever you add a feature, change an analytics provider or alter how you handle data. An outdated form is a policy risk, and it undermines the trust it is meant to build.
Data safety and UK data protection
The form is Google's requirement, but your legal duties as a UK organisation come from elsewhere. The Information Commissioner's Office notes that app developers and app store providers have existing responsibilities under the UK GDPR and Data Protection Act 2018 to create and distribute apps with appropriate security and privacy.
Two practical consequences follow:
- Consistency. UK GDPR transparency provisions require clear information about what personal data is collected, what is done with it, who it is shared with and how people can exercise their rights. Your privacy policy carries that detail. Your Data safety answers should be a faithful short version of it. If the two disagree, fix the source of the mismatch before you publish.
- Device storage and access. The Privacy and Electronic Communications Regulations (PECR) apply to technologies that store or access information on a user's device, including in mobile apps. Their use is permitted in particular circumstances or with valid user consent. Check how your app asks for consent where analytics or advertising SDKs are involved.
This is general information, not legal advice. If your app handles health, children's or other sensitive data, speak to your data protection officer or a solicitor who specialises in data protection before you submit.
For more on building privacy into the product itself, our guides on data privacy best practices for mobile app developers and what app privacy labels show and how to get yours right go deeper. If you want the security side, see our overview of mobile app security best practices for UK businesses.
Our perspective
We have shipped more than 300 projects, and the pattern at release is consistent: the build is rarely what delays a launch. Store requirements are. The AAB itself is a routine step. The delays come from unanswered questions about who owns the developer account, which SDKs are in the app and what they collect, and whether the privacy policy says the same thing as the Data safety form.
Our advice is to treat these as design decisions, not release-week paperwork. We raise them during discovery, when it is cheap to choose a lighter analytics tool or drop a third-party library that collects data the app does not need. A smaller data footprint makes the Data safety form shorter, the privacy policy easier to write and the app easier to trust.
We are also technology-agnostic. Whether an app is native or cross-platform, we recommend the platform that suits the project, and the AAB is simply how that Android build reaches Google Play. If a vendor tells you the AAB requirement changes your budget significantly, ask why. For most apps it should not.
— Paul
Getting your app to Google Play with Pocket App
If you are planning an Android app, or inheriting one that needs to move to the bundle format, we can take it from discovery through design, development and deployment, including the store set-up covered above. Our Discover, Design, Develop and Deploy process is how we plan release requirements early. If you already have an app and want an expert second opinion before you publish, our Mobile App Clinics are the place to start. Pricing is scoped per project, so get in touch with the details of what you need.
Common AAB problems and how to avoid them
"Upload a valid app bundle" error. This usually means someone uploaded an APK where Play Console expects an AAB. Rebuild the release as a bundle, in Android Studio or on the command line, and upload the .aab file instead.
Testing only on a debug build. A debug APK does not reproduce what users get from Google Play. Generate device-specific APKs from the bundle and test those, especially if you use feature modules or resource shrinking.
Sharing the file for stakeholder review. Because an AAB cannot be installed, a director cannot tap it on a phone. Ask your development partner for a testing-track invitation, which gives reviewers the real Google Play install, or a separate APK for private internal review.
Leaving the Data safety form to the end. It depends on decisions made throughout the build. Draft it when the SDK list is stable, then confirm it against the final release candidate.
Unclear account ownership. Register the developer account in your organisation's name, not an individual's or a supplier's, and keep admin access within your business.
If you manage Android devices for staff rather than publishing publicly, a different route may suit you better. Our piece on managed Google Play private apps for admins explains how to avoid slow rollouts for internal tools.
FAQ
What is the difference between an Android APK and an app bundle?
An APK is the installable file that runs on an Android device. An app bundle (AAB) is a publishing format that contains all of an app's code and resources, and Google Play uses it to generate optimised APKs for each device. You cannot install an AAB directly.
Do I still need an APK if I publish with an AAB?
For Google Play, you upload the AAB and Google generates the APKs. You may still use APKs for private testing or for distribution outside Google Play, but they are not what you submit to the store for a new app.
Does every app need the Google Play Data safety form?
Every app published on Google Play does, including apps on closed, open or production testing tracks, and apps that collect no data at all. Apps only on internal testing tracks are exempt. You complete the form on the App content page in Play Console.
Do third-party SDKs count in my Data safety answers?
Yes. Data collected or handled by third-party libraries and SDKs in your app must be declared. Ask your development team for the full SDK list and check each provider's published Data safety information before you submit.
Sources
- About Android App Bundles
- Android App Bundle frequently asked questions
- The Android App Bundle format
- Prepare and roll out a release, Play Console Help
- Provide information for Google Play's Data safety section
- ICO response on app security and privacy interventions
- What are storage and access technologies? ICO