AAB — was es ist, Unterschied zu APK und Funktionsprinzip

Was ist AAB

AAB (Android App Bundle) ist ein von Google entwickeltes Veröffentlichungsformat als Ersatz für APK zur Verteilung über Google Play. Im Inneren von AAB befindet sich ein ZIP-Archiv mit der Erweiterung .aab, das kompilierten Code, Ressourcen und Metadaten enthält. Der Hauptunterschied: AAB wird nicht direkt auf einem Gerät installiert.

Funktionsweise

Der Entwickler lädt AAB in die Google Play Console hoch. Wenn ein Benutzer versucht, die Anwendung zu installieren, analysiert Google Play die Gerätekonfiguration: Bildschirmdichte (DPI), CPU-Architektur, Sprache und Android-Version. Basierend auf dieser Analyse wird eine minimale APK generiert, die nur die erforderlichen Komponenten enthält.

Einführungsgeschichte

Google stellte AAB 2018 auf der I/O-Konferenz vor. Seit August 2021 ist das Format für alle neuen Anwendungen bei Google Play verpflichtend. Bestehende Anwendungen können weiterhin APK verwenden, neue müssen jedoch ausschließlich im AAB-Format veröffentlicht werden.

Wie unterscheidet sich AAB von APK

Der Unterschied zwischen AAB und APK ist grundlegend: APK ist eine vollständige Installationsdatei, die zur Installation bereit ist. AAB ist ein Container mit Quellkomponenten, der eine Verarbeitung erfordert.

APK eignet sich für die Verteilung außerhalb von Google Play — über Websites, E-Mail oder unternehmenseigene MDM-Systeme. AAB ist an die Google Play-Infrastruktur gebunden und kann nicht direkt installiert werden. Zum Testen von AAB wird das Tool bundletool verwendet, das die APK-Generierung auf einem lokalen Rechner emuliert.

AAB-Dateistruktur

Die interne Struktur von AAB ähnelt APK, enthält jedoch zusätzliche Verzeichnisse und Dateien zur Beschreibung der Module und ihrer Abhängigkeiten.

Basismodul (base)

Das base-Modul ist ein obligatorischer Bestandteil von AAB. Es enthält den Hauptcode, die Ressourcen und das Anwendungsmanifest. Ohne das Basismodul kann die Anwendung nicht erstellt werden. Alle anderen Module sind optional und werden über Dynamic Delivery angebunden.

Protobuf-Format

Die AAB-Konfiguration verwendet Protocol Buffers (protobuf) anstelle von XML. .pb-Dateien sind kompakter und werden von der Google-Serverinfrastruktur schneller analysiert. Das Tool bundletool konvertiert Protobuf für Debugging-Zwecke in ein lesbares Format.

Dynamic Delivery und Anwendungsmodule

Dynamic Delivery ist die Schlüsseltechnologie, auf der AAB aufbaut. Sie ermöglicht es, dem Benutzer nur die Teile der Anwendung zu liefern, die seinem Gerät und seiner Sprache entsprechen, sowie zusätzliche Module bei Bedarf zu laden.

Modultypen

Install-time-Module werden zusammen mit der Basis-APK während der Installation geladen. Conditional-Module werden nur geliefert, wenn Bedingungen erfüllt sind — zum Beispiel ein Modul mit Materialien für 4K-Bildschirme. On-demand-Module werden auf Benutzeranfrage innerhalb der Anwendung geladen.

Play Asset Delivery (PAD)

Für große Ressourcen (bis zu 2 GB) wird Play Asset Delivery anstelle von OBB-Dateien verwendet. PAD unterstützt dieselben drei Liefermodi: Install-time, Fast-follow (sofort nach der Installation) und On-demand.

// Laden eines On-Demand-Moduls über SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

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

Modulkonfiguration in Gradle

Jedes dynamische Modul wird in einer separaten build.gradle-Datei mit Angabe des Liefertyps beschrieben. Ein Modul kann eigene Ressourcen, Code und ein Manifest enthalten, die unabhängig von der Basisanwendung sind.

AAB-Erstellung über Gradle

Die Erstellung von AAB erfolgt über das Android Gradle Plugin mit der Aufgabe bundleRelease (oder bundleDebug). Das Ergebnis ist eine .aab-Datei im Verzeichnis build/outputs/bundle/.

Build-Konfiguration

Für die AAB-Erstellung ist keine spezielle Konfiguration erforderlich — das Android Gradle Plugin unterstützt Bundles standardmäßig. Geben Sie einfach die Aufgabe bundle anstelle von assemble an.

// build.gradle.kts — AAB-Build mit Signatur
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Aufgabe: ./gradlew bundleRelease

Lokale Tests mit bundletool

