An APK and an Android App Bundle serve different jobs, so the choice is usually not either-or. An APK is the installable Android package you can put directly on a device, sideload, or distribute through any channel. An AAB is a publishing format you upload to Google Play, which then generates optimized, per-device APKs from it so each user downloads only what their device needs. Since August 2021, Google Play requires new apps to publish as an AAB, so for Play you generate an AAB, while you still use an APK for direct installation, other stores, and local testing. You cannot install an AAB directly, and to test one locally you use bundletool to build and install the APKs it would produce.
Short answer
Generate an AAB for Google Play and an APK for everything else. Per Android's app bundle documentation, an Android App Bundle is a publishing format, not an installable one, and Google Play uses it to generate and serve optimized APKs tailored to each device, which shrinks download size. Since August 2021, new apps on Google Play must be published as an AAB. An APK, by contrast, is directly installable, so you use it to sideload, to publish on stores that take APKs, and to test on a device. To run an AAB locally you use bundletool to build APKs from it and install them.
What an APK is
An APK, an Android Package, is the traditional and directly installable format for an Android app, containing the code and resources a device needs to run it. Because it is installable, you can put an APK straight onto a device by sideloading it, hand it to a tester, or distribute it through channels other than Google Play, such as other app stores or your own website. For most of Android's history, the APK was both how you built and how you shipped an app.
An APK is self-contained in a way that is convenient but not optimal for download size. A single APK typically includes resources for many device configurations, such as multiple screen densities, processor architectures, and languages, so every user downloads assets they will never use. That universality is exactly what makes an APK easy to install anywhere, and it is also what the App Bundle format was created to improve on for Play distribution.
What an Android App Bundle is
An Android App Bundle, with the .aab extension, is a publishing format rather than an installable one, so you do not install an AAB on a device. Instead you upload it to Google Play, and Play uses it to generate a set of optimized APKs and serve each user only the code and resources their specific device needs. This is called dynamic delivery, and it means a user on one device does not download the assets for every other kind of device, so the download and install size is smaller than a universal APK.
Because Play generates and signs the delivered APKs from your bundle, an AAB works together with Play App Signing, where Google holds the app signing key and re-signs the APKs it delivers. So the AAB is your upload artifact, and the APKs users actually install are produced by Play from it. This division is the core idea: you ship one bundle that describes your whole app, and Play tailors what each device receives.
AAB versus APK: which to generate
Which format to generate depends on where the app is going. For Google Play, you generate an AAB, because since August 2021 new apps must be published in that format, and it is what enables the optimized, smaller downloads Play delivers. So if Play is your distribution channel, the AAB is not optional for a new app; it is the required upload.
For anywhere else, you generate an APK, because it is the installable artifact. You use an APK to sideload onto a device, to distribute through stores or channels that accept APKs, to support enterprise or direct distribution, and to test locally. In practice many teams produce both from the same project: an AAB for the Play release and an APK for testing and non-Play distribution. So the honest framing is not AAB or APK but AAB for Play and APK for direct installation, generated as needed.
Can you test an AAB locally?
Not directly, because an AAB is not installable, so you cannot drag it onto a device or emulator the way you can an APK. This trips people who build a release bundle and then find nothing will install it. The bundle is a description of your app that Play turns into APKs, so to run it yourself you need to perform that same conversion locally first.
There are a few ways to do this. The most direct is bundletool, which takes your AAB and produces the APKs it would generate, then installs the right ones on a connected device. Android Studio can also deploy from an app bundle when you run the app, handling the conversion for you. And Google Play's internal app sharing lets you upload a build and get a link that installs the exact APKs Play would deliver, which is the closest test to real delivery. So you can absolutely test an AAB; you just do it through generated APKs rather than the bundle itself.
What is bundletool?
Bundletool is Google's command-line tool for working with Android App Bundles, and it is the same engine Play uses to turn a bundle into deliverable APKs. Its main job is to build an APK set from an AAB, using the build-apks command, which produces the split APKs for different device configurations, and it can also produce a single universal APK that runs on any device when you need one installable file. It then installs the appropriate APKs for a connected device with the install-apks command.
This makes bundletool the bridge between the bundle you build and a device you can test on. When you want to verify that your AAB installs and runs correctly, you generate the APKs with bundletool and install them, which mirrors what a real user would receive from Play. It is also how you inspect what Play will deliver, so bundletool answers both the how do I test this and the what will users actually get questions about an app bundle.
AAB versus APK at a glance
The two differ in purpose, installability, and where they are used, which the table below lays out.
| Attribute | APK | Android App Bundle (AAB) |
|---|---|---|
| Purpose | Installable package | Publishing format for Play |
| Install directly? | Yes | No; Play generates APKs |
| Download size | Universal, larger | Optimized per device, smaller |
| Google Play | Not accepted for new apps | Required for new apps |
| Other stores and sideloading | Yes | Generally no |
Read the install row as the key distinction: an APK you install, an AAB you upload, and bundletool converts a bundle into installable APKs for testing.
The security angle
From a security standpoint, neither format is inherently more resistant to reverse engineering, which is a common misconception when teams move to bundles. The APKs generated from your AAB are ordinary APKs, and like any APK they can be decompiled to inspect code and resources, so shipping to Play as a bundle does not hide your logic or your secrets. What protects your app is not the container but the practices inside it.
So the security work is the same regardless of format. Enable code shrinking and obfuscation with R8 so your compiled code is harder to read, keep secrets and keys out of the app rather than embedding them where a decompiler will find them, and follow the OWASP MASVS controls for storage, cryptography, and platform interaction. The AAB changes how your app is delivered and does add Play App Signing to the picture, but the reverse-engineering surface of the installed app is unchanged, so treat an AAB-delivered app with the same scrutiny as any APK.
How to generate each
Producing each format is straightforward from a standard Android project. The checklist below covers it.
| Step | Action | Done? |
|---|---|---|
| Build an AAB for Play | Use the release bundle task or Build Bundle in the IDE | [ ] |
| Sign for Play App Signing | Sign the bundle with your upload key | [ ] |
| Build an APK for testing | Use the release APK task or Build APK | [ ] |
| Convert an AAB locally | Use bundletool to build APKs from the AAB | [ ] |
| Install to test | Install the APKs on a device with bundletool | [ ] |
| Scan the build | Run a security scan before you ship | [ ] |
The step teams skip most is converting the AAB locally, since they try to install the bundle directly, which does not work, instead of generating APKs from it with bundletool.
Where a scan fits
Choosing a format is a distribution decision, but the security of what you ship is the same either way, and that is worth verifying whichever artifact you produce.
A scanner like PTKD.com analyzes your Android build and flags issues such as exposed keys, weak cryptography, over-broad permissions, and risky third-party code, by severity and mapped to OWASP MASVS. To be clear about the boundary: PTKD does not build your AAB or APK or upload it to Play, which are your build and release steps. Because the APKs delivered from a bundle are ordinary APKs, a scan gives you the same security check whether you ship an AAB to Play or an APK elsewhere.
What to take away
- An APK is the installable Android package for sideloading, other stores, and testing, while an AAB is a publishing format you upload to Google Play.
- Google Play generates optimized, per-device APKs from your AAB, giving users smaller downloads, and requires new apps to publish as an AAB since August 2021.
- You cannot install an AAB directly, so to test one locally you use bundletool to build the APKs it would produce and install them.
- Bundletool is Google's command-line tool that converts a bundle into APKs, can make a universal APK, and installs the right splits to a device.
- Neither format is more secure against reverse engineering, so obfuscate with R8, keep secrets out of the app, and scan the build with a tool like PTKD.com regardless of format.
