Part of: Upload APK Online
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.
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, and it is the difference this page estimates by costing one split from each group on top of 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 on-demand modules and anything shipped as an asset pack. An install-time asset pack does ship with the app, so add its size back from the module list if your bundle has one. 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, use Play Internal App Sharing, or run bundletool build-apks --mode=universal and distribute the universal APK. BetaDrop accepts .apk and .ipa files for exactly this reason.
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: install-time packs ship with the first install and count toward the size Play lists, while fast-follow and on-demand packs download afterwards. The device estimate leaves out on-demand modules and every asset pack and lists them separately with their sizes, so add back any install-time asset pack your bundle carries.
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 leaves out on-demand modules and asset packs, which the module list shows separately with their sizes. On-demand modules and fast-follow or on-demand asset packs arrive after install, if at all. An install-time asset pack ships with the app and counts toward the size Play lists, so add it back if your bundle has one. 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), 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.
