APK und AAB: Build-Artefakte für Installation und Play-Auslieferung

Wenn du deine Android-App zum ersten Mal teilen oder veröffentlichen willst, stößt du sofort auf zwei Abkürzungen: APK und AAB. Beide klingen ähnlich, lösen aber unterschiedliche Probleme im Build- und Distributions-Prozess. In diesem Artikel klären wir, was die Formate sind, wie sie zusammenhängen, wann du welches brauchst und welche Stolperfallen Junior-Devs typischerweise erleben. Das Ziel: Du verstehst, was Android Studio dir am Ende eines Builds in die Hand drückt und warum Google Play heute fast ausschließlich auf das App Bundle setzt.

Was ist das?

Eine APK (Android Package Kit) ist das eigentliche Installationspaket, das auf einem Android-Gerät landet. Technisch ist sie ein ZIP-Archiv mit deinem kompilierten Code (classes.dex), den Ressourcen, dem AndroidManifest.xml, nativen Libraries pro Architektur und einem Signaturblock. Sobald ein Nutzer eine App installiert, entpackt das System diese APK und legt sie im App-Verzeichnis ab. APKs sind also das Format, das ein Gerät tatsächlich versteht und ausführt.

Ein AAB (Android App Bundle, Endung .aab) ist dagegen kein Installationsformat, sondern ein Publishing-Format. Du lädst dein Bundle in die Google Play Console hoch, und Play generiert daraus für jedes Zielgerät eine maßgeschneiderte APK – nur mit den Sprachen, Bildschirm-Dichten und CPU-Architekturen, die das jeweilige Gerät wirklich braucht. Diese Aufteilung heißt Dynamic Delivery. Das Bundle enthält alle Bausteine, die Play für diese Splits braucht: Base-Modul, optionale Feature-Module, Konfigurations-APKs und Asset-Pakete.

Der entscheidende Unterschied: Die APK ist das, was installiert wird; das AAB ist das, was du veröffentlichst. Seit August 2021 verlangt Google Play für neue Apps zwingend das AAB-Format, seit August 2022 auch für Updates bestehender Apps. Klassische APKs bleiben aber relevant für Sideload, Tests, alternative Stores wie F-Droid oder Amazon Appstore und für Geräte ohne Play Services. Beide Formate gehören also weiter zu deinem Werkzeugkasten – nur mit klarer Rollenverteilung.

Wie funktioniert es?

Der Build-Prozess läuft konzeptionell gleich, egal ob am Ende eine APK oder ein AAB steht. Das Android Gradle Plugin kompiliert deinen Kotlin-Code zu JVM-Bytecode, übersetzt diesen mit dem D8-Compiler in DEX, packt Ressourcen mit AAPT2 und sammelt native Libraries ein. Erst beim letzten Schritt entscheidet sich das Format: assembleRelease erzeugt eine APK, bundleRelease erzeugt ein AAB.

Die Magie des AAB liegt in der Aufteilung beim Auslieferungszeitpunkt. Play bekommt dein Bundle und schneidet daraus drei Arten von APK-Splits zu:

• Base-APK mit Code und Standard-Ressourcen, die jedes Gerät braucht.
• Configuration-APKs mit gerätespezifischen Ressourcen: eine pro Sprache (de, en), eine pro Bildschirm-Dichte (hdpi, xxhdpi) und eine pro ABI (arm64-v8a, x86_64).
• Feature-APKs für optional nachladbare Module über Play Feature Delivery.

Das Gerät installiert nur die Splits, die es tatsächlich braucht. Eine deutschsprachige App auf einem arm64-Gerät bekommt also keine englischen Strings und keine x86-Libs. In der Praxis bedeutet das spürbar kleinere Downloads – laut Google im Schnitt 15–20 Prozent weniger als bei einer universellen APK, bei großen Apps oft mehr.

Beim Signieren kommt ein wichtiges Detail dazu: Beim AAB lädst du dein Bundle mit deinem Upload-Key hoch, und Google Play signiert die generierten APKs mit dem App-Signing-Key. Diesen Key verwaltet Google im Rahmen von Play App Signing. Das hat zwei Konsequenzen: Erstens schützt es dich davor, deinen Key zu verlieren – ohne Play App Signing wäre ein verlorener Keystore das Ende deiner App-Updates. Zweitens bedeutet es, dass die APK, die ein Nutzer am Ende installiert, mit einem anderen Key signiert ist als die Datei, die du hochgeladen hast. Lokal getestete Bundles musst du daher mit einem eigenen Tool wie Bundletool oder über Internal App Sharing prüfen, sonst stimmt die Signatur-Prüfung nicht.

Für klassische APKs gibt es zwei Signatur-Schemata, die du kennen solltest: APK Signature Scheme v1 (JAR-basiert, langsam, aber alt-kompatibel), v2 und v3 (signieren das gesamte Archiv, schneller bei der Installation) sowie v4 (für inkrementelle Installationen). Android Studio aktiviert v2 und v3 standardmäßig; v1 brauchst du nur noch, wenn du wirklich Geräte mit Android 6 oder älter unterstützt.

