Optimizing Android App Bundle (AAB) for Smaller APK Size
Since Google Play made AAB the mandatory format for new apps, simply converting an APK to AAB doesn't automatically shrink the size — we see this on almost every second project. Without proper configuration of splits, texture compression, and R8, you'll get only marginal savings. Our team, with 5+ years in Android development and 20+ release projects, helps configure AAB so that the downloadable APK size shrinks by 15–35%. Below are the concrete steps that deliver measurable results.
How Does Android App Bundle Reduce APK Size?
An APK is a monolithic archive for all devices. An AAB is a container with modules from which Google Play generates a personalized APK for each device. For example, a Samsung Galaxy S23 will receive only arm64-v8a libraries and xxhdpi resources, without x86, armeabi-v7a, or xhdpi/hdpi variants. The result: the downloadable APK shrinks by an average of 15–35% — this is official data from Google, confirmed on real apps. Android Developers documentation confirms: "On average, the size of Android App Bundles is about 15% smaller than APKs." We guarantee the same effect on your project.
What to Configure in build.gradle for Optimal AAB?
Configuring splits is the foundation of AAB. Here is the minimal setup:
android { bundle { language { enableSplit = true } density { enableSplit = true } abi { enableSplit = true } texture { enableSplit = true defaultFormat = "ETC2" } } } texture splits are critical for games and apps with 3D graphics. Without them, all texture formats are packed together, potentially adding 50–100 MB. ETC2 is a universal format (GLES 3.0+), ASTC offers best compression on modern devices (Adreno 530+, Mali-G51+). The choice depends on your minimum API level.
Additional settings for texture compression
If your app uses ASTC, set defaultFormat = "ASTC" in the texture block. For older devices that don't support ASTC, Google Play will automatically pick the ETC2 variant — but only if enableSplit is enabled. Check compatibility using baseConfig.fgl.
APK vs AAB: Which Is More Effective?
| Parameter | APK | AAB |
|---|---|---|
| Download size | Single for all devices | Optimized per device |
| Texture splits | Not supported | Supported (ETC2, ASTC, DXT) |
| Dynamic modules | Require separate setup | Built-in (Play Feature Delivery) |
| Versioning | Simple | Requires bundletool for analysis |
AAB is unequivocally more efficient: it reduces size by 15–35% — better than any APK splitter.
Table: Texture Formats for AAB
| Format | Requirements | Compression |
|---|---|---|
| ETC2 | OpenGL ES 3.0+ | 4:1 |
| ASTC | Adreno 530+, Mali-G51+ | 10:1 |
| DXT | Nvidia Tegra, old GPUs | 6:1 |
How to Verify AAB Size Before Upload?
Use bundletool. Build the APK set with:
bundletool build-apks --bundle=app.aab --output=app.apks \ --ks=keystore.jks --ks-pass=pass:password \ --ks-key-alias=key --key-pass=pass:password bundletool get-size total --apks=app.apks --device-spec=pixel7_spec.json device-spec.json is obtained via bundletool get-device-spec --adb=<path>. This gives the exact download size for a target device before uploading to Play Store.
Why R8 and ProGuard Are Mandatory for AAB?
buildTypes { release { minifyEnabled = true shrinkResources = true proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro") } } shrinkResources = true works only when minifyEnabled = true. It removes unused resources — strings, images, layouts — based on static code analysis. On real projects we see 5–20 MB of additional reduction. R8 in full mode more aggressively removes code and inlines methods, reducing size by another 5–15% compared to the old ProGuard.
Analyze Size via Android Studio
Go to Build → Analyze APK (works with AAB after unpacking). It shows a pie chart: classes.dex, res/, lib/, assets/. You immediately see what takes up the most space. Typical findings:
-
assets/with uncompressed JSON data files — compress or switch to binary format (Protobuf / FlatBuffers) -
lib/with native libraries for all ABIs includingx86andx86_64— keep onlyarm64-v8aandarmeabi-v7afor production builds -
res/drawable-*with PNG where VectorDrawable would suffice
What Our Work Includes
Setting up AAB is not a single flag; it's a set of actions. Here are the steps we follow:
- Audit current configuration: check splits, texture compression, R8/ProGuard, bundletool.
- Configure build.gradle: proper slots and texture formats.
- Optimize resources: compress assets, remove unused resources, convert PNG to VectorDrawable.
- Verify size: calculate via bundletool for 3–5 target devices.
- Documentation: report on changes and recommendations for future releases.
- Team training: how to maintain AAB optimization in subsequent releases.
Reducing app size by 15–35% directly lowers traffic costs for users and increases installation conversion rates. We guarantee a reduction in downloadable APK size of 15–35%. Get a consultation on AAB configuration for your project — we'll assess your current build and pinpoint exactly how much you can save.
Timeline
AAB configuration with bundletool verification takes 1–2 days. If full size optimization is needed, including R8 tuning and texture splits, it's 3–5 days. Contact us to discuss your specific case.