What Is an AAB File? How to Open and Install One

An AAB (Android App Bundle) is a publishing file for an Android app. It contains compiled app code and resources arranged in modules, but an Android phone cannot install the .aab file directly. A store or compatible tool processes it into installable APKs. To test your own bundle locally, use Google’s bundletool to create an APK set and install it on a connected device. Android Developers’ AAB FAQ explains the format and its relationship to APKs.

What an AAB file contains and what it is for

An Android App Bundle packages the app’s compiled code and resources, often divided into a base module and optional feature modules. It is intended as input for publishing. A distributor can use the bundle to generate APKs containing the base app plus the configuration and features needed by a particular device. That means users may receive a device-appropriate set rather than one universal APK. See the official Android build guide and bundletool guide.

The key distinction is simple: AAB is a publishing format; APK is Android’s installable app package. Google Play and other compatible distributors process AABs into APKs. For local testing, developers can do that processing with bundletool. An AAB is not an archive that you can tap on a phone to install.

AAB vs. APK

Question	AAB	APK
Primary role	Publishing input containing app modules and resources	Installable Android app package
Can Android install it directly?	No	Yes, when properly signed and compatible
Who creates device-targeted output?	A distributor or developer tooling processes it	It is already an installable artifact
Typical action	Upload it to a compatible store, or use bundletool for testing	Install it through a store or a supported APK workflow

App bundles are not exclusive to Google Play: Android Developers describes AAB as an open format supported by Google Play and other app stores. Whether another store accepts a bundle depends on that store’s support; check its current publishing requirements.

How to open an AAB file

“Open” can mean viewing the file’s contents, installing the app, or validating a release. Choose the workflow that matches your goal:

You received an AAB and want to use the app: ask the publisher for its official store listing or an APK distribution. The bundle itself cannot be installed. AAB does not prevent sideloading APKs; it simply is not an installable file.
You are the developer and need a local test install: use bundletool to produce an .apks archive, then install it to a connected Android device.
You want to inspect the delivered package: generate APKs with bundletool and inspect the output, or use the official Android build and bundle tooling. An AAB is structured for packaging and distribution, not execution.
You are publishing to Google Play: upload the signed AAB through Play Console. Google Play processes it into APKs for users.

Install an AAB on a connected device with bundletool

This workflow is for developers testing a bundle they own or are authorized to test. It requires the AAB, the bundletool command-line tool, and Android Debug Bridge (adb) with a connected device that has USB debugging enabled. Follow Google’s current bundletool documentation for installation and options.

Install Java if required by the bundletool release you use, download the official bundletool JAR from its GitHub repository, and confirm adb can see the device with adb devices.
Place your bundle at app.aab or substitute its path in the commands below.
Build an APK set. For a quick local test, bundletool attempts to sign generated APKs with a debug key if you do not provide signing information.
Install the matching APKs from that set to the connected device.

java -jar bundletool-all.jar build-apks --bundle=app.aab --output=app.apks
java -jar bundletool-all.jar install-apks --apks=app.apks

If the bundletool JAR is on your PATH through a wrapper, the shorter documented form is:

bundletool build-apks --bundle=app.aab --output=app.apks
bundletool install-apks --apks=app.apks

For multiple connected devices, select one explicitly with --device-id on the appropriate bundletool command. To build only for the connected device, use --connected-device on build-apks. The bundletool guide also supports generating a device specification JSON and using it with --device-spec when you need repeatable output for a particular configuration.

Use your own signing key for test APKs

For testing an update over an already installed build, the generated APKs must be signed with a compatible key. A debug-signed build usually cannot update an app signed with a different release key. Keep keystore passwords out of source control and command history; bundletool accepts password file arguments.

bundletool build-apks \
  --bundle=app.aab \
  --output=app.apks \
  --ks=release-or-test-key.jks \
  --ks-pass=file:keystore-password.txt \
  --ks-key-alias=MyKeyAlias \
  --key-pass=file:key-password.txt

If you omit signing flags, bundletool attempts to use a debug key. That is convenient for a clean test install, but it does not reproduce the signing identity of a production release. For production publication, sign the AAB with the upload key configured for your release process and upload it to the store. Android’s command-line guide specifies jarsigner for signing an AAB; apksigner signs APKs and cannot sign an AAB.

Install a generated APK set manually

The .apks file is an APK set archive, not a single APK. Usually the easiest way to deploy it is bundletool install-apks, which selects the APKs appropriate for the connected device. If you need to inspect or transfer artifacts, you can extract the archive, but do not assume that any one APK inside the set is sufficient: split APKs commonly need to be installed together. Use bundletool’s device-aware deployment instead of selecting a random split.

Publish an AAB through Google Play

