APK vs AAB: Which Should You Upload to Google Play?

The Short Answer

If you are submitting a new app to Google Play in 2026, upload an AAB (Android App Bundle), not an APK. Google has required AAB for all new app submissions since August 2021, and for a first-time publisher there is no scenario where uploading an APK to Play Console is the right move. The only real decision left is what to do if you already have an app that predates that rule, or if you need an APK for somewhere other than Google Play — both covered below.

What Each File Actually Is

An APK (Android Package) is a single, complete, ready-to-install file. It contains everything: the compiled code, every image at every resolution, every language translation, all packaged together. When you sideload an app — install it directly onto a phone without going through an app store — you are installing an APK.

An AAB (Android App Bundle) is not directly installable at all. It is a publishing format: you upload it to Google Play, and Google's own servers use it to generate a set of smaller, device-specific APKs on the fly. A user with a phone that only needs English and one screen density downloads an APK built just for that phone, not a universal file carrying every language and every resolution it will never use.

When Google Requires Which

• New app, first submission: AAB. No exceptions.
• Updating an app that existed before August 2021: AAB is still required for the update itself, but Google allows a signing-key upgrade path where you upload both an AAB and a legacy APK signed with your old key, so existing installs continue to update smoothly.
• Private, internal company apps distributed through Managed Play: APK is still accepted through that specific channel.
• Distributing outside Google Play — your own website, a client's device fleet, a QR code at an event, another app store: build and share an APK directly. The AAB requirement is a Google Play submission rule; it has no bearing on how you distribute your app anywhere else.

Why AAB Is Not Just Google Being Difficult

It is easy to read "Google requires a new format" as friction for its own sake. In this case the format switch solves a real problem. Before AAB, developers had two bad options: ship one bloated universal APK containing every density and language, or maintain several separate APK variants per device configuration and manage the release logistics themselves. AAB moves that job onto Google's infrastructure, which is one reason app sizes across the Play Store dropped noticeably in the years after AAB became mandatory.

Building Both with Free App Maker

Free App Maker generates both formats from the same build, so there is nothing to configure by hand. Choose AAB when your destination is the Play Store, and APK when you want to test on a device directly, hand a file to a client for review, or distribute outside Google Play entirely. Both are signed automatically, so either one is ready to use the moment the build finishes — see our step-by-step conversion guide if you have not built your first app yet.

How This Shows Up in Play Console

When you open Release > Production > Create new release for a new app, the upload panel only accepts an .aab file — there is no toggle to switch it to APK, because for a first submission Google does not offer the option. If you have an existing pre-2021 app doing a signing-key upgrade, Play Console's upload step for that specific flow accepts both files together, clearly labelled. Outside Play Console entirely — testing on your own device, or handing a file to someone directly — there is no upload step at all; you simply share the .apk file and the recipient installs it.

Frequently Asked Questions

Can I test an AAB file directly on my phone?
Not the way you would an APK. An AAB is not installable on its own — you either upload it to Play Console and use internal testing, or use a tool like bundletool to generate an installable APK set from it locally. For quick device testing during development, an APK is simpler.

Does an AAB make my app less secure?
No. Google signs the generated APKs using the same signing key infrastructure either way (Play App Signing). The format affects packaging and delivery, not code integrity.

My app predates AAB. Do I have to switch?
Only when you next update it. Existing published APK-only apps kept working after the August 2021 cutoff; the requirement applies to new submissions and, from that point forward, to updates as well.

Is there a downside to AAB?
The main one raised by developers is losing direct control over the exact APK a specific device receives, since Google's servers generate it. For the vast majority of apps this trade-off is invisible; it mainly matters for very unusual device-targeting setups.

Do I need different signing keys for APK and AAB?
No — Play App Signing manages one signing identity for your app regardless of which format you upload; the AAB and any legacy APK in a key-upgrade scenario are signed under the same Google-managed key.

Where do I choose the format when publishing?
In Play Console, under Release > Production > Create new release, the upload step only accepts AAB for a new app — see our full Google Play publishing guide for the entire submission walkthrough.

Conclusion

For a new app in 2026 this is not really a choice: Google Play requires AAB, and it produces a smaller download for your users than a universal APK would. Keep an APK on hand for direct testing, client handoffs, and any distribution outside the Play Store — Free App Maker builds both from a single conversion, so you are never stuck rebuilding to get the other format.