Convert APK to AAB

Google Play requires Android App Bundles for new app uploads, so a developer may need an AAB when an older build exists only as an APK. An APK can be installed directly, but an AAB must normally be rebuilt from the original Android project or reconstructed locally from the APK.

What the APK format is

An APK is an Android application package that phones, tablets, Android TV devices, and emulators install directly. It is a ZIP-based archive containing compiled code, resources, the manifest, assets, native libraries, and APK signing information.

Android Studio and the Android Gradle Plugin generate APKs through Gradle tasks such as ./gradlew assembleRelease. Developers also receive APKs from build servers, testing services, device extraction, and distribution outside Google Play. An APK is an installation format; an Android device does not install an AAB directly.

What the AAB format is

An AAB, or Android App Bundle, is a publishing package containing an app's compiled modules and resources. Google Play processes it into device-specific APKs, selecting the required screen density, language resources, CPU architecture, and dynamic features instead of delivering everything in one universal APK.

This can reduce download size and enables Google Play Feature Delivery and Play Asset Delivery. An AAB is normally produced from an Android Studio or Gradle project with ./gradlew bundleRelease, which commonly creates app/build/outputs/bundle/release/app-release.aab. The release build must have a valid signing configuration before it can be uploaded.

How to create an AAB from the original project

1. Open the project in a compatible Android Studio and synchronize its Gradle and Android Gradle Plugin versions. Use the versions required by the project rather than upgrading them indiscriminately.
2. Check the application ID, version code, release dependencies, product flavors, native libraries, manifest declarations, and signing configuration.
3. In Android Studio, select Build → Generate Signed Bundle / APK, choose Android App Bundle, select the release variant, and provide the keystore and key credentials. Alternatively, run ./gradlew bundleRelease from the project directory.
4. Retrieve the result from app/build/outputs/bundle/release/. A multi-module project may place the bundle under the relevant module's output directory instead.
5. Validate and test the bundle with Google's official bundletool. For example, bundletool validate --bundle=app-release.aab checks its structure. To create installable APKs for a connected device, run bundletool build-apks --bundle=app-release.aab --output=app.apks --connected-device, supplying the required keystore options if bundletool needs to sign the generated APKs, then run bundletool install-apks --apks=app.apks.

Android Studio is the appropriate desktop option because it preserves Gradle configuration, resource processing, signing, build variants, and dynamic-feature modules. bundletool is Google's command-line utility for validating, inspecting, building, and installing APK sets from an AAB; it does not convert an arbitrary finished APK into a source project or equivalent bundle.

If only the APK is available

There is no reliable one-command conversion from a finished APK to an equivalent AAB. Compilation, resource processing, code shrinking, dependency resolution, and signing have already occurred, and the APK does not contain the complete Gradle project required to reproduce those steps.

For an application you own, reconstruction is possible but is a new build rather than a file-format conversion:

1. Decode resources and the manifest with apktool d app.apk -o decoded-app.
2. Inspect decompiled Java or Kotlin-like code with jadx-gui app.apk. Decompiled output is for reference and usually needs substantial correction before it can compile.
3. Create an Android Studio project and restore the package structure, resources, assets, manifest declarations, native libraries, dependencies, Gradle settings, and any required dynamic-feature modules.
4. Resolve compilation and runtime differences, configure the correct application ID and version code, then generate and sign the release bundle with ./gradlew bundleRelease.

Generic online APK-to-AAB converters are not a suitable substitute for this process. No reputable online service can reliably recover missing source code and build configuration from an APK, and uploading an APK can expose proprietary code, embedded credentials, certificates, or application data. Keep reconstruction local; use Google Play Console only to upload and test the resulting AAB.

Compatibility and publishing limitations

• A rebuilt bundle can behave differently because obfuscation, removed resources, generated code, native build settings, and dependency versions may not be recoverable from the APK.
• An update must use the same application ID and a signing identity accepted for the existing app. With Google Play App Signing, the upload must use the registered upload key; possessing an APK does not provide permission to publish an update.
• An APK extracted from a device may be only one split from an installed app. A complete installation can contain base, configuration, and feature split APKs, so one extracted split cannot recreate the original bundle.
• An AAB is a publishing format, not a normal sideloading format. For direct installation, build an APK or use bundletool to generate the appropriate APK set from the bundle.
• Test the release output on representative Android versions, screen densities, and CPU architectures, especially after reconstructing native libraries or dynamic features.