Android 16KB Page Sizes: Unsere Migrations-Achterbahnfahrt

Wir dachten, es dauert einen Vormittag. Es wurden drei Wochen.

Dann kam Googles Ankündigung: „Hallo zusammen, ab dem 1. November 2025 müssen Ihre Apps 16KB Page Sizes unterstützen. Sollte einfach sein!“

Wir waren gerade dabei, die Mobile-App von Arheev, unserer intelligenten HR-Plattform, zu migrieren. Wir haben die Doku gelesen. Klang unkompliziert. Ein paar Build-Tools aktualisieren, ein paar Config-Flags setzen, vielleicht einen Kaffee holen, während es baut. Bis zum Mittagessen fertig, oder?

Erzählerstimme: Es war nicht bis zum Mittagessen fertig.

Was Google wollte (und warum)

Die Grundidee ergibt Sinn. Android arbeitet seit jeher mit 4KB großen Speicherseiten, aber moderne Geräte mit jeder Menge RAM laufen mit 16KB-Seiten besser. Googles eigene Zahlen zeigen ein paar schöne Verbesserungen:

• Apps starten 3 % schneller, wenn der Speicher des Telefons voll ist
• 4,5 % weniger Akkuverbrauch beim Start
• Kamera-Apps laufen 5–7 % schneller
• Das Telefon bootet 8 % schneller

Klingt gut. Wo ist der Haken?

Das eigentliche Problem, vor dem uns niemand gewarnt hat

Jetzt wird es heikel. Jede native Bibliothek (.so-Datei) in Ihrer App muss an 16KB-Grenzen „ausgerichtet“ sein, also aligned. Stellen Sie sich das wie Parken vor: Ihre Bibliothek muss sauber in Parkplätze von 16KB Größe passen.

Wenn Sie eine reine Java/Kotlin-App schreiben, haben Sie Glück. Kein nativer Code, kein Problem.

Aber die Arheev-Mobile-App ist mit React Native gebaut. Und React-Native-Apps sind im Grunde native Bibliotheken, verpackt in JavaScript, verpackt in weitere native Bibliotheken, verpackt in existenzielle Fragen, warum wir nicht einfach separate native Apps gebaut haben.

Wenn Bibliotheken nicht richtig ausgerichtet sind, bekommen Sie:

• Apps, die sich nicht installieren lassen
• Kryptische Fehlermeldungen, die Ihnen nichts sagen
• Abstürze, die nur auf bestimmten Geräten auftreten (meist auf denen, mit denen Ihr Chef testet)

Ein Riesenspaß!

Was tatsächlich passiert ist: eine Chronik

Tag 1: „Das wird einfach“

Wir haben auf Android Gradle Plugin 8.5.1 und NDK r28 aktualisiert. Laut Doku kümmern sich diese Versionen automatisch um das 16KB-Alignment. Wir haben ein paar Flags in die AndroidManifest.xml eingetragen:

<application
  android:enableOnBackInvokedCallback="true"
  android:extractNativeLibs="true">

  <property
    android:name="android.app.16kb_page_size"
    android:value="true" />
</application>

Build lief durch. Tests grün. High Fives in alle Richtungen. Zeit, unsere Migration in unter einer Stunde zu feiern!

Tag 3: „Warum funktioniert das nicht?“

Wir haben einen Android-15-Emulator mit aktivierter 16KB-Unterstützung hochgefahren. App installiert. Sofort abgestürzt.

Wie sich herausstellte, waren mehrere Bibliotheken, die sich in unserem Dependency-Tree versteckten, nicht 16KB-aligned:

• Unsere Audioverarbeitungs-Bibliothek (libandroidlame.so)
• Irgendein Bildkomprimierungs-Dings
• Ein Drittanbieter-SDK, an dessen Einbau wir uns kaum noch erinnerten

Die Fehlermeldung lautete: „Native module initialization failed.“ Danke, Android. Super hilfreich.

Wir haben zwei Tage damit verbracht, mehr über ELF-Alignment zu lernen, als wir je wissen wollten.

Tag 5: „Na gut, dann bauen wir drumherum“

Nach viel Googeln (und ein paar langen Abenden auf Stack Overflow mit sehr viel Kaffee) fanden wir das magische Flag: android:extractNativeLibs="true".

Es weist Android an, Bibliotheken bei der Installation der App zu extrahieren, statt sie direkt aus dem APK zu laden. Damit wird die Alignment-Anforderung im Grunde komplett umgangen.

Ist das perfekt? Nein. Funktioniert es? Ja. Liefern wir es aus? Auf jeden Fall.

Das Gute:

• Hat unsere Abstürze sofort behoben
• Funktioniert mit jeder Bibliothek, aligned oder nicht
• Kein Warten darauf, dass Drittanbieter ihr Zeug aktualisieren

