APK vs AAB: The New Android Distribution Format Explained
What APK Actually Is (And Why It Ruled Android for 15 Years)
For 15 years, the Android Package Kit—APK—was the only game in town. It has been the standard for Android apps since the platform's 2008 launch. An APK is really just a ZIP archive with a very specific internal structure: it holds the compiled AndroidManifest.xml, the DEX bytecode (classes.dex), a resources.arsc table, and folders for assets, native libraries, and other raw resources. When you grab an app from a website or zap it to a friend with Bluetooth, you’re sending a single .apk file that has everything needed to run on any Android device. That one-size-fits-all approach is both the APK's greatest strength and its fatal flaw. A single APK from the Google Play Store must support everything from a Samsung Galaxy S25 Ultra with a 64-bit ARM chip to a budget Tecno phone with a 32-bit ARM chip, plus Chromebooks on x86 processors and every screen density imaginable. To do this, developers had to pack every version of every native library, translated string, and screen-density image into one massive package. The result? Apps like Google Maps would ship 100 MB APKs when your device only needed about 40 MB of that. The rest was just dead weight—downloaded and stored, but never used.
Android App Bundle: What Changed in 2018 and Why Google Made It Mandatory
Google finally addressed the APK's bloat problem at Google I/O 2018 with the Android App Bundle (AAB), making it mandatory for new Play Store apps in August 2021. While it has an .aab extension and is also a ZIP archive, it’s not an installable app. Think of it as a recipe and a box of ingredients, not the finished cake. An AAB contains the compiled code and resources in modules, but Google Play's servers do the final assembly. This process is called Dynamic Delivery. When a user hits 'Install' in the Play Store, Google's servers look at their specific device—its CPU architecture (ABI), screen density, and language settings. Then, they build and serve a customized set of split APKs containing only what that exact device needs. A Pixel 9 running Android 15 in English might get a 38 MB download, whereas the old monolithic APK would have been a hefty 95 MB. The size reduction isn't theoretical; it's significant and measurable. Google's own 2021 data showed an average size reduction of 15% for apps that switched to AAB, with some cutting their size by over 50%. For a game with huge texture atlases designed for different GPU compression formats (like ETC2, ASTC, and S3TC), the savings can be astronomical, easily stripping hundreds of megabytes from the final installation on the user's phone.
The Internal Structure of an AAB File
If you crack open an AAB with a ZIP utility, you'll immediately see it’s not an APK. The top level has a BundleConfig.pb file, which defines the bundle's configuration, a BUNDLE-METADATA directory, and at least one module directory. The main module is always called `base/`, and it looks a bit like an APK inside, with `dex/`, `manifest/`, `res/`, `root/`, and `lib/` folders. But there’s a critical difference: resources are stored in a `resources.pb` proto format, not the flat binary `resources.arsc` of an APK. This is a key reason an AAB can’t be installed directly. Other feature modules appear alongside the `base/` module, with names like `onboarding/` or `ar_features/`. Each has its own manifest and resources and can be set to download at install-time, right after install (fast-follow), or only when needed. This on-demand model is how an app like Google Earth can avoid burdening every user with 3D city data, fetching it via the Play Core library only when someone actually tries to view a city with that coverage. The `lib/` directory within each module is where the real magic happens for size savings. A cross-platform game might have `arm64-v8a`, `armeabi-v7a`, and `x86_64` subdirectories, each filled with compiled .so libraries. A monolithic APK would bundle all of them. With an AAB, Dynamic Delivery ensures only the single, matching ABI directory is sent. For a game with 80 MB of native code per ABI, that's an instant 160 MB saved on a modern 64-bit phone that has no use for 32-bit or x86 libraries.
APK vs AAB: A Direct Comparison of What Matters to Developers
So what do these differences mean in practice for developers, QA, and users? Let's break down the comparison by what actually matters in your day-to-day work. **Distribution channel support:** Google Play requires AABs for new apps. Simple as that. However, AABs are a Google-only technology. Alternative Android app stores like the Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery, and F-Droid all require good old-fashioned APKs. If you're distributing your app outside of Google Play, you are still in the APK business. This is not a minor detail, especially in markets where Google Play isn't available and APK-only distribution is the standard. **Direct installation:** You can't sideload an AAB. Trying to install one with `adb install app.aab` will just give you an error. To test an AAB locally, you have to use Google's `bundletool` to generate a local APK set or use the `--local-testing` flag in your build. Anyone who has tried to get a non-technical stakeholder to test a build knows that adding extra steps is a recipe for frustration. This definitely adds friction to QA workflows. **Build tooling:** In Android Studio, you create an AAB with Build > Generate Signed Bundle/APK > Android App Bundle, or with the `./gradlew bundleRelease` task. You build an APK with `./gradlew assembleRelease`. Most teams use both, building APKs for internal testing and AABs for the final Play Store upload. **File size on disk:** Here's a common point of confusion: your AAB file will almost always be larger than your APK. A 60 MB APK might generate an 80 MB AAB because the AAB contains the resources for *all* device configurations. The size savings only appear on the user's device after Google Play has done its magic. **Security model:** Both formats are signed, but the process differs. With AABs, you must use Play App Signing. This means you upload your bundle and Google re-signs the final split APKs it generates with a key it manages. While you register this key, Google ultimately holds it, a fact that makes some security-conscious teams nervous. With APKs, you can control the entire signing process with your own keys, no Google involvement required.
Converting Between APK and AAB: What's Possible and What Isn't
This is where honest answers matter more than marketing promises. Let's be blunt: converting an existing APK back into an AAB is not a real thing, and you should be deeply skeptical of any tool that claims it can do it automatically. The problem is fundamental. An AAB needs the original source information—the resource files neatly organized by screen density and language, the proto-format resource table, the module structure. All of that data is compiled, flattened, and optimized away when an APK is created. The `resources.arsc` file in an APK is a binary blob; the original `res/drawable-hdpi/` folder structure is gone. Trying to rebuild that from a compiled APK isn't conversion; it's a painful process of reverse engineering, and the results are almost always incomplete. CocoConvert is built for APK-to-APK operations. You can use it to repackage, rename, and, most usefully, extract the contents of APK files for inspection. Upload an APK, and you can pull out its manifest, see its resource table, or grab specific assets. But what CocoConvert cannot do is generate a valid, Play-ready AAB from an APK. Frankly, no tool can do this reliably if you don't have the original source code project. If you've lost your source and only have an APK, your best bet is a tool like `apktool`. It can decompile the package to smali bytecode and give you an approximation of the resources, but turning that back into a proper project that can be built into an AAB requires a massive amount of manual work. What CocoConvert *is* genuinely useful for is tasks that come up all the time in mobile QA and security research. You can convert APKs to ZIP files to browse their contents, extract specific images or audio files, and even batch-process a whole folder of APKs to audit them. These are the practical, real-world jobs we can help with.
The Sideloading Problem and Why APK Isn't Going Away
Despite Google's big push for AAB, the humble APK isn't going anywhere. Its durability comes from all the use cases that exist completely outside of Google's control. Sideloading—installing an APK from outside the Play Store—is a core feature of Android, enabled by a quick trip to your phone's settings (usually under Settings > Apps > Special App Access > Install Unknown Apps, though the path varies). And the sideloading ecosystem is massive. APKMirror hosts verified APKs of Play Store apps, letting users grab updates before a staged rollout reaches them or install older versions. Enterprise Mobile Device Management (MDM) tools from VMware and Microsoft push APKs to thousands of corporate devices without ever touching the Play Store. Game modding communities live and breathe modified APKs. For developers in regions with limited Play Store access, sharing APKs is the primary method of distribution. For any of these users, AAB is simply irrelevant. It's a format that lives and dies inside Google's walled garden. The second an app needs to be shared, deployed, or installed outside of that ecosystem, it has to be an APK. This is becoming even more relevant with new regulations. The EU's Digital Markets Act is forcing both Apple and Google to open up to alternative app stores. As third-party Android marketplaces gain traction in Europe, they will need a universal format for submissions. Since they can't tap into Google's proprietary Dynamic Delivery infrastructure, that format will be the APK. This could ironically lead to a resurgence in the APK's importance in some of the world's biggest markets, even as Google doubles down on AAB for its own store.
Practical Recommendations Based on Your Situation
So, let's cut to the chase. The right format depends entirely on what you're trying to do. Here’s a no-nonsense guide based on your role. **If you're publishing a new app to Google Play:** You have no choice. You must submit an AAB for any new app since August 2021. Get Play App Signing configured in the Play Console (Setup > App Integrity), set up your Gradle signing config, and run `./gradlew bundleRelease`. Make sure to test it locally with `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` followed by `bundletool install-apks --apks=app.apks`. **If you're distributing to enterprise devices via MDM:** Stick with APKs. Build one with `./gradlew assembleRelease`. Your MDM solution pushes the APK directly to devices. Using an AAB here adds zero value and just creates headaches. **If you're distributing to alternative app stores:** Build APKs. The Amazon Appstore, for instance, has its own developer portal for APK uploads and its own logic for device targeting. They don't use Google's system. **If you're a QA engineer testing a build:** Use APKs for your daily smoke tests and regression testing; they're fast and install directly with `adb install`. For the final pre-release validation, you should build an AAB and use `bundletool` to make sure you're testing what users will actually get from the Play Store. **If you need to inspect an APK you've received:** You can upload it to CocoConvert to quickly extract its contents, or use Android Studio's own APK Analyzer (Build > Analyze APK). The analyzer gives a great visual breakdown of file sizes and is perfect for comparing two different builds to see what changed. Ultimately, the APK vs. AAB debate isn't about which format is technically superior in a vacuum. It's about logistics. The right choice is determined by your distribution channel and your tooling. Both formats are here to stay, serving different paths in the sprawling Android ecosystem.