Google stellt das Tool bundletool zur Verfügung, um APKs aus AAB auf einem lokalen Rechner zu generieren. Der Befehl `bundletool build-apks --bundle=app.aab --output=app.apks` erstellt einen Satz von APKs zum Testen auf verschiedenen Gerätekonfigurationen.

bundletool kann AAB auch entpacken, seine Konfiguration anzeigen und die Signaturintegrität vor dem Hochladen in die Google Play Console überprüfen. Zum Debuggen wird der Befehl `bundletool dump manifest --bundle=app.aab` verwendet, der das Manifest des Basismoduls anzeigt.

Split-Konfiguration in AAB

Standardmäßig teilt AAB Ressourcen in drei Dimensionen auf: Sprache, Bildschirmdichte (density) und CPU-Architektur (abi). Der Entwickler kann jede Aufteilung in build.gradle deaktivieren — zum Beispiel, wenn die Anwendung nur Englisch unterstützt. Das Deaktivieren einer Aufteilung bedeutet, dass Ressourcen für alle Varianten in die Basis-APK aufgenommen werden.

Ressourcen-Optimierung — AAB konvertiert automatisch PNG ohne Qualitätsverlust in WebP, komprimiert ungenutzte Ressourcen und entfernt doppelte Zeichenfolgen. Diese Optimierungen werden beim Generieren der endgültigen APK auf Google Play-Seite angewendet. Dadurch erhält der Benutzer eine APK, die 15–25% kleiner ist als das vollständige Archiv.

AAB-Veröffentlichung bei Google Play

Der Prozess der Veröffentlichung von AAB in der Google Play Console unterscheidet sich von APK nur im Format der hochgeladenen Datei. Die Konsole akzeptiert .aab, überprüft dessen Struktur, Signatur und Modulkonfiguration und generiert dann APKs für jeden Gerätetyp.

App Signing by Google Play

Beim Hochladen von AAB übernimmt Google Play die Verwaltung der Signaturschlüssel. Der Entwickler lädt ein mit einem Upload-Schlüssel signiertes Paket hoch, und Google signiert die generierten APKs mit seinem eigenen Schlüssel neu. Dies vereinfacht die Schlüsselrotation und die Wiederherstellung des Zugriffs bei Verlust des Keystores.

Tests vor der Veröffentlichung

Die Google Play Console bietet einen integrierten AAB-Test: Sie können die generierte APK für ein bestimmtes Gerät herunterladen oder interne Tests über die Tracks Internal Testing, Closed Alpha und Open Beta durchführen.

Häufige AAB-Probleme und Lösungen

Die Migration auf AAB kann Probleme verursachen, insbesondere bei Projekten mit vielen dynamischen Modulen oder komplexer Ressourcenkonfiguration.

Modulkonfigurationsfehler

Wenn ein dynamisches Modul mit einem falschen Namen auf Ressourcen des Basismoduls verweist, lehnt Google Play das AAB während der Überprüfung ab. Lösung — verwenden Sie vor dem Build eine Lint-Überprüfung und testen Sie alle Module lokal über bundletool.

Sprachaufteilungen und Leistungseinbußen

Die Aufteilung nach Sprachen kann den Anwendungsstart verlangsamen, wenn Ressourcen für das aktuelle Gebietsschema dynamisch geladen werden. Googles Empfehlung ist, Sprachen nicht aufzuteilen, wenn es weniger als 10 sind, oder für die beliebtesten Install-time zu verwenden.

Kompatibilität mit Drittanbieter-SDKs

Einige SDKs (Analytics, Werbung, Karten) benötigen Zugriff auf das vollständige Manifest und die Ressourcen. Die Überprüfung der AAB-Kompatibilität ist ein obligatorischer Schritt vor der Migration. Die meisten großen SDKs (Firebase, Google Ads, Crashlytics) unterstützen AAB seit 2022 vollständig. Zur Kompatibilitätsprüfung wird bundletool mit dem Flag --validate verwendet, das die serverseitige APK-Generierung emuliert.

AAB-Versionierung

AAB verwendet den versionCode aus dem Manifest des Basismoduls. Im Gegensatz zu APK unterstützt AAB auch einen separaten versionCode für jedes Modul — dies ermöglicht das Aktualisieren einzelner Teile der Anwendung ohne vollständige Neuinstallation. Dynamic Delivery verfolgt installierte Module und liefert bei Updates über Google Play nur geänderte Komponenten aus.

AAB-Überwachung und Analysen

Die Google Play Console bietet detaillierte Analysen für jedes AAB: wie viele APKs generiert wurden, welche Splits nachgefragt wurden, wie hoch die durchschnittliche Downloadgröße pro Gerät ist. Android Vitals zeigt Leistungsmetriken der generierten APKs an. Diese Daten helfen, die Split-Konfiguration zu optimieren und die Downloadgröße für verschiedene Gerätekategorien zu reduzieren.