Das weniger Gute:

• Die Installation der App dauert etwas länger
• Belegt mehr Speicherplatz auf dem Gerät
• Google könnte das irgendwann abschaffen (aber das ist das Problem unseres zukünftigen Ichs)

Wir behandeln das als vorübergehende Lösung, während wir mit den Maintainern der Bibliotheken an sauber 16KB-ausgerichteten Versionen arbeiten.

Tag 7: „Automatisieren wir das, bevor wir es vergessen“

Das Letzte, was wir wollten, war, dass jemand expo prebuild ausführt und versehentlich all unsere hart erarbeiteten Konfigurationen wegputzt.

Also haben wir ein Expo-Config-Plugin gebaut, das alles automatisch erledigt:

Änderungen an AndroidManifest.xml:

• Fügt die 16KB-Page-Size-Property hinzu
• Aktiviert den Back-Gesture-Callback
• Setzt das extractNativeLibs-Flag

Updates in build.gradle:

• Konfiguriert die NDK-ABI-Filter
• Aktiviert Multidex-Unterstützung
• Richtet das Release-Signing ein

Anpassungen in gradle.properties:

• Build-Tool-Einstellungen
• Flags für die neue React-Native-Architektur
• Ressourcenoptimierung

Wenn jetzt jemand im Team prebuild ausführt, dann… funktionieren diese Einstellungen einfach. Keine „Moment, wo ist diese Config hin?“-Momente mehr.

Was wir gern von Tag eins an gewusst hätten

1. Erst alles aktualisieren

Denken Sie nicht einmal daran, diese Migration ohne Android Gradle Plugin 8.5.1+ und NDK r28+ anzufangen. Ältere Versionen bekommen das 16KB-Alignment schlicht nicht richtig hin.

Aktualisieren Sie Ihre android/build.gradle:

dependencies {
  classpath('com.android.tools.build:gradle:8.5.1')
}

Ja, Build-Tools zu aktualisieren nervt. Machen Sie es trotzdem.

2. Finden Sie heraus, ob Sie überhaupt nativen Code haben

Bevor Sie in Panik geraten: Prüfen Sie, ob Ihre App tatsächlich native Bibliotheken verwendet. Am einfachsten geht das mit dem APK Analyzer in Android Studio:

1. Öffnen Sie Android Studio (jedes Projekt funktioniert)
2. Klicken Sie auf Build > Analyze APK…
3. Wählen Sie Ihre APK-Datei aus
4. Suchen Sie nach einem lib-Ordner

Wenn Sie einen lib-Ordner mit .so-Dateien darin sehen: Glückwunsch, Sie haben nativen Code, um den Sie sich kümmern müssen. Prüfen Sie die Spalte „Alignment“ auf Warnmeldungen.

Kein lib-Ordner? Sie nutzen reines Java/Kotlin und können sich den Großteil dieser Kopfschmerzen vermutlich sparen. Glück gehabt.

3. Testen Sie tatsächlich auf einem 16KB-Emulator

Erstellen Sie im AVD Manager einen Android-15-Emulator und aktivieren Sie in den erweiterten Einstellungen „16KB page size“. Ihr normales Gerät wird diese Probleme nicht aufdecken, weil es noch mit 4KB-Seiten arbeitet.

Glauben Sie uns: Alignment-Probleme wollen Sie nicht erst nach dem Release im Produktivbetrieb entdecken.

4. Spüren Sie Ihre nativen Bibliotheken auf

Finden Sie all die .so-Dateien, die in Ihrer App lauern:

# List all native libraries in your APK
unzip -l app-release.apk | grep '\.so$'

Oder nutzen Sie einfach wieder den APK Analyzer; das ist viel einfacher und hat eine schöne Oberfläche.

Machen Sie eine Liste. Prüfen Sie, ob welche Probleme machen. Fluchen Sie über die, die es tun.

5. Behalten Sie Ihre Abhängigkeiten im Blick

Nicht jeder Bibliotheks-Maintainer ist schon auf den 16KB-Zug aufgesprungen. Manche haben noch nie davon gehört. Für React Native:

• Prüfen Sie, ob Ihre Expo-SDK-Version die Fixes enthält
• Durchsuchen Sie die GitHub-Issues Ihrer nativen Module
• Erwägen Sie einen Bibliothekswechsel, wenn der Maintainer spurlos verschwunden ist

6. Der extractNativeLibs-Trick ist nur vorübergehend

Ja, android:extractNativeLibs="true" behebt gerade alles. Aber behandeln Sie es wie Panzertape: Es funktioniert, aber irgendwann wollen Sie eine richtige Lösung. Behalten Sie im Blick, welche Bibliotheken es brauchen, und achten Sie auf Updates.

