AAB — what it is, difference from APK and working principle

What is AAB

AAB (Android App Bundle) is a publishing format developed by Google as a replacement for APK for distribution through Google Play. Inside AAB is a ZIP archive with the .aab extension containing compiled code, resources and metadata. The key difference: AAB is not installed directly on a device.

How it works

The developer uploads AAB to Google Play Console. When a user tries to install the application, Google Play analyzes the device configuration: screen density (DPI), CPU architecture, language and Android version. Based on this analysis, a minimal APK is generated containing only the necessary components.

History of adoption

Google introduced AAB in 2018 at the I/O conference. Since August 2021, the format has become mandatory for all new applications on Google Play. Existing applications can continue using APK, but new ones must be published only in AAB.

How AAB differs from APK

The difference between AAB and APK is fundamental: APK is a complete installation file ready for installation. AAB is a container with source components that requires processing.

APK is suitable for distribution outside Google Play — via websites, email or corporate MDM systems. AAB is tied to Google Play infrastructure and cannot be installed directly. For testing AAB, the bundletool utility is used, which emulates APK generation on a local machine.

AAB file structure

The internal structure of AAB is similar to APK but contains additional directories and files for describing modules and their dependencies.

Base module (base)

The base module is a mandatory component of AAB. It contains the main code, resources and application manifest. Without the base module, the application cannot be built. All other modules are optional and are connected via Dynamic Delivery.

Protobuf format

AAB configuration uses Protocol Buffers (protobuf) instead of XML. .pb files are more compact and parse faster by Google's server infrastructure. The bundletool utility converts protobuf to a readable format for debugging.

Dynamic Delivery and app modules

Dynamic Delivery is the key technology behind AAB. It allows delivering to the user only those parts of the application that match their device and language, as well as loading additional modules on demand.

Module types

Install-time modules are loaded together with the base APK during installation. Conditional modules are delivered only when conditions are met — for example, a module with materials for 4K screens. On-demand modules are loaded at the user's request within the application.

Play Asset Delivery (PAD)

For large resources (up to 2 GB), Play Asset Delivery is used instead of OBB files. PAD supports the same three delivery modes: install-time, fast-follow (immediately after installation) and on-demand.

// Loading on-demand module via SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Module configuration in Gradle

Each dynamic module is described by a separate build.gradle file specifying the delivery type. A module can contain its own resources, code and manifest, independent of the base application.

Building AAB via Gradle

Building AAB is done through the Android Gradle Plugin with the bundleRelease (or bundleDebug) task. The result is a .aab file in the build/outputs/bundle/ directory.

Build configuration

No special configuration is required for building AAB — Android Gradle Plugin supports bundles by default. Simply specify the bundle task instead of assemble.

// build.gradle.kts — building AAB with signing
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Task: ./gradlew bundleRelease

Local testing via bundletool

Google provides the bundletool utility for generating APKs from AAB on a local machine. The command `bundletool build-apks --bundle=app.aab --output=app.apks` creates a set of APKs for testing on different device configurations.

bundletool can also unpack AAB, display its configuration and verify signature integrity before uploading to Google Play Console. For debugging, the command `bundletool dump manifest --bundle=app.aab` is used to show the base module manifest.

Split configuration in AAB

By default, AAB splits resources across three dimensions: language, screen density (density) and CPU architecture (abi). The developer can disable any split in build.gradle — for example, if the application supports only English. Disabling a split means that resources for all variants will be included in the base APK.

Resource optimisation — AAB automatically converts PNG to WebP without quality loss, compresses unused resources and removes duplicate strings. These optimizations are applied on the Google Play side when generating the final APK. As a result, the user receives an APK that is 15–25% smaller than the full archive.

Publishing AAB on Google Play

The process of publishing AAB in Google Play Console differs from APK only in the format of the uploaded file. The console accepts .aab, checks its structure, signature and module configuration, then generates APKs for each device type.

App Signing by Google Play

When uploading AAB, Google Play takes over signing key management. The developer uploads a package signed with an upload key, and Google re-signs the generated APKs with its own key. This simplifies key rotation and access recovery if the keystore is lost.

Pre-release testing

Google Play Console provides built-in AAB testing: you can download the generated APK for a specific device or run internal testing through Internal Testing, Closed Alpha and Open Beta tracks.

Common AAB issues and solutions

Migrating to AAB can cause issues, especially in projects with many dynamic modules or complex resource configuration.

Module configuration errors

If a dynamic module references base module resources with an incorrect name, Google Play rejects the AAB during verification. Solution — use lint checking before building and test all modules via bundletool locally.

Language splits and performance impact

Splitting by language can slow down application startup if resources for the current locale are loaded dynamically. Google's recommendation is not to split languages if there are fewer than 10, or use install-time for the most popular ones.

Compatibility with third-party SDKs

Some SDKs (analytics, advertising, maps) require access to the full manifest and resources. Checking AAB compatibility is a mandatory step before migration. Most major SDKs (Firebase, Google Ads, Crashlytics) fully support AAB since 2022. For compatibility verification, bundletool with the --validate flag is used, which emulates server-side APK generation.

AAB versioning

AAB uses the versionCode from the base module manifest. Unlike APK, AAB also supports versionCode for each module separately — this allows updating individual parts of the application without a full reinstall. Dynamic Delivery tracks installed modules and delivers only changed components during updates via Google Play.

AAB monitoring and analytics

Google Play Console provides detailed analytics for each AAB: how many APKs were generated, which splits were in demand, what the average download size is per device. Android Vitals shows performance metrics for the generated APKs. This data helps optimize split configuration and reduce download size for different device categories.