Open an .aab and see what a device actually downloads
An Android App Bundle is a publishing format, not an app. Google Play takes it apart and builds a smaller APK for each device, so the size of the .aab on your disk is a number none of your users will ever experience. This tool reads the bundle in your browser and estimates the size that matters — plus the manifest, the modules, and what it splits on.
Nothing leaves your machine. The file is parsed in the tab, which is the only sensible way to look inside an unreleased build.
Drop an .aab here, or click to choose one
Nothing is uploaded — the bundle is read in this tab. Up to 250 MB.
Frequently Asked Questions
What is an Android App Bundle (.aab)?
An .aab is a publishing format, not an install format. It is a zip archive holding one directory per module — base/ plus any feature modules and asset packs — and each module carries its own AndroidManifest.xml, dex/, res/, lib/ and assets/. Google Play takes that bundle and generates the APKs a particular device needs, so nothing inside an .aab installs as-is and no device ever downloads the whole file.
Why is the .aab file size not the download size?
Because Play splits it. A bundle carries every CPU architecture, every screen density and every language the app supports, while a device receives the shared code and resources plus the one ABI, the one density bucket and the one language it actually uses. That is how a 60 MB bundle becomes a far smaller install. This page estimates the difference: it groups every entry by lib/<abi>, by density qualifier and by language qualifier, costs one split from each group — a mainstream device's for ABI and density, and the heaviest locale for language so the figure errs high rather than low — and adds those to the bytes every device pays regardless.
How accurate is the install size estimate?
It is an estimate, and the assumptions behind it are listed next to the number rather than buried. It uses compressed entry sizes, one ABI (arm64-v8a where the bundle has it), one density (xxhdpi where available), one language, and it leaves out modules declared on-demand or conditional, and anything shipped as an asset pack. It does not model the exact split APKs Play builds or how Play re-compresses them, so treat it as the right order of magnitude and not a figure to quote in a release note. For Play's own numbers, build an APK set with bundletool and run bundletool get-size total --apks=app.apks.
What is the difference between an AAB and an APK?
An APK is a finished, installable package for one device configuration, signed by whoever built it. An AAB is the upload format: it holds every configuration at once, it is signed with your upload key rather than the key users verify, and Play re-signs the APKs it generates with the app signing key. Since August 2021 new apps on Google Play must be published as app bundles, while APKs remain the format for sideloading, internal test builds and any distribution that does not go through Play.
Can I install an .aab file on a phone?
No. Android installs APKs, and an .aab contains no installable APK — those are generated afterwards, by Play or by bundletool. To get a build onto a tester's device, either use Play Internal App Sharing or run bundletool build-apks --mode=universal to produce a single universal APK and distribute that. BetaDrop accepts .apk and .ipa files for exactly this reason: an .aab would hand testers a file their phone cannot open.
Is my bundle uploaded to a server?
No. The .aab is opened with a JavaScript zip reader inside the page and its protobuf manifest is decoded in the browser, so the file never leaves your machine — nothing is uploaded, logged or stored. The practical ceiling is 250 MB per file; a larger bundle is refused rather than left to exhaust the tab's memory.
Why are some manifest values marked as decoded?
Because they were inferred rather than read. An .aab stores its manifest as protobuf, and aapt2 sometimes puts a numeric attribute — versionCode, minSdkVersion, targetSdkVersion — into a compiled item instead of a literal string. Recovering the number means walking that item and taking the first scalar inside it, which is dependable for the numbers and booleans shown here but is not the same as reading a string off the file. Every value obtained that way is marked, so you know which ones to confirm against your Gradle config.
What do the module delivery labels mean?
Each module declares how it should be delivered and the tool reads that declaration from the module's own manifest. install-time modules ship with the first install. on-demand modules download later, when the app asks for them. conditional modules install only on devices matching a condition such as a country or a minimum API level. Asset packs are asset-only modules with their own delivery rules. Anything not delivered at install time is excluded from the device estimate and reported separately, because deferring it is the entire point of declaring it.
Does this tool tell me whether the bundle is signed?
It reports whether a JAR signature is present in META-INF/, which is what Play checks on upload: the bundle has to be signed with your upload key. That is not a statement about what users verify, because Play re-signs the delivered APKs with the app signing key, so the certificate inside your .aab is not the one that ends up on the device. An unsigned bundle is fine for local bundletool runs and will be rejected on upload.
Why your bundle looks so much bigger than your app
A bundle carries every variant at once: every native ABI, every screen density, every language. A device takes one of each. That is where the difference goes, and it is why a bundle with native libraries can be three or four times the install it produces — the other ABIs are simply never sent.
The estimate above costs one ABI, one density and one language, and excludes anything your bundle declares as on-demand, conditional, or an asset pack — those arrive after install, if at all. It is deliberately an estimate: only bundletool and the Play Console can give you the exact per-device figure, and this tool says what it assumed rather than presenting a number as though it came from Play.
Your testers cannot install an .aab
This is the most common surprise with bundles, and it is by design: Android has no way to install one. A device installs APKs. If you send a bundle to a tester, they get a file their phone will not open, no matter how they try.
To hand a build to someone directly, generate APKs first — bundletool build-apks --mode=universal produces a single APK that installs anywhere — and then share that APK over a link. For the full workflow, including the Play-side testing tracks, see the guide to testing Android App Bundles.
What this reads, and what it infers
A bundle stores its manifest as protobuf rather than the binary XML an APK uses, so names and text values — package, permissions, module declarations — are read directly. Numbers and booleans are the awkward case: the compiler often stores them in a compiled value whose encoding varies by type, so this tool finds them by inspection rather than by assuming a fixed layout.
Anything obtained that way is marked decoded beside the value. That is not a disclaimer for its own sake: a version code is the field people copy into a bug report, and it should be obvious which numbers were read and which were inferred. If you need a guaranteed answer, bundletool dump manifest is the authority.
Bundle or APK — which should you build?
Both, for different jobs. Play has required an .aab for new apps since August 2021, so that is what you upload. But an APK is what you send a tester, attach to a bug, sideload onto a device in front of you, or hand to a client who wants to try the build without a Play account.
If you are comparing the formats themselves rather than inspecting one, the IPA vs APK explainer covers where each fits, and the APK inspector opens the APKs your bundle produces.
