APK vs AAB: The New Android Distribution Format Explained
What APK Actually Is (And Why It Ruled Android for 15 Years)
The Android Package Kit — APK — has been the standard container for Android applications since the platform launched in 2008. Structurally, an APK is a ZIP archive with a specific internal layout: a compiled AndroidManifest.xml, the DEX bytecode files (classes.dex), a resources.arsc table, and folders for assets, native libraries (.so files), and raw resources. When you sideload an app from a website or share it between phones using Bluetooth, you're moving a single .apk file that contains everything the app needs to run on any Android device. That universality is both the format's greatest strength and its biggest problem. A single APK shipped to the Google Play Store has to work on a Samsung Galaxy S25 Ultra running a 64-bit ARM chip, a budget Tecno device running a 32-bit ARM chip, a Chromebook with an x86 processor, and every screen density from ldpi (120 dpi) to xxxhdpi (640 dpi). To cover all those combinations, developers historically bundled every native library variant, every set of translated strings, and every screen-density drawable into one package. The result? Apps like Google Maps have historically shipped APKs exceeding 100 MB even when the average user's device only needed roughly 40 MB of that content. The rest was dead weight — downloaded, stored, and never executed.
Android App Bundle: What Changed in 2018 and Why Google Made It Mandatory
Google introduced the Android App Bundle (AAB) format at Google I/O 2018 and made it mandatory for new apps on Google Play starting August 2021. The file extension is .aab, and while it looks superficially similar to an APK — it's also a ZIP-based archive — its internal structure is fundamentally different. An AAB contains the compiled code and resources organized into a base module and optional feature modules, but it does not contain a fully assembled, installable package. Instead, it contains the raw ingredients that Google Play's infrastructure uses to build a tailored APK set for each specific device. The mechanism behind this is called Play Asset Delivery and, more specifically, the App Bundle format uses a process Google calls Dynamic Delivery. When a user downloads your app from the Play Store, Google's servers analyze the device's ABI (CPU architecture), screen density, and language settings, then assemble a set of split APKs — a base APK plus configuration APKs — that together contain only what that device needs. A Pixel 9 running Android 15 with English set as its only language might receive a 38 MB install where the equivalent monolithic APK would have been 95 MB. The size reduction is measurable and significant. Google's own data from 2021 showed that apps migrated to AAB saw an average size reduction of 15%, with some apps achieving over 50% reduction. For a game with large texture atlases targeting multiple GPU compression formats (ETC2, ASTC, S3TC), the savings can be dramatic — potentially hundreds of megabytes stripped from the user's installation.
The Internal Structure of an AAB File
Cracking open an AAB with any ZIP utility reveals a directory tree that differs meaningfully from an APK. At the top level you'll find a BundleConfig.pb — a protocol buffer file encoding the bundle's configuration — alongside a BUNDLE-METADATA directory and one or more module directories. The base module, always named base/, mirrors a lot of APK structure: it contains dex/, manifest/, res/, root/, and lib/ subdirectories. However, resources are stored in proto format (resources.pb) rather than the binary resources.arsc used in APKs, because the AAB is not meant to be installed directly. Feature modules sit alongside base/ as sibling directories — for example, onboarding/ or ar_features/ — each with their own manifest and resources. These can be configured as install-time, fast-follow, or on-demand modules. An on-demand module is not downloaded when the user first installs the app; it's fetched only when the app explicitly requests it via the Play Core library. This is how apps like Google Earth serve 3D city data only to users who actually navigate to cities with 3D coverage. The lib/ directory inside each module is where the ABI split savings are most obvious. A typical cross-platform game might include arm64-v8a, armeabi-v7a, and x86_64 subdirectories, each containing the full set of compiled .so files. In a monolithic APK, all three are bundled together. In an AAB, Dynamic Delivery ensures only the matching ABI directory is sent to each device. For a game with 80 MB of native libraries per ABI, that's potentially 160 MB saved on a modern 64-bit device that will never touch the 32-bit libraries.
APK vs AAB: A Direct Comparison of What Matters to Developers
The practical differences between the two formats break down along several axes that matter depending on your role — developer, QA engineer, or end user. **Distribution channel support:** AAB is required by Google Play for new apps, but it is not supported by alternative Android app stores. Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery, and F-Droid all require APK submissions. If you're distributing outside Google Play, APK remains your only option. This isn't a minor footnote — in markets like China where Google Play is unavailable, APK-only distribution is the norm. **Direct installation:** You cannot sideload an AAB onto a device. If you pull an .aab file from your build system and try to install it with `adb install app.aab`, you'll get an error. To test an AAB locally, you need either bundletool (Google's open-source command-line tool) to generate a local APK set, or you use the `--local-testing` flag in your build configuration. This adds friction to QA workflows. **Build tooling:** Android Studio generates AABs via Build > Generate Signed Bundle/APK > Android App Bundle. The Gradle task is `./gradlew bundleRelease`. APKs are built with `./gradlew assembleRelease`. Both coexist in a typical project; many teams build APKs for internal testing and AABs for Play Store submission. **File size on disk:** An AAB is typically larger than the equivalent APK because it contains resources for all configurations rather than one. A 60 MB APK might produce an 80 MB AAB. The savings manifest on the user's device, not in the file you upload. **Security model:** Both formats support signing. AABs use Play App Signing, where Google re-signs the generated split APKs with a key you register in the Play Console. This means Google holds the final signing key, which some security-conscious teams find uncomfortable. APKs can be signed entirely with your own keys without Google's involvement.
Converting Between APK and AAB: What's Possible and What Isn't
This is where honest answers matter more than marketing promises. Converting an APK to an AAB is not straightforward, and any tool claiming a lossless, automated APK-to-AAB conversion deserves skepticism. An AAB requires source-level information — the original resource files organized by configuration qualifier, the proto-format resource table, the module structure — that is compiled away during APK creation. When you build an APK, resources.arsc is a flattened binary table; the original res/ folder structure with its drawable-hdpi/, drawable-xhdpi/ qualifiers is gone. Reconstructing that structure from a compiled APK is reverse engineering, not conversion, and the result will be incomplete. CocoConvert supports APK-to-APK operations — specifically, repackaging, renaming, and extracting contents from APK files for inspection purposes. You can upload an APK and extract its manifest, inspect its resource table, or pull out specific assets. What CocoConvert cannot do is generate a valid, Play-ready AAB from an APK. Nobody can do this reliably without the original source project. The realistic workflow for teams who need an AAB is to build it from source using Android Studio or a CI pipeline with Gradle. If you've lost your source code and have only an APK, tools like apktool can partially decompile it to smali bytecode and approximate resource files, but the resulting project cannot be rebuilt into a proper AAB without significant manual reconstruction. What CocoConvert can genuinely help with: converting APK files to ZIP for content inspection, extracting specific file types from inside an APK (images, audio files, raw assets), and batch-processing multiple APKs when you need to audit a collection of packages. These are practical tasks that come up regularly in mobile QA, security research, and app archiving workflows.
The Sideloading Problem and Why APK Isn't Going Away
Despite Google's push toward AAB, the APK format has a durability that stems from use cases Google doesn't control. Sideloading — installing APKs from outside the Play Store — is legal on Android and enabled by toggling Settings > Apps > Special App Access > Install Unknown Apps on modern Android versions (the exact path varies by manufacturer; on Samsung One UI 6, it's Settings > Apps > three-dot menu > Special Access > Install Unknown Apps). The sideloading ecosystem is enormous. APKMirror hosts verified APK mirrors of Play Store apps, allowing users to install older versions or get updates faster than Play's staged rollout allows. Enterprise MDM (Mobile Device Management) solutions from vendors like VMware Workspace ONE and Microsoft Intune routinely distribute APKs to managed devices without touching the Play Store. Game modding communities distribute modified APKs. Developers in countries with restricted Play Store access rely on APK sharing. For these users, AAB is irrelevant. The format exists entirely within Google's infrastructure. The moment an app leaves the Play Store ecosystem — whether by direct download, enterprise deployment, or peer sharing — it must be an APK. There's also a regulatory dimension emerging. The EU's Digital Markets Act has pushed Apple and Google toward allowing alternative app stores. If third-party Android app marketplaces grow in the EU, they'll need to support APK distribution since they can't access Google's Dynamic Delivery infrastructure. This could actually increase APK's relevance in certain markets over the next few years, even as Google continues mandating AAB for Play submissions.
Practical Recommendations Based on Your Situation
The right format depends entirely on what you're trying to accomplish, so here's a situation-by-situation breakdown rather than a one-size-fits-all answer. **If you're publishing a new app to Google Play:** You must submit an AAB. There's no opt-out for apps created after August 2021. Set up Play App Signing in the Play Console under Setup > App Integrity, configure your Gradle signing config, and run `./gradlew bundleRelease`. Test the output locally with bundletool: `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing`, then `bundletool install-apks --apks=app.apks`. **If you're distributing to enterprise devices via MDM:** Build an APK with `./gradlew assembleRelease`. Your MDM solution will push the APK directly to enrolled devices. AAB adds no value here and creates unnecessary complexity. **If you're distributing to alternative app stores:** Build APKs. Amazon Appstore, for example, accepts APK uploads through its developer portal and has its own device-targeting logic separate from Google's Dynamic Delivery. **If you're a QA engineer testing a build before release:** Build APKs for daily testing — they install directly with `adb install`. Build an AAB for final pre-submission validation using bundletool to simulate what Play will deliver to different device profiles. **If you need to inspect an APK you've received:** Upload it to CocoConvert to extract its contents, or use Android Studio's built-in APK Analyzer (Build > Analyze APK) which gives you a detailed breakdown of file sizes by category and lets you compare two APK builds side by side. The APK vs AAB question ultimately isn't about which format is better in the abstract — it's about which format your distribution channel requires and what tooling you have available. Both formats will coexist in the Android ecosystem for the foreseeable future, serving different distribution paths that have different technical requirements.