Build a release AAB from the Android Gradle plugin or Android Studio.
Sign it using the upload signing setup for your Play Console app. If signing an AAB manually from the command line, Android documents jarsigner; apksigner is not for AABs.
Upload the AAB in Play Console, typically to an internal, closed, or production track according to your release plan.
Use a test track or local bundletool install to validate installation and behavior before broad distribution.

For users, the normal path is to install the app from the store. Play processes the uploaded bundle into APKs suited to each device. Avoid sending end users an AAB and telling them to tap it to install.

Useful bundletool options

Option or command	When to use it
`--bundle=PATH`	Required input AAB for `build-apks`.
`--output=PATH`	Required output path for the APK set archive.
`--overwrite`	Replace an existing output file instead of failing because the path already exists.
`--connected-device`	Build APKs targeted to a connected device’s configuration.
`--device-spec=PATH`	Build for a saved device specification, useful for repeatable testing.
`--device-id=SERIAL`	Select one device when multiple devices are connected.
`--ks`, `--ks-pass`, `--ks-key-alias`, `--key-pass`	Provide the signing keystore and key information for generated APKs. Passwords can be read from files.
`get-device-spec`	Save the connected device configuration as JSON for a later build.

Consult the live bundletool reference for the complete current option list; command flags can change across releases.

Common errors and fixes

Error or symptom	Likely cause	What to do
“App not installed” after tapping an `.aab`	An AAB is not installable by Android.	Install from the official store, request an APK from the publisher, or use bundletool if you are testing the bundle.
`bundletool: command not found`	The tool is not installed or its wrapper is not on PATH.	Run the downloaded JAR with `java -jar bundletool-all.jar`, or configure the wrapper on PATH.
“File already exists” for the output	The target `.apks` path already exists.	Choose a new output name or add `--overwrite`.
No device found, or install cannot connect	`adb` does not see an authorized device, or more than one target is ambiguous.	Check `adb devices`, authorize the computer on the phone, reconnect, and pass `--device-id` when needed.
APK signature or update conflict	The installed app and generated APK set use different signing keys, or the app version/package identity is incompatible.	Use the matching key for an update test, or uninstall the old test app before a clean install. Uninstalling removes that app’s local data.
Missing resource or feature on a device	A device-specific split may be missing, or a dynamic feature delivery path was not exercised.	Install the complete APK set with bundletool and test feature delivery using the documented local testing workflow or a Play test track.
Trying to sign an AAB with `apksigner`	`apksigner` is for APKs.	Use the configured Gradle signing process or `jarsigner` for an AAB, as documented by Android.

Performance, reliability, and cost considerations

Build size and download: the distributor can generate device-specific APKs from bundle contents, so devices need not receive every configuration’s resources. Actual size depends on the app and device configuration; do not assume a fixed saving.
Testing fidelity: bundletool locally recreates parts of the bundle-to-APK workflow and deploys matching splits. A Play test track is still useful for validating store-side release and delivery behavior.
Repeatability: save device specs for stable CI or regression builds, record the bundletool version, and use deterministic input artifacts. Use a specified device ID in multi-device labs.
Signing reliability: maintain the upload key safely and distinguish it from debug keys. Keep passwords in protected CI secrets or password files, and ensure release artifacts are signed through the intended pipeline.
Cost: bundletool is command-line software and the basic local workflow does not require a paid screenshot or capture service. Device labs, build infrastructure, and store account terms are separate considerations.

Or skip the browser setup

For web screenshots used in release notes, documentation, or app listings, ScreenshotNeo takes a screenshot or PDF from one API request. This is separate from AAB processing: it captures a web page, not an Android bundle. The API accepts a URL and returns PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and removed before capture; newsletter popups and chat widgets are removed too.
Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed; response headers report the page verdict and billing status.
An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
1,000 screenshots per month are free with no card. Paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

FAQ

Can I convert an AAB to one universal APK?

Bundletool can produce APK artifacts, but bundle-based output may consist of multiple splits tailored to device configuration. Use install-apks to deploy the right combination. If you need a standalone APK for sharing, build an APK variant from the project when appropriate.

Can I install an AAB without a computer?

Not directly on Android. Use the app’s store listing or obtain an installable APK distribution from its publisher.

Does an AAB only work with Google Play?

No. The format is open and other stores can support it, but each distributor decides which formats it accepts.

Can I inspect an AAB by renaming it to ZIP?

Renaming does not turn it into an installable app or provide a supported inspection workflow. Use Android build tools and bundletool to generate and inspect the relevant outputs.

Who should receive the AAB?

Normally, the store or distribution pipeline receives the signed bundle. End users receive installable APKs through that distribution channel.