Ihre Migrations-Checkliste (damit Sie nichts vergessen)

Das müssen Sie tatsächlich tun:

• AGP auf 8.5.1+ und NDK auf r28+ aktualisieren
• Gradle auf 8.14+ aktualisieren (wenn Sie schon dabei sind)
• Mit dem APK Analyzer prüfen, ob Sie native Bibliotheken haben
• Die 16KB-Page-Size-Flags in die AndroidManifest.xml eintragen
• NDK-ABI-Filter in build.gradle einrichten
• extractNativeLibs hinzufügen, wenn es zu Abstürzen kommt
• Einen Android-15-Emulator mit aktiviertem 16KB-Modus erstellen
• Wirklich alles testen (nicht einfach annehmen, dass es funktioniert)
• Eine Liste problematischer Bibliotheken anlegen
• Die Config automatisieren (Ihr zukünftiges Ich wird es Ihnen danken)

Die Realität der Cross-Platform-Entwicklung

Plattformanforderungen wie diese betreffen eben nicht bloß Ihren eigenen Code, sondern jede einzelne Bibliothek in Ihrem Dependency-Tree.

Wenn Google sagt „unterstützt 16KB“, muss jeder Entwickler nativer Module, jeder SDK-Anbieter, jedes Community-Paket nachziehen. Und Ihre Migration ist erst dann abgeschlossen, wenn die langsamste Bibliothek endlich aufgeholt hat.

Mit React Native wird es noch unterhaltsamer: Sie warten auf mehrere Ökosysteme gleichzeitig, bis sich iOS-, Android- und JavaScript-Entwickler untereinander abgestimmt haben. Es ist wie Katzen hüten, nur dass die Katzen nebenbei auch noch jonglieren.

Hat es sich gelohnt?

Haben wir nach all der Arbeit tatsächlich Verbesserungen gesehen?

Ja, haben wir:

• Weniger Speicherfragmentierung auf neueren Geräten
• Etwas schnellere App-Starts (schwer exakt zu messen, aber es ist da)
• Keine „Ihre App funktioniert auf meinem Handy nicht“-Bug-Reports mehr von Android-15-Nutzern

Der extractNativeLibs-Workaround macht die Installation etwas langsamer, aber sobald die App läuft, fühlt sich alles gut an.

Was noch nicht perfekt ist

Wir verwenden immer noch extractNativeLibs="true" statt sauber ausgerichteter Bibliotheken. Das funktioniert, ist aber technisch gesehen ein Workaround, keine Lösung.

Ein paar Abhängigkeiten haben noch keine 16KB-ausgerichteten Versionen veröffentlicht. Wir beobachten ihre GitHub-Issues, aber einige wurden seit Monaten nicht aktualisiert. Möglicherweise müssen wir sie irgendwann forken oder Alternativen finden.

Und wir sind nicht 100 % sicher, wie sich das auf echten 16KB-Geräten verhält, sobald diese verbreitet sind. Emulatoren sind das eine, echte Hardware das andere. Wir werden es herausfinden.

Wie geht es weiter?

Vermutlich mehr vom Gleichen. Je leistungsfähiger Android-Telefone werden, desto mehr Plattformanforderungen werden sich durch die Dependency-Trees ziehen. Die Automatisierung, die wir für diese Migration gebaut haben, kommt bei der nächsten wieder zum Einsatz.

Unterm Strich

Die Migration auf 16KB Page Sizes ist nicht optional, wenn Sie über Google Play ausliefern wollen. Und sie ist definitiv aufwendiger, als die Dokumentation es klingen lässt.

Aber wenn Sie einmal durch sind, sind Sie durch. Die Config läuft weitgehend von selbst, Ihre App läuft auf neueren Geräten schneller, und Sie haben eine Deadline weniger, über die Sie sich Sorgen machen müssen.

Wenn Sie gerade mitten in dieser Migration stecken und auf seltsame Probleme stoßen: Sie sind nicht allein, uns ging es genauso. Melden Sie sich gern, wenn Sie über Bibliotheks-Alignment jammern oder Anekdoten über kryptische Android-Fehlermeldungen austauschen möchten.

Nützliche Links, wenn Sie einsteigen

• Android-Dokumentation zu 16KB Page Sizes: Die offizielle Dokumentation (die es deutlich einfacher klingen lässt, als es ist)
• Release Notes des Android Gradle Plugin: Um zu prüfen, welche Version Sie brauchen
• Leitfaden zu Expo Config Plugins: Falls Sie Expo nutzen und dieses Chaos automatisieren wollen

Anders als die meisten Migrationen hat diese tatsächlich eine Deadline. Aber zumindest müssen Sie sie nicht allein durchstehen; jeder React-Native-Entwickler kämpft gerade mit denselben Alignment-Albträumen.