Schnellantwort
Google Play verlangt von Apps mit Ziel Android 15 (API-Level 35) oder höher, dass sie 16-KB-Speicherseiten auf 64-Bit-Geräten unterstützen, und ab dem 1. Februar 2027 können Sie keine Updates mehr veröffentlichen, die das nicht tun. Eine App, die ausschließlich in Java oder Kotlin geschrieben ist, Bibliotheken und SDKs eingeschlossen, ist bereits konform. Eine App, die native .so-Bibliotheken mitliefert, scheitert so lange, bis jede einzelne neu kompiliert oder ersetzt wurde, am besten mit Android Gradle Plugin 8.5.1+ und NDK r28+, und bis der Build zwei getrennte Prüfungen besteht: jedes ELF-LOAD-Segment auf mindestens 2**14 ausgerichtet und das App Bundle meldet PAGE_ALIGNMENT_16K. Ihr Framework zu aktualisieren ist kein Nachweis; das Artefakt ist der Nachweis. Wenn das Beseitigen dieser Warnung einen bereits laufenden geschlossenen Test blockiert, hält PrimeTestLab die Tester-Seite am Laufen, während Sie neu kompilieren.
Die Warnung ist kurz, sie nennt bestenfalls einen Dateinamen, und sie kommt, wenn Sie den Build längst für fertig hielten. Deshalb wiederholen sich dieselben drei Irrwege: man vertraut einer Frist, die verschoben wurde, aktualisiert ein Framework und hält die Sache damit für erledigt, oder prüft ein einziges lokales APK und sieht sich nie das Bundle an, aus dem Google tatsächlich baut. Dieser Artikel ist so aufgebaut, wie sich das Problem wirklich löst, nämlich identifizieren, zuordnen, reparieren, nachweisen, und alles darin ist Stand 5. August 2026, geprüft gegen Googles Leitfaden zu Seitengrößen am Tag seiner letzten Aktualisierung. Wo der Beleg der Issue-Tracker eines Maintainers und keine offizielle Release-Note ist, sagt die Seite das auf der Karte, statt es zur Tatsache aufzurunden.
Das Ausrichtungslabor
Zwölf Instrumente, gebaut für diesen einen Fehler. Nichts davon braucht ein Konto, einen Upload oder eine Netzwerkanfrage: jedes Werkzeug läuft in Ihrem Browser mit den Werten, die Sie eingeben.
Inhaltsverzeichnis
In drei Schritten beheben
Jede echte Behebung dieses Fehlers besteht aus denselben drei Schritten in derselben Reihenfolge: die nicht ausgerichtete native Bibliothek identifizieren, die Abhängigkeit aktualisieren, die sie liefert, und dann das Artefakt prüfen, das Sie hochladen wollen. Direkt bei Schritt zwei einzusteigen ist der Grund, warum so viele Entwickler ein Framework aktualisieren, neu bauen und die Warnung unverändert wiedersehen.
Die Anforderung selbst ist eng gefasst. Googles Leitfaden zu Seitengrößen besagt, dass Apps mit Ziel Android 15 (API-Level 35) oder höher 16-KB-Speicherseiten auf 64-Bit-Geräten unterstützen müssen und dass Sie ab dem 1. Februar 2027 keine Updates mehr veröffentlichen können, die das nicht tun. Es betrifft ausschließlich nativen Code. Wenn Ihre App und jede Bibliothek und jedes SDK darin reines Java oder Kotlin sind, unterstützt Ihre App laut Google bereits 16-KB-Geräte. Das Problem ist, dass die meisten Entwickler, die diese Warnung sehen, sich in dieser Kategorie wähnen und nicht darin sind.
Die fehlerhafte .so identifizieren
Öffnen Sie Ihr Release-APK in Android Studio über Build > Analyze APK..., klappen Sie lib/arm64-v8a und lib/x86_64 auf und lesen Sie die Spalte Alignment. Notieren Sie jeden gemeldeten Dateinamen. Diese Dateinamen sind die einzigen verlässlichen Suchschlüssel, die Sie haben.
Aktualisieren, was sie liefert
Eine Binärdatei, die Sie selbst kompiliert haben, behebt Ihre Toolchain: AGP 8.5.1 oder neuer mit NDK r28 oder neuer. Eine Binärdatei, die in einem Plugin, SDK, einer Engine oder einem AAR ankam, kann nur derjenige beheben, der sie gebaut hat: die Aktion besteht also darin, dieses Paket zu aktualisieren, zu ersetzen oder ein neu kompiliertes Artefakt anzufordern.
Den kürzesten Weg für Ihr Framework findenDas Artefakt prüfen, nicht das Update
Zwei unabhängige Prüfungen müssen beide bestehen. Jedes ELF-LOAD-Segment muss auf 2**14 oder mehr ausgerichtet sein, und bundletool muss für das Release-Bundle PAGE_ALIGNMENT_16K melden. Eine bestandene Prüfung beweist nichts über die andere.
Die ganze Entscheidung auf einem Bildschirm
Bevor Sie eine einzige Abhängigkeitsversion ändern, gehen Sie das hier durch. Es dauert etwa zwei Minuten und ist der Unterschied zwischen dem Beheben der richtigen Sache und dem Aktualisieren von elf Paketen, die nie das Problem waren.
Enthält das Release-APK einen lib-Ordner mit .so-Dateien?
Bereits konform
Kein nativer Code im APK. Google gibt an, dass eine App mit ausschließlich Java oder Kotlin, Bibliotheken und SDKs eingeschlossen, 16-KB-Geräte bereits unterstützt. Ein Testlauf lohnt sich trotzdem, ebenso die Bestätigung, dass Sie denselben Build geprüft haben, den Sie hochgeladen haben.
Nennt APK Analyzer oder check_elf_alignment.sh eine nicht ausgerichtete Bibliothek?
Zuordnen, dann aktualisieren
Finden Sie heraus, welches Framework, Plugin, SDK oder welche Engine genau diesen Dateinamen liefert, und aktualisieren Sie dieses Paket. Ihr eigenes NDK kann eine fremde vorkompilierte Binärdatei nicht umschreiben.
Was meldet bundletool dump config für das Release-Bundle?
PAGE_ALIGNMENT_4K
Die Bibliotheken sind in Ordnung, die Verpackung nicht. Wechseln Sie auf AGP 8.5.1 oder neuer und bauen Sie neu, oder wenden Sie den Legacy-Packaging-Workaround an, wenn Sie nicht aktualisieren können.
PAGE_ALIGNMENT_16K
Die Verpackung stimmt. Testen Sie jetzt die von Play erzeugten APKs in einer echten 16-KB-Umgebung und prüfen Sie jeden Laufzeitcode, der eine feste Seitengröße annimmt.
Die Falle in einem Satz
Ein lokales APK, das jede Ausrichtungsprüfung besteht, beweist nicht, dass das hochgeladene Bundle korrekt ist. Google warnt ausdrücklich, dass Android Gradle Plugin 8.3 bis 8.5 ein Bundle erzeugen kann, dessen von Play gebaute APKs nicht sauber ZIP-ausgerichtet sind, selbst wenn das APK auf Ihrem Rechner perfekt aussieht. Genau diese Abweichung ist der mit Abstand häufigste Grund, warum die Warnung eine "erfolgreiche" Behebung überlebt.
Was die Warnung der Play Console wirklich bedeutet
Googles dokumentierte Folge ist präzise: ab dem 1. Februar 2027 können Sie keine Updates veröffentlichen, die Android 15 (API-Level 35) oder höher als Ziel haben und 16 KB nicht unterstützen. Das ist eine Veröffentlichungssperre für Updates und keine Aussage, dass eine bereits veröffentlichte App an diesem Tag aus dem Store entfernt wird. Bis dahin sehen die meisten Entwickler eine Kompatibilitätswarnung und keine harte Ablehnung beim Upload.
Die Formulierung ist wichtig, weil die Panikversion dieser Geschichte schneller reist als die korrekte. Lesen Sie die Texte, die Google tatsächlich anzeigt, und der Geltungsbereich wird eng und beherrschbar.
App must support 16 KB memory page sizes
Rekonstruiert aus dem Screenshot der Play Console, den Google im Leitfaden zu Seitengrößen zeigt. Die Beschriftungen sind auf Englisch wiedergegeben, so wie sie auf diesem Screenshot erscheinen: Ihre Console kann sie auf Deutsch anzeigen, und Layout wie verfügbare Schaltflächen können je nach Konto abweichen.
Zwei Lesarten dieser Karte sind verbreitet falsch. Erstens ist "Action by Feb 1, 2027" kein Countdown bis zur Löschung: Googles eigener Text auf derselben Seite beschreibt die Folge als die Unmöglichkeit, diese Updates zu veröffentlichen. Zweitens erscheint der Text Extension granted zwar auf Googles Screenshot, das belegt aber nicht, dass Ihnen derzeit ein Antragsweg für eine Verlängerung offensteht. Betrachten Sie eine Verlängerung nur dann als real, wenn Sie die Option in Ihrer eigenen Play Console sehen.
Welche Frist haben Sie tatsächlich gelesen?
Drei Daten kursieren und nur eines gilt. Wählen Sie das, das Sie gesehen haben, und dieses Werkzeug klärt seinen Status gegen Googles aktuelle Seite, die zuletzt am 5. August 2026 aktualisiert wurde.
Instrument 01
Fristen-Auflöser
Google hat diese Frist mehr als einmal verschoben. Bevor Sie einen Release-Plan um den 1. Februar 2027 herum bauen, öffnen Sie den Leitfaden zu Seitengrößen selbst und prüfen Sie den Vermerk "Zuletzt aktualisiert" am Seitenende. Diese eine Gewohnheit ist mehr wert als jedes in einem Artikel gedruckte Datum, dieses eingeschlossen.
Betrifft die 16-KB-Anforderung meine App?
Das entscheidet nicht Ihr Framework, sondern der Inhalt Ihres erzeugten APK. Gibt es .so-Dateien unter lib, sind Sie im Geltungsbereich, auch wenn Sie nie eine C++-Datei geöffnet haben, und gibt es keine, sagt Googles eigener Hinweis, dass Sie 16-KB-Geräte bereits unterstützen.
Reine Java- oder Kotlin-Apps
Google ist hier eindeutig: wenn Ihre App und alle ihre Bibliotheken und SDKs ausschließlich Java oder Kotlin verwenden, unterstützt Ihre App bereits 16-KB-Geräte. Google empfiehlt trotzdem, in einer 16-KB-Umgebung zu testen, um unerwartete Regressionen zu finden, was Sie einen Emulatorlauf kostet.
Der Haken steckt in der Formulierung "und alle ihre Bibliotheken und SDKs". Eine einzige Abhängigkeit für Datenbank, Analytics, Absturzberichte, Medien, Karten, maschinelles Lernen oder Sicherheit kann native Binärdateien in ein Projekt bringen, dessen eigener Quellcode nur aus Kotlin besteht. "Ich habe kein C++ geschrieben" ist kein Beleg. Der lib-Ordner ist einer.
Flutter, React Native, Unity, Kivy und No-Code-Baukästen
Diese Stacks liefern konstruktionsbedingt native Runtimes, Engine-Binärdateien und Plugin-Bibliotheken mit, sind also fast immer im Geltungsbereich. Google nennt ausdrücklich App-Baukästen von Drittanbietern, die native Bibliotheken verwenden, als einen Weg, auf dem eine App betroffen sein kann, obwohl ihr Autor nie C oder C++ geschrieben hat. Was sich unterscheidet, ist nicht, ob Sie nativen Code haben, sondern welches Paket das fehlerhafte Teil geliefert hat: deshalb kommt das Zuordnen des Dateinamens vor jedem Update.
Wie Sie genau prüfen
Öffnen Sie das Release-APK, klappen Sie lib auf und sehen Sie sich die ABI-Ordner darin an, üblicherweise arm64-v8a und x86_64. Jede vorhandene Shared-Object-Datei bedeutet, dass Ihre App nativen Code verwendet. Keine .so-Dateien und kein lib-Ordner bedeutet, dass dieses APK überhaupt keinen nativen Code verwendet. Die Spalte Alignment im Analyzer zeigt Warnungen für Dateien mit Ausrichtungsproblemen an, und das ist der schnellste Weg von "irgendetwas stimmt nicht" zu einem Dateinamen.
Instrument 02
Betroffenheits-Triage
01 Welches Ziel-Level hat Ihre App derzeit?
02 Öffnen Sie das Release-APK im APK Analyzer. Gibt es einen lib-Ordner?
03 Was beschreibt die App am besten?
04 Haben Sie bundletool dump config auf das Release-Bundle angewendet?
Warum eine 4-KB-Binärdatei auf einem 16-KB-Gerät scheitert
Eine Speicherseite ist der kleinste Block, den der Kernel auf einmal abbildet. Android hat historisch 4-KB-Seiten verwendet; mit Android 15 kam die Unterstützung für Geräte hinzu, die mit 16-KB-Seiten konfiguriert sind. Eine native Bibliothek speichert die Ausrichtung, für die ihre Segmente gelinkt wurden, und ist dieser Wert kleiner als die Seitengröße des Geräts, kann der Loader das Segment nicht an einer Seitengrenze platzieren.
Das ist die gesamte Mechanik, und sie erklärt die eine Zahl, die Ihnen immer wieder begegnen wird. Die Ausrichtung wird als Zweierpotenz ausgedrückt: 2**12 sind 4096 Byte, 2**14 sind 16384 Byte. Googles Regel lautet, dass jedes LOAD-Segment einer nativen Bibliothek auf 2**14 oder mehr ausgerichtet sein muss. Eine mit 2**14 gebaute Bibliothek funktioniert auf 4-KB- und auf 16-KB-Geräten, weil 16384 ein glattes Vielfaches von 4096 ist. Eine mit 2**12 gebaute Bibliothek funktioniert nur auf der kleineren Seitengröße. Diese Asymmetrie ist der Grund, warum die Lösung immer "Ausrichtung anheben" heißt und nie "Gerät erkennen".
Instrument 03
Seiten-Visualisierung
Wählen Sie die Ausrichtung, die Ihre Bibliothek meldet, und sehen Sie, wo ihre Segmente auf einem Gerät mit 16-KB-Seiten beginnen können.
Besteht
Es gibt eine zweite, völlig eigenständige Bedingung außerhalb der Bibliothek. Unkomprimiert in einem APK abgelegte native Bibliotheken müssen zusätzlich innerhalb des ZIP-Archivs auf einer 16-KB-Grenze liegen. Das ist eine Eigenschaft der Verpackung, geprüft mit zipalign und konfiguriert durch Ihr Build-Plugin, und sie kann falsch sein, während jede Bibliothek darin perfekt ausgerichtet ist. Diese beiden Ideen auseinanderzuhalten ist das Nützlichste, was Sie aus diesem Abschnitt mitnehmen können.
Die Zahlen lesen
Wenn Sie in der Ausgabe von llvm-objdump ein 2**14 sehen, besteht die Prüfung. 2**13 oder 2**12 scheitert. Es gibt keine Teilpunkte und kein "knapp genug": ein einziges nicht ausgerichtetes LOAD-Segment in einer einzigen Bibliothek in einer einzigen ABI genügt, damit die Warnung auf Ihrem Konto bleibt.
Der kürzeste Fix für jedes Framework
Die Bereitschaft eines Frameworks und die Konformität einer App sind zwei verschiedene Dinge. React Native 0.77 und die unterstützten Unity-Versionen sind echte, dokumentierte Basiswerte. Flutter hat kein überprüfbares universelles Minimum. In jedem Fall behebt das Update die eigenen Binärdateien des Frameworks und lässt jedes Plugin von Drittanbietern genauso wenig konform zurück, wie es vorher war.
Instrument 04
Framework-Finder
Was danach immer noch scheitern kann
Alle Basiswerte in einer Tabelle
| Framework | Dokumentierte Basis | Kürzeste Handlung | Vertrauen |
|---|---|---|---|
| Flutter | Kein überprüftes universelles Minimum; 3.38 ist der dokumentierte Vorbereitungs-Meilenstein (Standard-NDK r28) | Aktuelles stabiles Flutter, native Plugins aktualisieren, aufräumen, neu bauen, jede Bibliothek prüfen | TEILWEISE |
| React Native | 0.77 | Unterstützter Update-Pfad, danach native Module und Anbieter-SDKs aktualisieren | BESTÄTIGT |
| Unity 6.1er-Linie | 6000.1 oder neuer | Editor anheben, Pakete und Plugins aktualisieren, neu bauen | BESTÄTIGT |
| Unity 6 LTS | 6000.0.38f1 oder neuer | Wie oben | BESTÄTIGT |
| Unity 2022 LTS | 2022.3.56f1 oder neuer | Wie oben | BESTÄTIGT |
| Unity 2021 | 2021.3.48f1 oder neuer, Berechtigung für erweitertes LTS nötig | Anheben, wenn berechtigt, sonst auf einen unterstützten Editor migrieren | BESTÄTIGT |
| Unity Burst | 1.8.21 oder neuer | Burst anheben, wenn lib_burst_generated.so genannt wird |
BESTÄTIGT |
| Natives Android | NDK r28+ mit AGP 8.5.1+ | Eigenen Code neu kompilieren, jede vorkompilierte Abhängigkeit aktualisieren | BESTÄTIGT |
| Auf altes NDK festgelegt | r27 oder älter mit beiden Linker-Optionen | max-page-size und common-page-size ergänzen, alle Bibliotheken neu bauen |
FUNKTIONIERT, NICHT BEVORZUGT |
| Kivy oder Python-Baukasten | Keine universelle Version bestätigt | Baukasten und Rezepte aktualisieren, genauen Dateinamen nach oben eskalieren | ANBIETERABHÄNGIG |
| No-Code-Baukasten | Keine universelle Version bestätigt | Auf dem konformen Build-Stack des Anbieters neu generieren, ihm den Dateinamen schicken | ANBIETERABHÄNGIG |
Die Vertrauenslabel haben überall auf dieser Seite dieselbe Bedeutung. BESTÄTIGT heißt, eine aktuelle Primärquelle sagt es direkt. TEILWEISE heißt, eine verlässliche Quelle stützt die Kernaussage, aber nicht jedes Umsetzungsdetail. GEMELDET heißt, der Beleg ist der Issue-Tracker eines Maintainers oder sind Entwicklerberichte und keine offizielle Release-Note.
Die genaue Bibliothek finden, die den Fehler verursacht
Der Dateiname ist die ganze Ermittlung. Sobald Sie wissen, dass libfoo.so die fehlerhafte Binärdatei ist, lautet die Frage nicht mehr "wie behebe ich die 16-KB-Unterstützung", sondern "welches Paket liefert libfoo.so, und gibt es eine neuere Version". Die zweite Frage hat eine Antwort; die erste nicht.
Beginnen Sie im APK Analyzer
Öffnen Sie Build > Analyze APK..., laden Sie das Release-APK und klappen Sie lib auf. Darin sehen Sie einen Ordner je ABI, üblicherweise arm64-v8a und x86_64. Die Spalte Alignment zeigt Warnmeldungen zu Dateien mit Ausrichtungsproblemen. Auch die Warnungen von Android Studio und Lint heben nicht konforme native Bibliotheken hervor, Sie sehen denselben Befund also möglicherweise an mehreren Stellen.
Notieren Sie jeden gemeldeten Dateinamen, bevor Sie eine einzige Versionsnummer anfassen. Prüfen Sie beide ABI-Ordner getrennt: es ist völlig normal, dass arm64-v8a besteht, während x86_64 scheitert, oder umgekehrt, weil es unterschiedliche Binärdateien sind, die potenziell von unterschiedlichen Pipelines gebaut wurden.
Die Kommandozeilenausgabe decodieren
Wenn Sie lieber im Terminal arbeiten: Google liefert check_elf_alignment.sh, das für ein APK ALIGNED oder UNALIGNED meldet, und eine einzelne Bibliothek prüfen Sie direkt mit llvm-objdump. Beides braucht Android SDK Build-Tools 35.0.0 oder neuer. Fügen Sie unten ein, was sie ausgeben, und dieses Werkzeug liest es Ihnen zurück.
Instrument 05
ELF-Decoder
Fügen Sie die Ausgabe von llvm-objdump -p file.so | grep LOAD, check_elf_alignment.sh oder zipalign -c -P 16 ein. Alles wird in Ihrem Browser ausgewertet; nichts wird irgendwohin hochgeladen.
Herausfinden, welche Abhängigkeit sie liefert
Play Console und APK Analyzer geben Ihnen beide einen Dateinamen und keinen Verursacher. Tippen Sie ihn unten ein, und dieses Werkzeug sagt Ihnen, was über diese Binärdatei bekannt ist, mit angehängter Belegqualität, und gibt Ihnen die Suchbefehle mit Ihrem Dateinamen bereits an der richtigen Stelle.
Instrument 06
Bibliotheks-Zuordnung
./gradlew app:dependencies zeigt Ihnen den aufgelösten Abhängigkeitsgraphen, und so finden Sie das transitive Paket, das eine Bibliothek eingezogen hat, die Sie nie selbst hinzugefügt haben. Es sagt Ihnen nicht direkt, welches Artefakt eine bestimmte .so enthält: kombinieren Sie es deshalb mit dem Entpacken des verdächtigen AAR. Das sind praktische Diagnosetechniken und keine von Google vorgeschriebenen Schritte.
Das App Bundle prüfen, nicht nur das lokale APK
Ihr lokales APK und die APKs, die Google Play aus Ihrem Bundle erzeugt, sind unterschiedliche Artefakte. Die ELF-Ausrichtung liegt in jeder Bibliothek; die ZIP-Ausrichtung ist eine Eigenschaft der Archivierung; und das Bundle trägt eine Konfiguration, die Play sagt, welche davon zu verwenden ist. Alle drei können auseinanderlaufen, und nur die letzte entscheidet, was Nutzer installieren.
Das ist die Mechanik hinter der frustrierendsten Variante des Problems: der Entwickler aktualisiert alles, prüft das lokale APK, sieht eine saubere Ausgabe, lädt hoch, und die Warnung ist immer noch da. Nichts, was er geprüft hat, war falsch. Er hat nur nie das geprüft, was Play bewertet.
Was Sie geprüft haben
app-release.apk auf Ihrem RechnerDirekt von Gradle auf Ihrer Hardware gebaut, mit Ihrem Verpackungsverhalten. Ein bestandenes zipalign beweist hier, dass diese Datei korrekt gepackt ist.
Was Play bewertet
Die aus app-release.aab erzeugten APKsVon Google aus Ihrem Bundle gebaut, mit der Ausrichtung, die das Bundle anfordert. Sagt das Bundle 4 KB, sind diese APKs falsch, egal wie sauber Ihr lokales APK war.
Führen Sie das also jedes Mal gegen das Bundle aus, das Sie hochladen wollen:
bundletool dump config --bundle=app-release.aab | grep alignment
PAGE_ALIGNMENT_16K ist das Ergebnis, das Sie wollen. PAGE_ALIGNMENT_4K bedeutet, dass das Bundle bundletool anweist, native Bibliotheken auf 4-KB-Grenzen zu packen: jedes APK, das Play daraus baut, wird also falsch sein. Google warnt ausdrücklich, dass Android Gradle Plugin 8.3 bis 8.5 genau diese Abweichung erzeugen kann: der lokale Build sieht ausgerichtet aus, und die App, die Play aus dem Bundle baut, installiert sich auf einem 16-KB-Gerät nicht korrekt. Die bevorzugte Lösung ist der Wechsel auf Android Gradle Plugin 8.5.1 oder neuer.
Jeder Befehl, mit Ihren eigenen Dateinamen
Tippen Sie Ihre Dateinamen einmal ein. Jeder Befehl unten schreibt sich neu, und jeder Reiter zeigt die genaue Ausgabe, die als bestanden gilt: Sie raten also nie, ob ein Ergebnis gut war.
Instrument 07
Befehlslabor
Hören Sie nicht bei "APK Analyzer sagt ausgerichtet" auf
Eine bestandene APK-Prüfung ist eine von vier Prüfungen und nicht die Ziellinie. Bestätigen Sie die ELF-Ausrichtung der LOAD-Segmente, die ZIP-Ausrichtung des APK, die Bundle-Konfiguration und das Laufzeitverhalten des Artefakts, das Play tatsächlich erzeugt. Scheitert auch nur einer dieser Punkte, bleibt die Warnung nach einem Build, den Sie für behoben hielten, auf Ihrem Konto.
AGP, NDK und die Verpackungsfalle
Zwei Versionen tragen das meiste Gewicht. NDK r28 oder höher kompiliert nativen Code standardmäßig 16-KB-ausgerichtet, und Android Gradle Plugin 8.5.1 oder höher verpackt unkomprimierte native Bibliotheken korrekt auf 16-KB-ZIP-Grenzen. Keines von beiden kann eine vorkompilierte Binärdatei reparieren, die in einer Abhängigkeit angekommen ist.
Das gefährliche Mittelfeld ist Android Gradle Plugin 8.3 bis 8.5. In diesem Bereich kann ein lokaler Build völlig korrekt aussehen, während bundletool die APKs, die es aus Ihrem Bundle für Play erzeugt, nicht ZIP-ausrichtet, und Googles Formulierung ist unmissverständlich: die aus diesem Bundle gebaute App wird sich nicht sauber installieren. Wenn Sie auf 8.5.0 sind und Ihr lokales APK jede denkbare Prüfung besteht, ist das das Erste, was Sie ausschließen sollten.
Instrument 08
Toolchain-Prüfer
Referenz der Build-Einstellungen
| Situation | Einstellung | Hinweise |
|---|---|---|
| Bevorzugtes NDK | r28 oder höher |
Erzeugt standardmäßig 16-KB-ausgerichtete native Ausgaben |
| Bevorzugtes AGP | 8.5.1 oder höher |
Behandelt unkomprimierte native Bibliotheken auf 16-KB-ZIP-Grenzen |
| NDK r27 oder älter | -Wl,-z,max-page-size=16384 |
Pflicht-Linker-Option an jedem nativen Ziel |
| NDK r27 oder älter | -Wl,-z,common-page-size=16384 |
Zusammen mit der Option für die maximale Seitengröße verwenden |
ndk-build |
LOCAL_LDFLAGS += ... |
Beide Optionen an jedem nativen Ziel anwenden |
| CMake | target_link_options(...) |
Beide Optionen an jedem betroffenen Ziel anwenden |
| AGP nicht aktualisierbar | jniLibs.useLegacyPackaging = true |
Komprimiert native Bibliotheken; erhöht den installierten Speicherbedarf |
| AGP 8.0 oder älter | android.bundle.enableUncompressedNativeLibs=false |
Zusätzliche Alt-Eigenschaft neben der Option darüber |
| Laufzeitcode | getpagesize() oder sysconf(_SC_PAGESIZE) |
Ersetzen Sie fest codierte 4096-Werte und feste PAGE_SIZE-Annahmen |
Was die Verpackung nicht beheben kann
Wenn Ihr eigenes C oder C++ eine Seitengröße annimmt, rettet Sie keine Build-Einstellung. Entfernen Sie fest codierte 4096-Werte und jede Abhängigkeit von einer festen PAGE_SIZE-Konstante, fragen Sie den echten Wert zur Laufzeit mit getpagesize() oder sysconf(_SC_PAGESIZE) ab, und prüfen Sie jeden mmap()-Aufruf samt aller Argumente, die Sie von Hand seitenausrichten. Das ist die Fehlerklasse, bei der eine App sich auf einem 16-KB-Gerät sauber installiert, die Bundle-Prüfungen besteht und dann beim ersten Speicher-Mapping abstürzt.
Reihenfolge der Schritte
Beheben Sie die Compilerseite vor der Verpackungsseite. Wenden Sie Sie zuerst den Legacy-Packaging-Behelf an, besteht Ihr APK plötzlich zipalign, während die Bibliotheken darin weiterhin für 4-KB-Seiten gebaut sind, und Sie haben das eigentliche Problem hinter einem grünen Ergebnis versteckt.
In einer echten 16-KB-Umgebung testen
Ein einziger Befehl entscheidet, ob Ihr Test etwas bedeutet: adb shell getconf PAGE_SIZE muss 16384 zurückgeben. Führen Sie ihn vor jeder Sitzung aus. Ein Emulator, der still im 4-KB-Modus gestartet ist, lässt einen kaputten Build alles bestehen, was Sie ihm vorsetzen.
Sie haben drei praktische und zwei spezialisierte Wege. Nehmen Sie den, an den Sie heute tatsächlich herankommen: für das Aufspüren von Seitengrößenfehlern gibt es zwischen ihnen keinen Qualitätsunterschied.
Instrument 09
Testumgebungs-Auswahl
Einschränkung
Danach, ausnahmslos jedes Mal, vor jedem Test
adb shell getconf PAGE_SIZE
Machen Sie nicht weiter, solange die Ausgabe nicht 16384 lautet.
Was Sie tatsächlich durchspielen sollten
Sobald die Umgebung bestätigt ist, lautet der nützliche Testdurchlauf nicht "startet sie". Native Fehler häufen sich in den Funktionen, die nativen Code berühren: spielen Sie diese also gezielt durch, Kaltstart, Navigation durch die App, Kamera, Lese- und Schreibzugriffe auf die Datenbank, Medienwiedergabe und -aufnahme, Anmeldung, Hintergrundarbeit, jede Funktion für maschinelles Lernen oder erweiterte Realität, jede Oberfläche eines nativen Plugins, und alles in Ihrem eigenen Code, das Speicher-Mapping nutzt. Wird eine Funktion von einer der gerade aktualisierten Bibliotheken angetrieben, ist diese Funktion der Test.
Der Kompatibilitätsmodus ist kein Bestehen
Android kann manche 4-KB-ausgerichteten Apps über einen Kompatibilitätspfad auf einem 16-KB-Gerät ausführen, und Sie sehen dabei beim ersten Start womöglich eine Warnung. Google empfiehlt trotzdem eine saubere 16-KB-Ausrichtung für beste Zuverlässigkeit und Stabilität. Eine App, die nur läuft, weil der Kompatibilitätsmodus eingegriffen hat, ist keine behobene App, und auf dieser Grundlage zu veröffentlichen heißt, dass der eigentliche Fehler noch vor Ihnen liegt.
Warum die Warnung ein Update überlebt
Fast jeder Fall von "ich habe das doch längst behoben" ist eine von dreizehn konkreten Situationen, und elf davon lassen sich aus dem Artefakt vor Ihnen belegen. Wählen Sie das passende Symptom, und Sie kennen die Ursache meist, bevor Sie es zu Ende gelesen haben.
Instrument 10
Blockade-Triage
Zwei dieser Fälle verdienen einen Vorbehalt statt einer selbstsicheren Antwort. Keine Primärquelle nennt, wie lange Google Play für die erneute Bewertung eines hochgeladenen Bundles braucht: bleibt Ihre Warnung unmittelbar nach einem Upload bestehen, ist der ehrliche Schritt, zu bestätigen, dass der neue Versionscode bei Ihren letzten Releases und App Bundles erscheint, und später erneut nachzusehen, statt einer irgendwo gelesenen Zahl zu Verarbeitungszeiten zu vertrauen. Und eine App, die nur läuft, weil der Kompatibilitätsmodus eingegriffen hat, wurde nicht behoben, sondern nur untergebracht.
Bibliotheken von Drittanbietern, die immer wieder auftauchen
Das sind gemeldete Beispiele, keine Rangliste ihrer Häufigkeit und kein Versprechen, dass eine bestimmte Version Ihren Build repariert. Ein Paket kann in jedem Release native Artefakte hinzufügen, entfernen oder ersetzen. Die letzte Instanz ist immer die Binärdatei in Ihrem eigenen Release-Bundle.
Nutzen Sie das als Ausgangspunkt, wenn Ihnen ein Dateiname bekannt vorkommt, und prüfen Sie danach die aktuellen Releases und offenen Issues des jeweiligen Projekts. Wo der Beleg der Issue-Tracker eines Maintainers und keine Release-Note ist, sagt die Karte das.
Instrument 11
Index gemeldeter Bibliotheken
libobjectbox-jni.so
Ältere native Android-Bibliotheken scheiterten in einer 16-KB-Umgebung. Eine bestimmte behobene Version ließ sich hier nicht belastbar genug bestätigen, um sie zu veröffentlichen. Prüfen Sie die aktuellen Release Notes von ObjectBox auf die Version, die die 16-KB-Unterstützung ergänzt hat, und bestätigen Sie danach die Binärdatei in Ihrem gebauten APK, statt der Versionsnummer allein zu vertrauen.
mitgelieferte Android-Bibliothek
Das Dart-SDK von ObjectBox liefert eine eigene Android-Bibliothek mit. Eine bestimmte behobene Version ließ sich hier nicht belastbar genug bestätigen, um sie zu veröffentlichen. Prüfen Sie die aktuellen Release Notes von ObjectBox und danach das Artefakt, das Ihr Build tatsächlich auflöst.
libsqlite3.so
Eine ältere Abhängigkeit 3.43.0 tauchte in betroffenen Flutter- und AWS-Amplify-Verpackungen auf. Die Belege aus den Issues nennen 3.46.1+1 als die Version, die die 16-KiB-Unterstützung ergänzt hat. Prüfen Sie die aufgelöste Abhängigkeitsversion und nicht nur die deklarierte, denn ein Framework-Paket kann eine ältere festnageln.
sqlcipher-android
Das ältere Paket android-database-sqlcipher ist upstream zugunsten des gepflegten Pakets sqlcipher-android als veraltet markiert. Eine bestimmte Version ließ sich hier nicht belastbar genug als behobenes Minimum bestätigen: wechseln Sie deshalb auf das aktuelle gepflegte Paket und validieren Sie jede ABI in der gebauten App, statt einer Versionsnummer zu vertrauen.
Binärdateien zur Medienverarbeitung
Das ursprüngliche FFmpegKit-Repository wurde eingestellt, und es ließ sich kein allgemein sicherer konformer Release feststellen. Die Qualität der Forks schwankt. Bestimmen Sie genau, welchen Fork Ihr Build auflöst, prüfen Sie dessen ABI-Artefakte direkt, und wägen Sie Pflegezustand und Herkunft ab, bevor Sie einen davon als Lösung übernehmen.
Realm- und JNI-Binärdateien
Die Meldungen widersprechen sich. Version 20.1.0 wurde gemeldet, und ein späterer Bericht besagte, 20.2.0 habe eine Realm-Binärdatei repariert, während eine andere JNI-Binärdatei problematisch blieb. Eine einzelne sichere Version lässt sich nicht seriös benennen: aktualisieren Sie und prüfen Sie danach jede von Realm beigesteuerte Bibliothek einzeln.
libmediapipe_tasks_vision_jni.so
Mit einer Ausrichtung von 2**12 gemeldet. Im eingesehenen Issue ließ sich kein behobener Release feststellen: behandeln Sie die Kompatibilität daher als versionsabhängig, prüfen Sie die aktuellen Release Notes, aktualisieren Sie, und prüfen Sie die Binärdatei in Ihrem eigenen Build.
OpenCV-Android-Artefakt
Ausrichtungsprobleme wurden für ein Android-Artefakt von OpenCV 5.0.0 gemeldet. Das Repository-Issue verweist auf einen CI-Fix, aber es ließ sich kein bestimmtes veröffentlichtes Artefakt sicher feststellen. Laden Sie genau das AAR herunter, von dem Sie abhängen, entpacken Sie es, und prüfen Sie die Bibliotheken selbst.
lib_burst_generated.so
Unitys eigene Empfehlung lautet, das Burst-Paket auf 1.8.21 oder neuer anzuheben, wenn diese Datei gemeldet wird. Das ist der einzige Eintrag im Index, der auf offizieller Anbieterdokumentation und nicht auf Issue-Meldungen beruht.
libUnityARCore.so, libquack.so und weitere
Community-Meldungen nennen diese unter den Binärdateien, die ein Editor-Update überleben. Es gibt keine allgemeingültige Version zu zitieren, weil jede zu einem anderen Paket gehört. Nutzen Sie den genauen Dateinamen, um zu entscheiden, welchem Paket Sie nachgehen.
Kein Eintrag passt zu diesem Filter. Das ist normal: dieser Index deckt gemeldete Beispiele ab und nicht jede Bibliothek des Ökosystems. Nutzen Sie die Bibliotheks-Zuordnung und verfolgen Sie die Datei in Ihrem eigenen Projekt.
Warum dieser Index kurz ist: die Zahl der Issues zeigt, welche Projekte lautstarke Nutzer haben, und nicht, welche Bibliotheken am häufigsten installiert sind. Eine Rangliste der "häufigsten Verursacher" zu veröffentlichen hieße, eine Statistik zu erfinden. Verallgemeinerbar ist dagegen die Methode: Dateinamen nehmen, Paket finden, aktuelle Releases dieses Pakets prüfen, Binärdatei im eigenen Build kontrollieren.
Der Zusammenhang mit der API-36-Frist vom 31. August 2026
Das sind zwei unabhängige Google-Play-Anforderungen, die sich an einer Stelle treffen. Ein höheres Ziel-API-Level kann die 16-KB-Warnung sichtbar machen, weil die Anforderung für Apps gilt, die Android 15 (API-Level 35) oder höher als Ziel haben. Es erzeugt die falsche Ausrichtung nicht und kann sie auch nicht reparieren.
Google Play verlangt ab dem 31. August 2026 von neuen Apps und App-Updates, Android 16 (API-Level 36) als Ziel zu setzen, mit einer möglichen Verlängerung bis zum 1. November 2026. Das ist eine Änderung an Manifest und Verhalten. Die 16-KB-Regel dagegen ist eine Änderung der Binärkompatibilität. Wer am Montag targetSdk erhöht und am Dienstag eine 16-KB-Warnung sieht, hat nichts kaputtgemacht: die nativen Bibliotheken waren bereits für 4-KB-Seiten kompiliert, und das höhere Ziel-Level hat die App lediglich in den Geltungsbereich einer Prüfung gebracht, die ohnehin gegriffen hätte.
Anforderung A
API 36 als Ziel- Datum 31. August 2026, Verlängerung bis 1. November 2026
- Geltung Neue Apps und App-Updates
- Liegt in Ihrem Manifest und Ihrer Build-Konfiguration
- Behoben durch Anheben des Ziel-Levels und Umgang mit den Verhaltensänderungen von Android 16
Anforderung B
Unterstützung von 16-KB-Speicherseiten- Datum 1. Februar 2027
- Geltung Apps mit Ziel API 35+ auf 64-Bit-Geräten
- Liegt in Den nativen Binärdateien in Ihrem Bundle
- Behoben durch Neukompilieren oder Ersetzen jeder falsch ausgerichteten Bibliothek
Praktisch behandeln Sie beides als eine Migration mit zwei Nachweisen. Sie werden das Ziel-Level ohnehin anheben: planen Sie das Audit der nativen Bibliotheken in denselben Release ein, statt es mitten in der API-36-Hektik zu entdecken. Alle Level je Geräteform, die Ausnahmen und die Mechanik der Verlängerung finden Sie in unserem Artikel zur API-36-Frist von Google Play, und die ganze Abfolge vom Konto bis zur Produktion in unserem Artikel zu den Veröffentlichungsanforderungen 2026.
Die Prüfung vor dem Upload
Elf Prüfungen, jede mit einem konkreten Beleg für das Bestehen. Arbeiten Sie sie ab, bevor Sie hochladen, statt nachdem Play Ihnen ein Problem meldet: so wird aus einer unbegrenzten Fehlersuche eine endliche Liste.
Instrument 12
Prüfung vor dem Upload
0 von 11 erledigt
Noch nichts belegt. Beginnen Sie mit dem Build, den Sie tatsächlich hochladen wollen, und nicht mit dem letzten, den Sie zufällig offen hatten.
Ihr Fortschritt wird ausschließlich in diesem Browser gespeichert. Es wird nichts irgendwohin gesendet, und das Löschen Ihrer Browserdaten löscht ihn.
Alle elf Punkte zu erledigen belegt die technische Ausrichtung gegenüber den auf dieser Seite zitierten Prüfungen. Es ist keine Zusage einer Genehmigung. Google Play kann beim selben Upload weiterhin unabhängige Richtlinien-, Inhalts- oder Qualitätsprobleme anbringen, und keine Checkliste der Welt kann dafür sprechen.
Wo das mit dem geschlossenen Test kollidiert
Nichts auf dieser Seite ändert Ihre Tester-Anforderung, und nichts an Ihren Testern ändert Ihren Build. Die beiden Probleme kollidieren nur auf einer Achse: der Zeit. Ein geschlossener Test über 14 Tage läuft auf einer Uhr, die Sie nicht anhalten können, und die Suche nach einer nativen Bibliothek läuft auf einer Uhr, die niemand vorhersagen kann.
Der schmerzhafte Ablauf sieht so aus. Ein privates Entwicklerkonto startet einen geschlossenen Test, das Fenster von 14 Tagen fortlaufender Anmeldung beginnt, und irgendwo in der Mitte bringt ein höheres Ziel-Level eine 16-KB-Warnung ans Licht. Jetzt kompiliert der Entwickler native Abhängigkeiten neu, während eine Testergruppe drumherum intakt bleiben muss. Einen neuen Release in den Test-Track hochzuladen ist völlig in Ordnung, und Google ermutigt Entwickler ausdrücklich dazu, während eines Tests weiter zu aktualisieren. Was den Lauf zerstört, ist eine Tester-Seite, die verstummt.
Genau diesen Teil hält PrimeTestLab stabil. Wir stellen 12 echte Tester auf echten Geräten von Android 7 bis 17, angemeldet und über die vollen 14 Tage gehalten, damit Ihre Neukompilierung gegen einen stabilen Test läuft und nicht gegen einen zerfallenden. Der Test startet in 4-6 Stunden, und wir haben das über 7.400+ Apps in 120+ Ländern mit einer Erfolgsquote von 99.9% durchgeführt.
Tester selbst rekrutieren oder betreut testen lassen
| Googles Anforderung | Selbst rekrutieren | Betreuter Test |
|---|---|---|
| Mindestens 12 angemeldete Tester | Echte Menschen finden, einweisen und nachfassen, und dann hoffen, dass sich niemand abmeldet | 12 gestellt und über das gesamte Fenster gehalten |
| 14 Tage fortlaufend | Ein einziger Tester, der mittendrin aussteigt, unterbricht das durchgehende Fenster | Die Gruppe wird überwacht, damit das Fenster intakt bleibt |
| Echte Geräte, echte Menschen | Emulatoren und inaktive Konten sind die übliche Abkürzung und der übliche Grund für einen gescheiterten Lauf | Echte Geräte von Android 7 bis 17 |
| Zeit bis zur ersten Anmeldung | Tage, je nachdem wer antwortet | Der Test startet in 4-6 Stunden |
| Kosten | Ihre Zeit, in genau der Woche, in der Sie ohnehin Bibliotheken neu kompilieren | Ab $19.99 plus 5% Servicegebühr |
| Neukompilieren mitten im Test | Jeder neue Upload bedeutet, alle erneut um ein Update zu bitten | Veröffentlichen Sie neue Releases frei, die Gruppe bleibt angemeldet |
Deutlich zur Abgrenzung: wir kompilieren Ihre nativen Bibliotheken nicht neu, und dieser Artikel ist kein Verkaufsargument dafür. Die 16-KB-Arbeit gehört Ihnen, und alles vor diesem Abschnitt ist so geschrieben, dass sie so kurz wie möglich ausfällt. Wir nehmen Ihnen die parallel laufende Tester-Anforderung ab, damit die beiden Probleme nicht länger um dieselben zwei Wochen konkurrieren.
Tipp zur Reihenfolge
Wenn Sie den geschlossenen Test noch nicht gestartet haben und bereits wissen, dass Sie native Bibliotheken mitliefern, bringen Sie zuerst das Testerfenster zum Laufen und erledigen Sie die Ausrichtungsarbeit darin. Googles qualifizierender Zeitraum misst die durchgehende Anmeldung der Tester und nicht einen eingefrorenen Build, und Google ermutigt dazu, während eines Tests weiter zu aktualisieren: die beiden Zeitpläne können sich also überlappen, statt sich zu stapeln. Behalten Sie dabei denselben Test-Track und dieselbe Testergruppe. Das spart oft eine ganze Woche.
Häufige Fragen
Lehnt Google Play nicht 16-KB-kompatible Apps bereits ab?
Googles aktuelle Dokumentation besagt, dass Sie ab dem 1. Februar 2027 keine Updates mehr veröffentlichen können, die Android 15 (API-Level 35) oder höher als Ziel haben und 16 KB auf 64-Bit-Geräten nicht unterstützen. Vor diesem Datum sehen die meisten Entwickler eine Kompatibilitätswarnung in der Play Console und keine harte Sperre. Die auf der zitierten Google-Seite dokumentierte Folge ist die Unmöglichkeit, nicht konforme Updates zu veröffentlichen, nicht die automatische Entfernung einer bereits veröffentlichten App.
Warum nennt Google den 1. Februar 2027, während andere Artikel den 1. November 2025 nennen?
Der 1. November 2025 war Googles ursprünglich angekündigte Frist und der 31. Mai 2026 ein späteres historisches Verlängerungsdatum. Stand 5. August 2026 zeigen sowohl Googles aktuelle Android-Developers-Seite als auch der aktuelle Screenshot der Warnung in der Play Console den 1. Februar 2027: es gilt also die neuere Primärquelle. Viele Blogartikel und KI-Antworten zitieren weiterhin die älteren Daten, weil sie vor der Änderung geschrieben wurden.
Ich habe nie C++ geschrieben. Warum ist meine App betroffen?
Ein Framework, ein SDK, ein Plugin, eine Spiel-Engine, eine Datenbank, eine Medienkomponente oder ein App-Baukasten kann native .so-Dateien hinzufügen, selbst wenn Ihr eigener Quellcode Dart, JavaScript, Python, Java oder Kotlin ist. Googles Hinweise schließen ausdrücklich Apps ein, die NDK-Bibliotheken indirekt über eine Abhängigkeit nutzen. Öffnen Sie das APK in Android Studio über Build und dann Analyze APK: jede .so-Datei unterhalb von lib bedeutet, dass die verpackte App nativen Code verwendet.
Braucht eine reine Kotlin-App überhaupt Änderungen?
Laut Google unterstützt eine App, die ausschließlich Java oder Kotlin verwendet, alle Bibliotheken und SDKs eingeschlossen, bereits 16-KB-Geräte. Google empfiehlt dennoch, in einer 16-KB-Umgebung auf unerwartete Regressionen zu testen. Prüfen Sie, dass das tatsächliche Release-APK kein lib-Verzeichnis enthält, bevor Sie Ihre App als reines Kotlin bezeichnen, denn eine einzige Analytics- oder Datenbank-Abhängigkeit fügt eines hinzu.
Welche Flutter-Version behebt die Warnung zur 16-KB-Seitengröße?
Keine offizielle Quelle nennt eine Flutter-Version, die die Konformität aller Flutter-Apps und Plugins garantiert. Die Release Notes von Flutter 3.27 sind enger, als sie wirken: sie decken die 16-KB-Unterstützung speziell für plugin_ffi-Vorlagen ab und nicht die gesamte Engine. Flutter 3.38 ist der am besten dokumentierte Meilenstein: Flutter hat das Update ausdrücklich als Vorbereitung auf Plays 16-KB-Anforderung positioniert und den Standard-NDK auf r28 umgestellt. Am sichersten ist der Wechsel auf den aktuellen stabilen Flutter-Release, das Update jedes nativen Plugins, ein neuer Build des Release-Bundles und die Prüfung jeder .so-Datei, die dabei herauskommt.
Welche React-Native-Version unterstützt 16-KB-Seiten?
React Native 0.77 ist die klare offizielle Basisversion. Die Release-Ankündigung besagt, dass React Native bereit ist, 16-KB-Seitengrößen vollständig zu unterstützen. Native Community-Module, lokaler C++-Code und Drittanbieter-SDKs können weiterhin inkompatible Binärdateien mitliefern: aktualisieren Sie über den unterstützten React-Native- oder Expo-Migrationspfad und prüfen Sie danach das erzeugte APK.
Welche Unity-Version brauche ich für die Unterstützung von 16-KB-Seiten?
Unity nennt 6000.1 oder neuer, 6000.0.38f1 oder neuer, 2022.3.56f1 oder neuer sowie 2021.3.48f1 oder neuer im erweiterten LTS für berechtigte Enterprise- oder Industry-Kunden. Aktualisieren Sie außerdem Ihre nativen Plugins und heben Sie Burst auf 1.8.21 oder neuer an, wenn die Play Console lib_burst_generated.so nennt. Eine unterstützte Editor-Version ist notwendig, aber nicht hinreichend, weil Drittanbieter-Plugins eigene Binärdateien mitliefern.
Wie finde ich die genaue .so-Datei, die scheitert?
Öffnen Sie das APK über Build und dann Analyze APK in Android Studio, klappen Sie lib/arm64-v8a und lib/x86_64 auf und lesen Sie die Spalte Alignment, die Warnungen für Dateien mit Ausrichtungsproblemen anzeigt. Zur Bestätigung auf der Kommandozeile führen Sie Googles Skript check_elf_alignment.sh gegen das APK aus oder prüfen eine Bibliothek mit llvm-objdump -p file.so, weitergeleitet an grep LOAD. Jede LOAD-Ausrichtung unter 2**14 erfordert eine Reaktion.
Warum besteht mein APK, während mein App Bundle weiter scheitert?
Die ELF-Ausrichtung innerhalb einer Bibliothek und die ZIP-Ausrichtung innerhalb des verpackten Artefakts sind zwei getrennte Prüfungen. Führen Sie bundletool dump config --bundle=app.aab aus und suchen Sie nach alignment: PAGE_ALIGNMENT_16K besteht, während PAGE_ALIGNMENT_4K bedeutet, dass die erzeugten APKs weiterhin mit 4 KB angefordert werden. Google warnt ausdrücklich, dass Android Gradle Plugin 8.3 bis 8.5 lokal korrekt aussehen kann, während die APKs, die Play aus Ihrem Bundle baut, nicht sauber ZIP-ausgerichtet sind: wechseln Sie deshalb auf 8.5.1 oder neuer.
Reicht ein Update auf NDK r28 zur Behebung aus?
Nein. NDK r28 und höher kompilieren standardmäßig 16-KB-ausgerichtet, das betrifft aber nur nativen Code, der während Ihres Builds kompiliert wird. Es kann keine vorkompilierte .so-Datei umschreiben, die in einem AAR, einem Plugin oder einem Spiel-Engine-Paket eines Dritten ankommt. Jede vorkompilierte native Abhängigkeit muss selbst aktualisiert, ersetzt oder neu kompiliert und neu eingebunden werden.
Wie kann ich die 16-KB-Unterstützung testen, ohne ein passendes Telefon zu besitzen?
Installieren Sie eines von Googles 16-KB-Systemabbildern für den Android-Emulator über den SDK Manager oder buchen Sie ein unterstütztes Gerät im Samsung Remote Test Lab. Was Sie auch nutzen: bestätigen Sie die Umgebung zuerst mit adb shell getconf PAGE_SIZE, die Ausgabe muss 16384 lauten, damit der Test überhaupt aussagekräftig ist. Ein Erfolg im Emulator belegt das Laufzeitverhalten, nicht die Verpackung: prüfen Sie also weiterhin auch das Release-Bundle.
Setzt das Beheben der 16-KB-Unterstützung meinen geschlossenen Test zurück?
Google misst den qualifizierenden Zeitraum an mindestens 12 Testern, die 14 Tage fortlaufend angemeldet bleiben, und nicht an einem eingefrorenen Build, und ermutigt Entwickler ausdrücklich, den Build während eines Tests weiter zu aktualisieren. Google veröffentlicht keine ausdrückliche Zusage für jeden denkbaren Fall eines Build-Austauschs: am sichersten halten Sie daher Ihre Testergruppe stabil, während Sie mitten im Test ein neu kompiliertes, 16-KB-konformes Bundle veröffentlichen. PrimeTestLab stellt 12 echte Tester auf echten Geräten ab $19.99 plus 5% Servicegebühr und hält die Gruppe über die vollen 14 Tage.
Fazit
Zusammenfassung
Google Play verlangt von Apps mit Ziel Android 15 (API-Level 35) oder höher, dass sie 16-KB-Speicherseiten auf 64-Bit-Geräten unterstützen, und ab dem 1. Februar 2027 lassen sich nicht konforme Updates nicht mehr veröffentlichen. Der 1. November 2025 und der 31. Mai 2026 sind tote Daten, die immer noch ranken. Reine Java- oder Kotlin-Apps sind bereits konform. Alle anderen gehen dieselben drei Schritte: die fehlerhafte .so benennen, das Paket aktualisieren, das sie liefert, und das Artefakt mit zwei unabhängigen Prüfungen nachweisen, jedes ELF-LOAD-Segment auf 2**14 oder mehr ausgerichtet und das Bundle mit der Meldung PAGE_ALIGNMENT_16K. AGP 8.5.1+ mit NDK r28+ ist die sicherste Standard-Toolchain, und keines von beiden repariert eine Binärdatei, die jemand anderes kompiliert hat. Fällt das mitten in einen geschlossenen Test, ist die Tester-Seite der Teil, den Sie abgeben können. Preispläne ansehen →
Primärquellen
Was auf dieser Seite zuerst veraltet
- Das Datum 1. Februar 2027. Google hat diesen Zeitplan bereits mehr als einmal verschoben. Prüfen Sie den Vermerk "Zuletzt aktualisiert" am Ende des Leitfadens zu Seitengrößen, bevor Sie einen Release darum herum planen.
- Die Texte der Play Console. Beschriftungen und Navigation der Console ändern sich unabhängig von den Richtlinienseiten: die genauen Überschriften bei Ihnen können von den hier wiedergegebenen abweichen.
- Die Framework-Basisversionen. Flutter veröffentlicht häufig stabile Releases, die Support-Politik von React Native entwickelt sich weiter, und die Unity-LTS-Berechtigung ändert sich. Prüfen Sie die aktuellen Release Notes statt einer in einem Artikel gedruckten Versionsnummer.
- Der Index gemeldeter Bibliotheken. Jedes Paket kann in jedem Release eine native Binärdatei hinzufügen, ersetzen oder wieder verschlechtern. Prüfen Sie immer das Artefakt in Ihrem eigenen Bundle.
- Die Namen der Emulator-Images. Als experimentell gekennzeichnete Images können umbenannt oder hochgestuft werden: der genaue Text im SDK Manager passt womöglich nicht mehr.
Am 9. August 2026 gegen die Google-Dokumentation geprüft. Monatliche Überprüfung bis mindestens einen Monat nach Inkrafttreten.