APK vs. AAB: Das neue Android-Distributionsformat erklärt
Was eine APK eigentlich ist (und warum sie 15 Jahre lang Android beherrschte)
15 Jahre lang war das Android Package Kit – APK – die einzige Option. Es war der Standard für Android-Apps seit dem Start der Plattform im Jahr 2008. Eine APK ist im Grunde nur ein ZIP-Archiv mit einer sehr spezifischen internen Struktur: Es enthält die kompilierte AndroidManifest.xml, den DEX-Bytecode (classes.dex), eine resources.arsc-Tabelle und Ordner für Assets, native Bibliotheken und andere Roh-Ressourcen. Wenn du dir eine App von einer Website holst oder sie per Bluetooth an einen Freund schickst, versendest du eine einzige .apk-Datei, die alles enthält, was zum Ausführen auf jedem Android-Gerät erforderlich ist. Dieser Einheitsgrößen-Ansatz ist sowohl die größte Stärke der APK als auch ihr fataler Fehler. Eine einzige APK aus dem Google Play Store muss alles unterstützen, von einem Samsung Galaxy S25 Ultra mit einem 64-Bit-ARM-Chip bis zu einem günstigen Tecno-Handy mit einem 32-Bit-ARM-Chip, plus Chromebooks mit x86-Prozessoren und jeder erdenklichen Bildschirmdichte. Um das zu erreichen, mussten Entwickler jede Version jeder nativen Bibliothek, jeden übersetzten String und jedes Bild für jede Bildschirmdichte in ein einziges riesiges Paket packen. Das Ergebnis? Apps wie Google Maps wurden als 100-MB-APKs ausgeliefert, obwohl dein Gerät nur etwa 40 MB davon wirklich brauchte. Der Rest war nur Ballast – heruntergeladen und gespeichert, aber nie verwendet.
Android App Bundle: Was sich 2018 änderte und warum Google es zur Pflicht machte
Google ging das Problem der aufgeblähten APKs schließlich auf der Google I/O 2018 mit dem Android App Bundle (AAB) an und machte es im August 2021 für neue Apps im Play Store zur Pflicht. Obwohl es die Dateiendung .aab hat und ebenfalls ein ZIP-Archiv ist, handelt es sich nicht um eine installierbare App. Stell es dir eher wie ein Rezept mit einer Kiste voller Zutaten vor, nicht wie den fertigen Kuchen. Ein AAB enthält den kompilierten Code und die Ressourcen in Modulen, aber die Server von Google Play übernehmen die endgültige Zusammenstellung. Dieser Prozess wird Dynamic Delivery genannt. Wenn ein Nutzer im Play Store auf „Installieren“ tippt, analysieren die Server von Google sein spezifisches Gerät – seine CPU-Architektur (ABI), Bildschirmdichte und Spracheinstellungen. Anschließend erstellen und liefern sie einen maßgeschneiderten Satz von Split-APKs, die nur das enthalten, was genau dieses Gerät benötigt. Ein Pixel 9 mit Android 15 auf Englisch erhält vielleicht einen 38-MB-Download, während die alte monolithische APK satte 95 MB groß gewesen wäre. Die Größenreduzierung ist nicht nur theoretisch; sie ist signifikant und messbar. Googles eigene Daten aus dem Jahr 2021 zeigten eine durchschnittliche Größenreduzierung von 15 % für Apps, die auf AAB umgestiegen sind, wobei einige ihre Größe um über 50 % reduzierten. Bei einem Spiel mit riesigen Textur-Atlanten, die für verschiedene GPU-Komprimierungsformate (wie ETC2, ASTC und S3TC) ausgelegt sind, können die Einsparungen astronomisch sein und leicht Hunderte von Megabytes von der endgültigen Installation auf dem Handy des Nutzers einsparen.
Die interne Struktur einer AAB-Datei
Wenn du eine AAB-Datei mit einem ZIP-Programm öffnest, siehst du sofort, dass es keine APK ist. Auf der obersten Ebene gibt es eine BundleConfig.pb-Datei, die die Konfiguration des Bundles definiert, ein BUNDLE-METADATA-Verzeichnis und mindestens ein Modulverzeichnis. Das Hauptmodul heißt immer `base/` und sieht im Inneren ein wenig wie eine APK aus, mit `dex/`, `manifest/`, `res/`, `root/` und `lib/`-Ordnern. Aber es gibt einen entscheidenden Unterschied: Die Ressourcen werden in einem `resources.pb`-Proto-Format gespeichert, nicht als flache binäre `resources.arsc`-Datei wie bei einer APK. Das ist ein Hauptgrund, warum eine AAB nicht direkt installiert werden kann. Andere Feature-Module erscheinen neben dem `base/`-Modul, mit Namen wie `onboarding/` oder `ar_features/`. Jedes hat sein eigenes Manifest und eigene Ressourcen und kann so konfiguriert werden, dass es zur Installationszeit, direkt nach der Installation (Fast-Follow) oder nur bei Bedarf heruntergeladen wird. Dieses On-Demand-Modell ermöglicht es einer App wie Google Earth, zu vermeiden, jeden Nutzer mit 3D-Städtedaten zu belasten, und diese stattdessen nur dann über die Play Core-Bibliothek abzurufen, wenn jemand tatsächlich versucht, eine Stadt mit dieser Abdeckung anzusehen. Im `lib/`-Verzeichnis jedes Moduls geschieht die eigentliche Magie bei der Größeneinsparung. Ein plattformübergreifendes Spiel könnte Unterverzeichnisse wie `arm64-v8a`, `armeabi-v7a` und `x86_64` haben, die jeweils mit kompilierten .so-Bibliotheken gefüllt sind. Eine monolithische APK würde sie alle bündeln. Mit einem AAB stellt Dynamic Delivery sicher, dass nur das eine, passende ABI-Verzeichnis gesendet wird. Bei einem Spiel mit 80 MB an nativem Code pro ABI bedeutet das eine sofortige Einsparung von 160 MB auf einem modernen 64-Bit-Handy, das keine Verwendung für 32-Bit- oder x86-Bibliotheken hat.
APK vs. AAB: Ein direkter Vergleich dessen, was für Entwickler zählt
Was bedeuten diese Unterschiede also in der Praxis für Entwickler, die Qualitätssicherung und die Nutzer? Lass uns den Vergleich anhand dessen aufschlüsseln, was in deiner täglichen Arbeit wirklich zählt. **Unterstützung durch Vertriebskanäle:** Google Play verlangt AABs für neue Apps. So einfach ist das. Allerdings sind AABs eine reine Google-Technologie. Alternative Android-App-Stores wie der Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery und F-Droid benötigen alle die guten alten APKs. Wenn du deine App außerhalb von Google Play vertreibst, bist du immer noch im APK-Geschäft. Das ist kein unwichtiges Detail, besonders in Märkten, in denen Google Play nicht verfügbar ist und die reine APK-Verteilung der Standard ist. **Direkte Installation:** Du kannst eine AAB nicht per Sideloading installieren. Der Versuch, eine mit `adb install app.aab` zu installieren, führt nur zu einer Fehlermeldung. Um eine AAB lokal zu testen, musst du Googles `bundletool` verwenden, um einen lokalen APK-Satz zu generieren, oder das `--local-testing`-Flag in deinem Build nutzen. Jeder, der schon einmal versucht hat, einen nicht-technischen Stakeholder dazu zu bringen, einen Build zu testen, weiß, dass zusätzliche Schritte ein Rezept für Frustration sind. Das erschwert die QA-Workflows definitiv. **Build-Tools:** In Android Studio erstellst du eine AAB mit Build > Generate Signed Bundle/APK > Android App Bundle oder mit dem Task `./gradlew bundleRelease`. Eine APK erstellst du mit `./gradlew assembleRelease`. Die meisten Teams verwenden beides: Sie erstellen APKs für interne Tests und AABs für den finalen Upload in den Play Store. **Dateigröße auf der Festplatte:** Hier gibt es eine häufige Verwirrung: Deine AAB-Datei wird fast immer größer sein als deine APK. Eine 60-MB-APK könnte eine 80-MB-AAB erzeugen, da die AAB die Ressourcen für *alle* Gerätekonfigurationen enthält. Die Größeneinsparungen zeigen sich erst auf dem Gerät des Nutzers, nachdem Google Play seine Magie hat wirken lassen. **Sicherheitsmodell:** Beide Formate werden signiert, aber der Prozess unterscheidet sich. Bei AABs musst du Play App Signing verwenden. Das bedeutet, du lädst dein Bundle hoch und Google signiert die finalen Split-APKs, die es generiert, mit einem von Google verwalteten Schlüssel neu. Obwohl du diesen Schlüssel registrierst, behält ihn letztendlich Google – eine Tatsache, die einige sicherheitsbewusste Teams nervös macht. Bei APKs kannst du den gesamten Signaturprozess mit deinen eigenen Schlüsseln steuern, ohne dass Google involviert ist.
Konvertierung zwischen APK und AAB: Was möglich ist und was nicht
Hier sind ehrliche Antworten wichtiger als Marketingversprechen. Seien wir ehrlich: Eine bestehende APK zurück in eine AAB zu konvertieren, ist keine reale Möglichkeit, und du solltest jedem Tool, das behauptet, dies automatisch zu können, zutiefst misstrauen. Das Problem ist fundamental. Eine AAB benötigt die ursprünglichen Quellinformationen – die Ressourcendateien, sauber nach Bildschirmdichte und Sprache geordnet, die Ressourcentabelle im Proto-Format, die Modulstruktur. All diese Daten werden beim Erstellen einer APK kompiliert, zusammengefasst und wegoptimiert. Die `resources.arsc`-Datei in einer APK ist ein binärer Blob; die ursprüngliche Ordnerstruktur `res/drawable-hdpi/` ist verschwunden. Der Versuch, das aus einer kompilierten APK wiederherzustellen, ist keine Konvertierung; es ist ein mühsamer Prozess des Reverse Engineerings, und die Ergebnisse sind fast immer unvollständig. CocoConvert ist für APK-zu-APK-Operationen konzipiert. Du kannst es verwenden, um APK-Dateien neu zu verpacken, umzubenennen und – was am nützlichsten ist – deren Inhalte zur Überprüfung zu extrahieren. Lade eine APK hoch, und du kannst ihr Manifest extrahieren, ihre Ressourcentabelle einsehen oder bestimmte Assets herausholen. Was CocoConvert jedoch nicht kann, ist eine gültige, für den Play Store bereite AAB aus einer APK zu generieren. Ehrlich gesagt kann das kein Tool zuverlässig, wenn du nicht das ursprüngliche Quellcodeprojekt hast. Wenn du deinen Quellcode verloren hast und nur noch eine APK besitzt, ist ein Tool wie `apktool` deine beste Wahl. Es kann das Paket in Smali-Bytecode dekompilieren und dir eine Annäherung an die Ressourcen liefern, aber das wieder in ein richtiges Projekt umzuwandeln, das zu einer AAB gebaut werden kann, erfordert einen enormen manuellen Aufwand. Wofür CocoConvert *wirklich* nützlich ist, sind Aufgaben, die in der mobilen Qualitätssicherung und Sicherheitsforschung ständig anfallen. Du kannst APKs in ZIP-Dateien umwandeln, um ihre Inhalte zu durchsuchen, bestimmte Bilder oder Audiodateien zu extrahieren und sogar einen ganzen Ordner von APKs per Stapelverarbeitung prüfen.
Das Sideloading-Problem und warum die APK nicht verschwinden wird
Trotz Googles großem Vorstoß für AABs wird die bescheidene APK nicht verschwinden. Ihre Langlebigkeit rührt von all den Anwendungsfällen her, die vollständig außerhalb von Googles Kontrolle existieren. Sideloading – die Installation einer APK von außerhalb des Play Stores – ist eine Kernfunktion von Android, die durch einen kurzen Abstecher in die Einstellungen deines Handys aktiviert wird (normalerweise unter Einstellungen > Apps > Spezieller App-Zugriff > Unbekannte Apps installieren, obwohl der Pfad variiert). Und das Sideloading-Ökosystem ist riesig. APKMirror hostet verifizierte APKs von Play-Store-Apps, sodass Nutzer Updates erhalten können, bevor ein gestaffelter Rollout sie erreicht, oder ältere Versionen installieren können. Enterprise Mobile Device Management (MDM)-Tools von VMware und Microsoft verteilen APKs auf Tausende von Firmengeräten, ohne jemals den Play Store zu berühren. Game-Modding-Communities leben und atmen modifizierte APKs. Für Entwickler in Regionen mit eingeschränktem Zugang zum Play Store ist das Teilen von APKs die primäre Vertriebsmethode. Für all diese Nutzer ist AAB schlicht irrelevant. Es ist ein Format, das innerhalb von Googles abgeschottetem Ökosystem lebt und stirbt. Sobald eine App außerhalb dieses Ökosystems geteilt, bereitgestellt oder installiert werden muss, muss es eine APK sein. Dies wird mit neuen Vorschriften noch relevanter. Der Digital Markets Act der EU zwingt sowohl Apple als auch Google, sich für alternative App-Stores zu öffnen. Wenn Drittanbieter-Marktplätze für Android in Europa an Bedeutung gewinnen, werden sie ein universelles Format für Einreichungen benötigen. Da sie nicht auf Googles proprietäre Dynamic-Delivery-Infrastruktur zugreifen können, wird dieses Format die APK sein. Dies könnte ironischerweise zu einer Wiederbelebung der Bedeutung der APK in einigen der größten Märkte der Welt führen, selbst während Google für seinen eigenen Store voll auf AAB setzt.
Praktische Empfehlungen je nach deiner Situation
Also, kommen wir zur Sache. Das richtige Format hängt vollständig davon ab, was du tun möchtest. Hier ist eine schnörkellose Anleitung, basierend auf deiner Rolle. **Wenn du eine neue App bei Google Play veröffentlichst:** Du hast keine Wahl. Du musst seit August 2021 für jede neue App eine AAB einreichen. Konfiguriere Play App Signing in der Play Console (Einrichtung > App-Integrität), richte deine Gradle-Signaturkonfiguration ein und führe `./gradlew bundleRelease` aus. Stell sicher, dass du es lokal mit `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` gefolgt von `bundletool install-apks --apks=app.apks` testest. **Wenn du Apps über MDM an Unternehmensgeräte verteilst:** Bleib bei APKs. Erstelle eine mit `./gradlew assembleRelease`. Deine MDM-Lösung verteilt die APK direkt auf die Geräte. Die Verwendung einer AAB hat hier keinerlei Mehrwert und verursacht nur Kopfschmerzen. **Wenn du Apps in alternativen App-Stores vertreibst:** Erstelle APKs. Der Amazon Appstore hat zum Beispiel sein eigenes Entwicklerportal für APK-Uploads und seine eigene Logik für das Device-Targeting. Sie verwenden nicht das System von Google. **Wenn du als QA-Ingenieur einen Build testest:** Verwende APKs für deine täglichen Smoke-Tests und Regressionstests; sie sind schnell und lassen sich direkt mit `adb install` installieren. Für die endgültige Validierung vor dem Release solltest du eine AAB erstellen und `bundletool` verwenden, um sicherzustellen, dass du das testest, was die Nutzer tatsächlich aus dem Play Store erhalten werden. **Wenn du eine erhaltene APK überprüfen musst:** Du kannst sie bei CocoConvert hochladen, um schnell ihre Inhalte zu extrahieren, oder den APK Analyzer von Android Studio verwenden (Build > Analyze APK). Der Analyzer bietet eine großartige visuelle Aufschlüsselung der Dateigrößen und ist perfekt, um zwei verschiedene Builds zu vergleichen und zu sehen, was sich geändert hat. Letztendlich geht es bei der Debatte APK vs. AAB nicht darum, welches Format im luftleeren Raum technisch überlegen ist. Es geht um Logistik. Die richtige Wahl wird durch deinen Vertriebskanal und deine Tools bestimmt. Beide Formate werden uns erhalten bleiben und bedienen unterschiedliche Wege im weitläufigen Android-Ökosystem.