Deine Web-App ist nicht das Problem
HTML, CSS und JavaScript laufen in Android System WebView, die Google ausliefert und aktualisiert. Nichts in deinem Lovable-, Bolt- oder Replit-Code ist eine native Bibliothek.
Was die Anforderung sagt und wann sie gilt
Android hat traditionell 4-KB-Speicherseiten genutzt. Ab Android 15 können Geräte stattdessen 16-KB-Seiten verwenden, was laut Google die Leistung verbessert. Native Bibliotheken, die für 4-KB-Seiten gelinkt wurden, können auf einem solchen Gerät nicht laden oder abstürzen. Deshalb verlangt Google Play, dass Apps, die auf Android 15 (API-Level 35) oder höher abzielen, auf 64-Bit-Geräten 16-KB-Seitengrößen unterstützen.
Der Zeitplan hat sich mehrmals verschoben, deshalb widersprechen sich Forenbeiträge:
- 1. November 2025: Die Anforderung trat für neue Apps und Updates in Kraft, die auf Android 15 oder höher abzielen.
- Bis 31. Mai 2026: Entwickler, die mehr Zeit brauchten, konnten in der Play Console eine Verlängerung beantragen.
- 31. August 2026: Neue Apps und Updates müssen auf Android 16 (API-Level 36) abzielen, also fällt jeder neue Upload unter die Regel.
- 1. Februar 2027: Laut Googles Android-Entwicklerleitfaden (aktualisiert im Oktober 2026) können ab diesem Datum Updates, die keine 16-KB-Seiten unterstützen, nicht mehr veröffentlicht werden.
Entscheidend sind das Datum und der Wortlaut, die die Play Console für deine eigene App anzeigt. Prüf sie, bevor du ein Release planst.
Wie die Play Console es dir mitteilt
Die Warnung erscheint auf den Release-Seiten und im App Bundle Explorer, wo Google zeigt, ob ein Bundle 16-KB-Seitengrößen unterstützt. Entwickler berichten von Formulierungen wie „Your app does not support 16 KB memory page sizes“, manchmal gefolgt vom Pfad der betroffenen Bibliothek, etwa base/lib/arm64-v8a/libexample.so. Eine bestehende App kann außerdem eine Nachricht im Posteingang der Play Console oder eine E-Mail mit der für sie geltenden Frist bekommen.
Bevor die Durchsetzung für deine App gilt, ist es eine Warnung mit Datum. Sobald sie gilt, lässt sich ein nicht konformes Release nicht ausrollen, und der einzige Weg nach vorn ist ein neues Bundle mit ausgerichteten Bibliotheken.
Warum eine Web-Wrapper-App überhaupt betroffen ist
Der WebViewGold-Code ist Java
Code in Java oder Kotlin hängt nicht von der Seitengröße ab. Google sagt, dass Apps ohne nativen Code 16-KB-Geräte bereits unterstützen.
SDKs können .so-Dateien mitbringen
Scan-, Werbe-, Analytics-, Crash-Reporting-, Zahlungs- oder Medien-SDKs liefern manchmal native Bibliotheken mit. Ist eines davon eine alte Version, fällt das ganze Bundle durch die Prüfung.
Alte Templates und Toolchains
Ein vor langer Zeit heruntergeladenes Template, in einen jniLibs-Ordner kopierte Bibliotheken oder ein Android Gradle Plugin älter als 8.5.1, das unkomprimierte Bibliotheken nicht an 16-KB-Grenzen ausrichtet.
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
Wo das aktuelle WebViewGold-Template steht
WebViewGold führt volle Unterstützung für 16-KB-Speicherseiten unter seinen Android-Funktionen, und das Android-Changelog nennt verbesserte 16-KB-Unterstützung in Version 16.8 (Mai 2026). Aus dem aktuellen Template mit den mitgelieferten SDK-Versionen zu bauen, ist der vorgesehene Weg zu einem konformen Bundle. Zwei Situationen verdienen trotzdem eine Prüfung: ein Projekt, das du mit einer älteren Version konfiguriert hast, und jede Bibliothek, die du selbst hinzugefügt hast.
Der Cloud Builder baut immer mit dem aktuellen Template, eine ältere App dort ohne geänderte Einstellungen neu zu bauen, ist also die schnellste Lösung. In Android Studio folgst du den Schritten zum Template-Update im Guide zum Target API Level, die hier unverändert gelten. Weil ein Rebuild für das aktuelle Target Level auch das Edge-to-Edge-Verhalten von Android 15 einschaltet, prüf im selben Durchgang den Edge-to-Edge-Guide.
Prüf dein Bundle in etwa fünfzehn Minuten
Du brauchst den signierten Build, den du veröffentlichen willst, und Android Studio.
Schau in den App Bundle Explorer
Öffne in der Play Console den App Bundle Explorer, wähle die Version und lies die Informationen zur 16-KB-Kompatibilität. Meldet er das Bundle als konform, bist du mit diesem Thema fertig.
Finde heraus, ob du nativen Code auslieferst
Baue in Android Studio ein signiertes Release-APK (Menü Build, Generate Signed App Bundle or APK) und öffne es mit Build, Analyze APK. Gibt es keinen lib-Ordner oder keine .so-Dateien darin, hat die App keinen nativen Code und unterstützt 16-KB-Seiten bereits.
Prüf die Ausrichtung jeder Bibliothek
Im APK Analyzer hat der lib-Ordner eine Spalte Alignment, die vor Dateien warnt, die nicht auf 16 KB ausgerichtet sind. Die Dateinamen deuten meist auf das SDK hin, das sie mitliefert.
Mit zipalign bestätigen
Führ die zipalign-Prüfung aus den Build-Tools des Android SDK auf dem APK aus, wie unten gezeigt. Die letzte Zeile der Ausgabe sollte „Verification successful“ lauten.
Auf einem 16-KB-Emulator testen
Leg ein virtuelles Gerät mit einem System-Image ab Android 15 an, das als 16 KB Page Size gekennzeichnet ist, bestätige die Seitengröße mit adb, installiere die App und öffne die Funktionen, die auf SDKs angewiesen sind, etwa Scanner, Werbung oder Zahlungen.
Beheben, neu bauen, hochladen
Aktualisiere das Template oder das SDK, das die nicht ausgerichtete Bibliothek mitliefert, baue mit höherem Version Code neu und lade hoch. Der App Bundle Explorer zeigt das Ergebnis für die neue Version.
Befehle für die Prüfung
Die Dateinamen sind Beispiele. zipalign liegt im Ordner build-tools deines Android SDK, adb in platform-tools.
bash
# 1. Sind alle nativen Bibliotheken auf 16 KB ausgerichtet? (nach "Verification successful" suchen)
zipalign -v -c -P 16 4 app-release.apk
# 2. Die nativen Bibliotheken im APK auflisten
unzip -l app-release.apk | grep "\.so$"
# 3. Welche Abhängigkeit bringt sie mit? (im Projektordner ausführen)
./gradlew app:dependencies --configuration releaseRuntimeClasspath
# 4. Auf dem 16-KB-Emulator: sollte 16384 ausgeben
adb shell getconf PAGE_SIZELösung nach Ursache
| Ursache | Lösung |
|---|---|
| Projekt mit einer älteren WebViewGold-Version gebaut | Lade das aktuelle Template herunter (Updates sind kostenlos), übertrage Config.java, Icons und deine Manifest-Änderungen und baue neu. Oder baue im Cloud Builder neu. |
| Ein SDK, das du hinzugefügt hast, liefert eine alte .so-Datei mit | Aktualisiere das SDK auf die Version, die sein Anbieter als 16-KB-kompatibel kennzeichnet, oder entferne es, wenn du es nicht brauchst. |
| Dein eigener C- oder C++-Code | Baue mit NDK r28 oder neuer, das standardmäßig auf 16 KB ausrichtet. Ergänze bei älteren NDKs die Linker-Flags -Wl,-z,max-page-size=16384 und -Wl,-z,common-page-size=16384. |
| Android Gradle Plugin älter als 8.5.1 | Aktualisiere das Plugin mit dem Upgrade-Assistenten von Android Studio. Bibliotheken komprimiert zu packen (useLegacyPackaging), ist nur ein letzter Ausweg, weil es die Installationsgröße erhöht. |
| Eine vorkompilierte .so ohne verfügbares Update | Ersetze die Bibliothek oder die Funktion, die von ihr abhängt. Keine Build-Einstellung macht aus einer für 4-KB-Seiten gelinkten Bibliothek eine konforme. |
16-KB-Checkliste
- Der App Bundle Explorer meldet das Bundle als 16-KB-kompatibel.
- Keine Alignment-Warnungen für .so-Dateien im APK Analyzer, und die zipalign-Prüfung besteht.
- Aus dem aktuellen WebViewGold-Template oder im Cloud Builder gebaut.
- Jedes SDK, das du selbst hinzugefügt hast, ist auf einer 16-KB-kompatiblen Version.
- Auf einem 16-KB-Emulator getestet, inklusive der Funktionen, die native SDKs nutzen.
- Version Code vor dem Upload erhöht.
Häufig gestellte Fragen
Meine App zeigt nur meine Website an. Muss ich wegen 16-KB-Seiten etwas tun?
Prüf es einmal. Enthält das Bundle keine nativen Bibliotheken, unterstützt es 16-KB-Seiten bereits. Enthält es .so-Dateien aus SDKs, müssen diese ausgerichtet sein; das aktuelle WebViewGold-Template ist mit den mitgelieferten SDKs darauf ausgelegt.
Muss ich meine Web-App für die 16-KB-Anforderung ändern?
Nein. Die Anforderung betrifft native Bibliotheken im Android-Bundle. HTML, CSS und JavaScript sind nicht betroffen.
Was passiert mit der Version, die schon live ist?
Bestehende Installationen funktionieren weiter. Die Anforderung regelt, welche neuen Releases du veröffentlichen kannst. Auf einem Gerät mit 16-KB-Seiten kann Android manche nicht ausgerichteten Apps in einem Kompatibilitätsmodus mit Warnung ausführen, worauf du dich aber nicht verlassen solltest.
Spielt die 16-KB-Regel für 32-Bit-Bibliotheken eine Rolle?
Die Play-Anforderung bezieht sich auf 64-Bit-Geräte, also müssen die 64-Bit-Bibliotheken in deinem Bundle (die Ordner arm64-v8a und x86_64) ausgerichtet sein. Halte den Rest trotzdem aktuell.
Wie finde ich heraus, welches SDK die nicht ausgerichtete Bibliothek mitliefert?
Der Dateiname im lib-Ordner verrät es meist, und der Gradle-Abhängigkeitsbaum zeigt, welche Bibliothek sie einbindet. Wenn du es nicht erkennst, schick die Dateiliste zusammen mit deiner WebViewGold-Version an den Support-Chat.
Drei Wege, deine App in die Stores zu bringen
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
Selbst machen
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehenCloud Builder
$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobierenFull Service
$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.