In der Praxis

In einem typischen Workflow generierst du dein AAB direkt aus Android Studio über Build → Generate Signed Bundle / APK oder per Kommandozeile mit Gradle. Eine minimale build.gradle.kts-Konfiguration für ein Release-Bundle sieht so aus:

android {
    namespace = "de.androidcoden.beispiel"
    compileSdk = 35

    defaultConfig {
        applicationId = "de.androidcoden.beispiel"
        minSdk = 24
        targetSdk = 35
        versionCode = 17
        versionName = "1.4.0"
    }

    signingConfigs {
        create("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "release.keystore")
            storePassword = System.getenv("KEYSTORE_PASSWORD")
            keyAlias = System.getenv("KEY_ALIAS")
            keyPassword = System.getenv("KEY_PASSWORD")
        }
    }

    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            signingConfig = signingConfigs.getByName("release")
        }
    }

    bundle {
        language { enableSplit = true }
        density  { enableSplit = true }
        abi      { enableSplit = true }
    }
}

Mit ./gradlew bundleRelease baust du anschließend das AAB unter app/build/outputs/bundle/release/app-release.aab. Möchtest du lokal sehen, was Play später ausliefert, hilft dir Bundletool:

# AAB in einen Satz APKs umwandeln (universelle Variante zum Testen)
java -jar bundletool.jar build-apks \
    --bundle=app-release.aab \
    --output=app-release.apks \
    --mode=universal \
    --ks=release.keystore \
    --ks-key-alias=androidcoden

# Direkt auf einem angeschlossenen Gerät installieren
java -jar bundletool.jar install-apks --apks=app-release.apks

Entscheidungsregel: Wann APK, wann AAB?

• AAB für jede Veröffentlichung über Google Play, also den Hauptverteilungskanal in Deutschland.
• APK für Sideload, manuelle QA-Builds, CI-Artefakte zum schnellen Verteilen, alternative Stores (F-Droid, Amazon Appstore, Huawei AppGallery, Samsung Galaxy Store) und für Enterprise-Distribution per MDM, falls dein System keine Splits unterstützt.
• Internal App Sharing in der Play Console nutzt du, wenn du das tatsächliche Auslieferungsverhalten deines AAB testen willst, ohne ein Release zu erstellen.

Typische Stolperfallen

Die häufigste Falle ist das falsche Mentalmodell: Junior-Devs erwarten, dass ihr AAB direkt installierbar ist. Versuchst du, es per adb install app-release.aab aufs Gerät zu schieben, scheitert das mit einem Parse-Fehler. Du brauchst immer den Zwischenschritt über Bundletool oder den Play Store.

Eine zweite Falle betrifft Ressourcen-Splits: Wenn dein Code zur Laufzeit Sprach-Ressourcen lädt, die das Gerät nicht installiert hat (zum Beispiel weil du dynamisch zwischen Locales wechselst), bekommst du die Fallback-Sprache statt der erwarteten Übersetzung. Lösung: die Play Core Library mit SplitInstallManager nutzen, um fehlende Sprachpakete bei Bedarf nachzuladen, oder Sprach-Splits über bundle { language { enableSplit = false } } deaktivieren.

Drittens: Versionierung. versionCode muss bei jedem Upload streng monoton steigen, sonst lehnt Play das Bundle ab. Ein klassischer Fehler ist, im CI parallel zwei Branches zu bauen und denselben versionCode zu erzeugen. Eine bewährte Strategie ist, den Code aus dem Build-Zeitstempel oder der CI-Build-Nummer abzuleiten.

Viertens: ProGuard/R8. Aktiviertes Shrinking ist für Release-Builds Pflicht, kann aber bei Reflection oder bei Bibliotheken ohne Consumer-Rules zu Crashes führen, die du im Debug-Build nie siehst. Teste deinen Release-Build daher mindestens einmal manuell auf einem echten Gerät, bevor du ihn ausrollst.

Fazit

APK und AAB sind keine Konkurrenten, sondern zwei Schichten desselben Distributions-Modells: Das App Bundle ist das, was du Google Play übergibst, die APK ist das, was am Ende auf dem Gerät landet. Wer als Android-Entwickler ernsthaft veröffentlichen will, kommt am AAB nicht vorbei – und wer Builds verteilt, debuggt oder alternative Stores bedient, braucht weiterhin ein solides APK-Verständnis. Mach jetzt eine kleine Übung: Baue mit ./gradlew bundleRelease ein Bundle deiner aktuellen App, generiere mit Bundletool ein installierbares APK-Set daraus, vergleiche die resultierende Größe mit einer universellen APK aus assembleRelease und prüfe in der Play Console über App-Bundle-Explorer die Splits, die für ein Pixel und ein Samsung-Gerät erzeugt würden. Erst wenn du diese Zahlen einmal selbst gesehen hast, wird der Vorteil des Bundles aus dem theoretischen Konzept zu einer Entscheidung, die du als Entwickler bewusst triffst.