Converting Modified APKs Back to Android App Bundle (AAB): Smali, Proto, and Bundletool Guide

With Google Play enforcing the Android App Bundle (AAB) format for all app distributions, security researchers, penetration testers, and QA engineers frequently hit a major architectural wall: decompilation and bytecode instrumentation tools (such as Apktool) naturally disassemble and reassemble apps into standard standalone APK files, not AAB archives. If your testing pipeline requires delivering an audited, patched, or rebranded binary back into an internal Play Store release track or enterprise bundle distribution, you need a deterministic path to convert an edited APK back into a spec-compliant .aab package.

In this technical masterclass, we will walk through the internal architecture of Android App Bundles, why a simple repackaging fails, and how to execute the reverse conversion from modified APK artifacts to proto-format AABs using AAPT2 and Bundletool, as well as zero-install workflows using APKTool Studio.

The Core Architectural Difference: APK vs. AAB

An APK is an installable archive containing pre-compiled binary resources (UTF-16/binary XML formatted) and Dalvik Executable (.dex) files. Conversely, an Android App Bundle is an uninstalled publishing format designed strictly for Google Play's Dynamic Delivery system.

• Resource Compilation: Standard APKs use binary XML format. AAB packages require resources compiled with AAPT2 using the --proto-format flag (Protocol Buffers).
• Directory Layout: AABs require a distinct directory hierarchy split into modules (such as base/, feature_name/) containing dedicated manifest/, dex/, res/, and root/ subdirectories.
• Target Artifact: Mobile devices cannot parse or run an AAB directly; it must be transformed into split APK sets or universal APKs via Bundletool before adb install can consume it.

If you have modified Smali bytecode, updated API endpoints in strings.xml, or patched anti-tamper logic using APKTool Studio, your immediate result is an APK. Converting that modified APK back into an AAB requires deconstructing the APK, converting resources back to proto-resources, and packaging module directories.

Step 1: Extract and Convert Binary Resources to Proto Format

Because Android App Bundles mandate Protocol Buffer resources, you cannot simply drop compiled binary XML files from a standard APK into an AAB container. You must extract and recompile the resource table using the Android Asset Packaging Tool (AAPT2).

1. Extract Assets and DEX Files

First, unpack your patched APK archive using standard extraction utilities to separate the raw components:

# Create working directory and extract APK
mkdir -p extracted_apk && cd extracted_apk
unzip ../modified-app.apk -d .

# Separate classes.dex, assets, and native libraries
mkdir -p ../aab_base/dex
mkdir -p ../aab_base/root/lib
mkdir -p ../aab_base/assets

cp classes*.dex ../aab_base/dex/
[ -d assets ] && cp -r assets/* ../aab_base/assets/
[ -d lib ] && cp -r lib/* ../aab_base/root/lib/
cd ..

2. Recompile Resources Using AAPT2 Proto Mode

To produce proto-compliant resources, recompile your unpacked resource tree (obtained via decompilation) using AAPT2's link command with the --proto-format flag:

aapt2 link \n  --proto-format \n  -o compiled_base.apk \n  -I $ANDROID_HOME/platforms/android-34/android.jar \n  --manifest decompiled/AndroidManifest.xml \n  -R compiled_resources.flat \n  --auto-add-overlay

The output compiled_base.apk now contains AndroidManifest.xml and the resources.pb table formatted in proto binary.

Step 2: Construct the AAB Base Module Hierarchy

An Android App Bundle relies on an exact directory layout. The primary app functionality resides inside the base/ directory. Let us extract the compiled proto files and build the structure:

mkdir -p aab_base/manifest
mkdir -p aab_base/res

# Extract proto-formatted manifest and resources from compiled_base.apk
unzip -q compiled_base.apk -d temp_proto/
mv temp_proto/AndroidManifest.xml aab_base/manifest/
mv temp_proto/resources.pb aab_base/
cp -r temp_proto/res/* aab_base/res/ 2>/dev/null || true
rm -rf temp_proto

Verify your directory tree matches the required specification before running Bundletool:

• base/manifest/AndroidManifest.xml (Proto format)
• base/resources.pb (Proto resource table)
• base/res/ (Drawables, layouts, and resource values)
• base/dex/ (All classes.dex, classes2.dex, etc.)
• base/assets/ (Raw application runtime assets)
• base/root/lib/ (Native .so shared objects sorted by ABI)

Step 3: Create the Unsigned Base Module ZIP

Compress the base directory into an uncompressed or standard zip archive representing the base module zip container:

cd aab_base
zip -r ../base.zip *
cd ..

Step 4: Build the Final AAB with Bundletool

With the base.zip module assembled, invoke Google's official bundletool utility to package the module archive into an Android App Bundle (.aab):

bundletool build-bundle \n  --modules=base.zip \n  --output=app-release-rebuilt.aab

Bundletool validates resource references, cross-module constraints, and manifest specifications. If the output succeeds, your new AAB is structurally identical to one generated natively by Android Studio or Gradle.

Step 5: Sign the Reconstructed AAB with Modern Keystores

Just like standard APKs, an AAB must be cryptographically signed before it can be processed by deployment pipelines or uploaded to internal testing platforms. Use jarsigner to apply the digital signature:

jarsigner -verbose \n  -sigalg SHA256withRSA \n  -digestalg SHA-256 \n  -keystore release.keystore \n  app-release-rebuilt.aab alias_name

Streamlining Analysis with APKTool Studio

Re-engineering an APK back into proto-format AAB manually requires matching exact Android SDK build tools, AAPT2 versions, and Java classpaths. For quick security triage, payload verification, and testing, managing local SDK dependencies can be time-consuming.

With APKTool Studio, you can inspect APK architectures, decompile Smali bytecode, inspect internal manifests, and generate signed binaries directly inside your browser without installing the full Android build chain. When performing dynamic binary updates, having an automated cloud suite ensures your resources and manifests remain strictly valid before repackaging.

Validating the Generated AAB Binary

Before deploying your newly synthesized AAB, confirm that it can successfully produce functional universal APKs that run seamlessly on real devices:

# Generate APK Set archive from the reconstructed AAB
bundletool build-apks \n  --bundle=app-release-rebuilt.aab \n  --output=app-verification.apks \n  --mode=universal \n  --ks=release.keystore \n  --ks-pass=pass:password123 \n  --ks-key-alias=alias_name

# Extract the universal APK and test ADB deployment
unzip -p app-verification.apks universal.apk > universal_debug.apk
adb install -r universal_debug.apk

If the universal APK installs and launches with your patched Smali logic intact, your APK-to-AAB conversion pipeline is complete and production-ready.