Unterstützung von Seitengrößen von 16 KB

Bisher wurden in Android nur Arbeitsspeicherseiten mit 4 KB unterstützt. Dadurch wurde die Leistung des Systemspeichers für die durchschnittliche Menge an Gesamtspeicher optimiert, die Android-Geräte in der Regel hatten. Ab Android 15 unterstützt AOSP Geräte, die für die Verwendung einer Seitengröße von 16 KB konfiguriert sind (16‑KB-Geräte). Wenn Ihre App NDK-Bibliotheken verwendet, entweder direkt oder indirekt über ein SDK, müssen Sie Ihre App neu erstellen, damit sie auf diesen 16‑KB-Geräten funktioniert.

Da Gerätehersteller weiterhin Geräte mit größeren Mengen an physischem Arbeitsspeicher (RAM) entwickeln, werden viele dieser Geräte 16‑KB-Seitengrößen (und schließlich noch größere) verwenden, um die Leistung des Geräts zu optimieren. Wenn Sie Unterstützung für Geräte mit einer Seitengröße von 16 KB hinzufügen, kann Ihre App auf diesen Geräten ausgeführt werden und von den damit verbundenen Leistungsverbesserungen profitieren. Ohne Neukompilierung funktionieren Apps in zukünftigen Android-Versionen nicht auf Geräten mit 16 KB.

Damit Sie Ihre App entsprechend anpassen können, haben wir Anleitungen dazu bereitgestellt, wie Sie prüfen, ob Ihre App betroffen ist, wie Sie Ihre App neu erstellen (falls zutreffend) und wie Sie Ihre App mit Emulatoren (einschließlich Android 15-Systemabbildern für den Android-Emulator) in einer 16‑KB-Umgebung testen.

Anforderung an die Kompatibilität mit Google Play

Damit deine App auf den aktuellen Android-Versionen einwandfrei funktioniert, müssen alle Apps, die auf Android 15 (API-Level 35) und höher ausgerichtet sind, auf 64‑Bit-Geräten in Google Play Speicherseiten mit 16 KB unterstützen. Ab dem 1. Februar 2027 kannst du keine App-Updates veröffentlichen, die keine Speicherseiten mit 16 KB unterstützen.

Vorteile und Leistungssteigerungen

Geräte, die mit einer Seitengröße von 16 KB konfiguriert sind, benötigen im Durchschnitt etwas mehr Arbeitsspeicher, erzielen aber auch verschiedene Leistungsverbesserungen für das System und die Apps:

• Kürzere App-Startzeiten, während das System unter Speicherauslastung steht: im Durchschnitt 3,16 % niedriger, mit deutlicheren Verbesserungen (bis zu 30%) bei einigen von uns getesteten Apps
• Verringerter Stromverbrauch beim Starten der App: durchschnittlich 4,56% weniger
• Schnellerer Kamerastart: 4,48% schnellere Heißstarts und 6,60% schnellere Kaltstarts im Durchschnitt
• Verbesserte Systemstartzeit: durchschnittlich um 8% (ca. 950 Millisekunden)

Diese Verbesserungen basieren auf unseren ersten Tests. Die Ergebnisse auf tatsächlichen Geräten werden sich wahrscheinlich unterscheiden. Im Rahmen unserer Tests werden wir zusätzliche Analysen zu den potenziellen Vorteilen für Apps durchführen.

Prüfen, ob deine App betroffen ist

Wenn Ihre App nativen Code verwendet, sollten Sie Ihre App neu erstellen, um Geräte mit 16‑KB-Speicherseiten zu unterstützen. Wenn Sie sich nicht sicher sind, ob Ihre App nativen Code verwendet, können Sie mit dem APK Analyzer prüfen, ob nativer Code vorhanden ist, und dann die Ausrichtung von ELF-Segmenten für alle gefundenen gemeinsam genutzten Bibliotheken prüfen. Android Studio bietet auch Funktionen, mit denen Sie Ausrichtungsprobleme automatisch erkennen können.

Wenn Ihre App nur Code verwendet, der in der Programmiersprache Java oder in Kotlin geschrieben wurde, einschließlich aller Bibliotheken oder SDKs, unterstützt Ihre App bereits Geräte mit 16 KB. Wir empfehlen Ihnen jedoch, Ihre App in einer 16‑KB-Umgebung zu testen, um zu prüfen, ob es unerwartete Regressionen im App-Verhalten gibt.

Verwendet deine App nativen Code?

Deine App verwendet nativen Code, wenn einer der folgenden Punkte zutrifft:

• Deine App verwendet C/C++-Code (nativen Code). Wenn deine App das Android NDK verwendet, verwendet sie nativen Code.
• Deine App ist mit nativen Bibliotheken oder Abhängigkeiten von Drittanbietern (z. B. SDKs) verknüpft, die nativen Code verwenden.
• Deine App wurde mit einem Drittanbieter-App-Builder erstellt, der native Bibliotheken auf dem Gerät verwendet.

Native Bibliotheken mit dem APK Analyzer identifizieren

Der APK Analyzer ist ein Tool, mit dem du verschiedene Aspekte eines erstellten APK bewerten kannst. So prüfst du, ob deine App nativen Code verwendet (unabhängig davon, ob sie mit 16 KB kompatibel ist):

1. Öffne Android Studio und klicke auf Datei > Öffnen und wähle ein beliebiges Projekt aus.

2. Klicke in der Menüleiste auf Build > APK analysieren...

   

3. Wähle das APK aus, das du analysieren möchtest.

4. Suche im Ordner lib nach freigegebenen Objektdateien (.so). Wenn freigegebene Objektdateien vorhanden sind, verwendet deine App nativen Code. In der Spalte Ausrichtung werden Warnmeldungen für alle Dateien mit Ausrichtungsproblemen angezeigt. Wenn keine freigegebenen Objektdateien vorhanden sind oder kein Ordner lib vorhanden ist, verwendet deine App keinen nativen Code.

   

Ausrichtungsprobleme mit automatisierten Prüfungen erkennen

Android Studio warnt dich proaktiv, wenn deine vorkompilierten Bibliotheken oder APKs nicht mit 16 KB kompatibel sind. Mit dem APK Analyzer-Tool kannst du prüfen, welche Bibliotheken aktualisiert werden müssen oder ob Codeänderungen erforderlich sind.

<figure>
  <img src="/images/guide/practices/studio-align-warnings.png"
       class="no-filter" width="300"
       alt="Studio warning notifications about alignment issues in a project">
</figure>

Lint in Android Studio hebt auch native Bibliotheken hervor, die nicht mit 16 KB ausgerichtet sind.

<figure>
  <img src="/images/guide/practices/studio-align-lint.png"
       class="no-filter"
       alt="Studio linter warning about a non-aligned native library">
</figure>

Ausrichtung von ELF-Segmenten für freigegebene Bibliotheken prüfen

Prüfe für alle freigegebenen Bibliotheken, ob die ELF-Segmente der freigegebenen Bibliotheken mit der 16‑KB-ELF-Ausrichtung richtig ausgerichtet sind. Wenn du unter Linux oder macOS entwickelst, kannst du das Skript check_elf_alignment.sh verwenden, wie im folgenden Abschnitt beschrieben. Du kannst auch die Befehlszeilentools direkt verwenden.

Skript `check_elf_alignment.sh` verwenden (Linux oder macOS)

So prüfst du die Ausrichtung von ELF-Segmenten mit dem Skript check_elf_alignment.sh:

1. Speichere das check_elf_alignment.sh Skript in einer Datei.

2. Führe das Skript für die APK-Datei deiner App aus:

   check_elf_alignment.sh APK_NAME.apk
   

   Das Skript gibt für alle arm64-v8a freigegebenen Bibliotheken entweder ALIGNED oder UNALIGNED aus.

3. Wenn freigegebene arm64-v8a oder x86_64 Bibliotheken UNALIGNED sind, musst du die Verpackung für diese Bibliotheken aktualisieren, deine App neu kompilieren und sie noch einmal testen. Folge dazu der Anleitung in diesem Abschnitt.

Befehlszeilentools direkt verwenden

So prüfst du die Ausrichtung von ELF-Segmenten direkt mit Befehlszeilentools:

1. Prüfe, ob sowohl die Android SDK Build-Tools Version 35.0.0 oder höher als auch das Android NDK mit dem SDK Manager in Android Studio oder sdkmanager Befehlszeilentool installiert sind.

2. Extrahiere die APK-Datei deiner App:

   Linux oder macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. Prüfe im temporären Verzeichnis, in das du die APK-Datei extrahiert hast, den Inhalt des Verzeichnisses lib auf freigegebene Objektdateien (.so). Das sind dieselben freigegebenen Objektdateien, die du beim Identifizieren nativer Bibliotheken mit dem APK Analyzer gesehen hast. Führe den folgenden Befehl für jede freigegebene Objektdatei aus:

   Linux oder macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   Dabei ist SDK_ROOT_LOCATION der Pfad zum Verzeichnis, in dem du das Android SDK installiert hast, SHARED_OBJECT_FILE der Name der freigegebenen Objektdatei, die du prüfst, und NDK_VERSION die Version des installierten Android NDK (z. B. 28.0.12433566). Die Ausgabe sieht für jede geprüfte Datei in etwa so aus:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Prüfe die Ausgabezellen. Die Werte der Ladesegmente dürfen nicht kleiner als 2**14 sein. Wenn Ladesegmente 2**13, 2**12 oder niedrigere Werte haben, musst du die Verpackung für diese Bibliotheken aktualisieren, dann deine App neu kompilieren und sie noch einmal testen. Folge dazu der Anleitung in diesem Abschnitt.

5. Führe als Nächstes das Befehlszeilentool zipalign für die APK-Datei deiner App aus:

   Linux oder macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   Dabei ist SDK_ROOT_LOCATION der Pfad zum Verzeichnis, in dem du das Android SDK installiert hast, und APK_NAME der Name der APK-Datei deiner App. In der letzten Zeile der Ausgabe steht „Verification successful“, wenn alle freigegebenen Bibliotheken richtig ausgerichtet sind.

   Wenn die Überprüfung fehlgeschlagen ist, müssen einige freigegebene Bibliotheken neu ausgerichtet werden. Du musst also die Verpackung für diese Bibliotheken aktualisieren, dann deine App neu kompilieren und sie noch einmal testen. Folge dazu der Anleitung in diesem Abschnitt.

Sicherheitsflag „RELRO“ prüfen

Um Sicherheitslücken zu minimieren, verwenden moderne Linker das Flag „Relocation Read-Only“ (RELRO), um die Verlagerungs abschnitte der freigegebenen Objektdatei nach dem Laden schreibgeschützt zu machen. Wenn ein Abschnitt mit aktiviertem RELRO mit einem Abschnitt ohne aktiviertem RELRO (aus einer anderen Objektdatei) auf derselben Seite kombiniert wird, stürzt die App ab.

Führe den folgenden Befehl für jede freigegebene Objektdatei aus (Linux oder macOS):

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -l SHARED_OBJECT_FILE.so | grep RELRO

Prüfe die Befehlsausgabe. Die String GNU_RELRO muss ausgegeben werden. Das bestätigt, dass RELRO für die .so-Datei aktiviert ist.

App mit Unterstützung für 16‑KB-Geräte erstellen

Wenn deine App nativen Code verwendet, führe die Schritte in den folgenden Abschnitten aus, um sicherzustellen, dass deine App 16‑KB-Geräte unterstützt:

1. Verpackung deiner freigegebenen Bibliotheken aktualisieren
2. App mit 16‑KB-ELF-Ausrichtung kompilieren
3. Code korrigieren und Laufzeitprobleme beheben
4. SDKs auf 16‑KB-Unterstützung prüfen

Verpackung deiner freigegebenen Bibliotheken aktualisieren

Führe ein Upgrade auf AGP-Version 8.5.1 oder höher durch und verwende unkomprimierte freigegebene Bibliotheken.

bundletool verwenden, um die ZIP-Ausrichtung zu prüfen

So prüfst du die Ausrichtung deines Bundles:

bundletool dump config --bundle=<my .aab>  | grep alignment

Wenn PAGE_ALIGNMENT_16K angezeigt wird, fordert dein Bundle eine 16‑KB-ZIP-Ausrichtung an. Wenn PAGE_ALIGNMENT_4K angezeigt wird, werden die aus diesem AAB erstellten APKs so konfiguriert, dass die ` .so`-Dateien in der ZIP-Datei eine 4‑KB-Ausrichtung haben.

AGP-Version 8.5.1 oder höher

Auf 16‑KB-Geräten müssen Apps, die mit unkomprimierten freigegebenen Bibliotheken ausgeliefert werden, an einer 16‑KB-ZIP-ausgerichteten Grenze ausgerichtet werden. Dazu musst du ein Upgrade auf Android-Gradle-Plug-in (AGP) Version 8.5.1 oder höher durchführen. Weitere Informationen zum Upgrade findest du im Abschnitt Android Gradle plugin Upgrade Assistant.

AGP-Version 8.5 oder niedriger

Wenn du kein Upgrade auf AGP-Version 8.5.1 oder höher durchführen kannst, kannst du stattdessen komprimierte freigegebene Bibliotheken verwenden. Aktualisiere deine Gradle-Konfiguration so, dass Gradle deine freigegebenen Bibliotheken beim Verpacken deiner App komprimiert, um Probleme bei der App-Installation mit nicht ausgerichteten freigegebenen Bibliotheken zu vermeiden.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

AGP-Version 8.0 oder niedriger

Wenn du eine AGP-Version 8.0 oder niedriger verwendest, musst du auch die Option für unkomprimierte native Bibliotheken für App-Bundles in der Datei gradle.properties deaktivieren:

android.bundle.enableUncompressedNativeLibs=false

App mit 16‑KB-ELF-Ausrichtung kompilieren

Auf 16‑KB-Geräten müssen die ELF-Segmente der freigegebenen Bibliotheken mit der 16‑KB-ELF-Ausrichtung richtig ausgerichtet sein, damit deine App ausgeführt werden kann.

Wenn du Spieleentwickler bist und dein Spiel auf der Unity-Spiel-Engine ausgeführt wird, lies die Unity-Anleitung. Wenn dein Spiel auf der Unreal-Game-Engine ausgeführt wird, lies die Unreal-Anleitung. Bei nativen Game-Engines fahre mit dieser Anleitung fort.

Führe die Schritte in einem der folgenden Abschnitte aus, um deine App mit einer 16‑KB-ELF-Ausrichtung zu kompilieren. Die Schritte variieren je nach verwendeter Version des Android NDK.

Android NDK r28 und höher

Mit NDK-Version r28 und höher werden standardmäßig 16‑KB-ausgerichtete Bibliotheken kompiliert.

Android NDK r27 und niedriger

Wenn du mit Android NDK-Version r27 oder niedriger 16‑KB-ausgerichtete freigegebene Bibliotheken kompilieren möchtest, verwende die folgenden Linker-Flags:

-Wl,-z,max-page-size=16384
-Wl,-z,common-page-size=16384

So aktualisierst du die Konfigurationsdateien deines Build-Systems:

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

Code korrigieren und Laufzeitprobleme beheben

Auch wenn deine App mit 16 KB ausgerichtet ist, können Fehler auftreten, wenn an bestimmten Stellen im Code davon ausgegangen wird, dass ein Gerät eine bestimmte Seitengröße verwendet. So vermeidest du das:

1. Entferne alle fest codierten Abhängigkeiten, die auf die PAGE_SIZE Konstante verweisen, oder Instanzen in deiner Codelogik, bei denen davon ausgegangen wird, dass die Seitengröße eines Geräts 4 KB (4096) beträgt.

   Verwende stattdessen getpagesize() oder sysconf(_SC_PAGESIZE).

2. Suche nach Verwendungen von mmap() und anderen APIs, die seitenweise ausgerichtete Argumente erfordern, und ersetze sie bei Bedarf durch Alternativen.

In einigen Fällen, wenn deine App PAGE_SIZE als praktischen Wert verwendet, der nicht an die zugrunde liegende Seitengröße gebunden ist, führt das nicht dazu, dass deine App im 16‑KB-Modus nicht mehr funktioniert. Wenn dieser Wert jedoch ohne MAP_FIXED mit mmap an den Kernel übergeben wird, verwendet der Kernel trotzdem eine ganze Seite, was Speicherplatz verschwendet. Aus diesen Gründen ist PAGE_SIZE nicht definiert, wenn der 16‑KB-Modus in NDK r27 und höher aktiviert ist.

Wenn deine App PAGE_SIZE auf diese Weise verwendet und diesen Wert nie direkt an den Kernel übergibt, erstelle anstelle von PAGE_SIZE eine neue Variable mit einem neuen Namen, um anzugeben, dass sie für andere Zwecke verwendet wird und keine tatsächliche Speicherseite darstellt.

SDKs auf 16‑KB-Unterstützung prüfen

Viele SDKs sind mit 16‑KB-Seitengrößen kompatibel, insbesondere wenn du sie selbst erstellst oder aktuelle vorkompilierte Versionen verwendest. Da einige vorkompilierte SDKs oder SDK-Versionen jedoch nicht mit 16 KB kompatibel sind, solltest du auf der Website des jeweiligen SDK-Anbieters nachsehen, welche Version mit 16 KB verwendet werden kann.

App in einer 16‑KB-Umgebung testen

Nachdem du deine App mit Unterstützung für 16‑KB-Geräte erstellt hast, solltest du sie in einer 16‑KB-Umgebung testen, um zu sehen, ob es zu Regressionen kommt. Gehe dazu so vor:

1. Richte das Android 15 SDK oder höher ein.

2. Richte eine der folgenden Testumgebungen ein:

   • Android Emulator mit einem Android 15-System-Image auf 16‑KB-Basis einrichten
     • Cuttlefish mit 16‑KB-Seitengröße auf ARM64 verwenden
   • Cuttlefish mit 16‑KB-Seitengröße auf x86‑64 simulieren
   • 16‑KB-Modus auf einem Gerät über die Entwickleroptionen aktivieren
   • Samsung Remote Test Lab auf Geräten mit 16 KB ‑Unterstützung verwenden

3. Starte dein Testgerät und führe dann den folgenden Befehl aus, um zu prüfen, ob es eine 16‑KB-Umgebung verwendet:

   adb shell getconf PAGE_SIZE
   

   Der Befehl sollte den Wert 16384 zurückgeben.

4. Führe den folgenden zipalign-Befehl aus, um zu prüfen, ob deine App mit 16 KB ausgerichtet ist. Dabei ist APK_NAME der Name der APK-Datei deiner App:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. Teste deine App gründlich und konzentriere dich dabei auf alle Bereiche, die von der Änderung von Codeinstanzen betroffen sein könnten, die auf bestimmte Seitengrößen verweisen.

Android Emulator mit einem System-Image auf 16‑KB-Basis einrichten

So richtest du eine 16‑KB-Umgebung mit dem Android Emulator ein:

1. Klicke in Android Studio auf Tools > SDK-Manager.

2. Setze auf dem Tab SDK-Plattformen ein Häkchen bei Paketdetails anzeigen und erweitere den Abschnitt Android VanillaIceCream oder höher. Wähle je nach den virtuellen Geräten, die du erstellen möchtest, eines oder beide der folgenden Emulator-System-Images aus:

   • Google APIs Experimental 16 KB Page Size ARM 64 v8a System Image
   • Google APIs Experimental 16 KB Page Size Intel x86_64 Atom System Image

   

3. Klicke auf Anwenden > OK , um die ausgewählten System-Images herunterzuladen.

4. Folge der Anleitung, um ein virtuelles Gerät für Android 15 einzurichten. Wenn du aufgefordert wirst, ein System-Image auszuwählen, wähle das heruntergeladene 16 KB-System-Image aus, das du heruntergeladen hast. Wenn es nicht automatisch empfohlen wird, findest du das 16‑KB-System-Image auf dem Tab Andere Images.

   

Emulator starten

Nachdem du den Android Emulator und die virtuellen Geräte eingerichtet hast, starte den Emulator über das Menü des Zielgeräts oder über die Befehlszeile.

16‑KB-Modus auf einem Gerät über die Entwickleroptionen aktivieren

Aktivieren Sie die Entwickleroption Mit Seitengröße von 16 KB starten, um ein Gerät im 16‑KB-Modus zu starten.

In QPR-Versionen von Android 15 können Sie die Entwickleroption verwenden, die auf bestimmten Geräten verfügbar ist, um das Gerät im 16‑KB-Modus zu starten und Tests auf dem Gerät durchzuführen. Bevor Sie die Entwickleroption verwenden, rufen Sie die Einstellungen > System > Softwareupdates auf und installieren Sie alle verfügbaren Updates.

Diese Entwickleroption ist auf den folgenden Geräten verfügbar:

• Google Pixel 8 und Google Pixel 8 Pro (mit Android 15 QPR1 oder höher)

• Google Pixel 8a (mit Android 15 QPR1 oder höher)

• Google Pixel 9, Google Pixel 9 Pro und Google Pixel 9 Pro XL (mit Android 15 QPR2 oder höher)

• Google Pixel 9a (mit Android 16 oder höher)

16‑KB-Abwärtskompatibilitätsmodus

Warnung im Kompatibilitätsmodus für die Seitengröße

Die 16‑KB-Abwärtskompatibilitätsoption ist verfügbar, wenn ein Gerät mit einem 16‑KB-Kernel ausgeführt wird. Der Paketmanager führt eine App im 16‑KB-Abwärtskompatibilitätsmodus aus, wenn die folgenden Bedingungen erfüllt sind:

• Die App hat ELF-Dateien (mit der Erweiterung .so) mit einer Ausrichtung des LOAD-Segments von 4 KB.
• Das gezippte APK hat unkomprimierte ELF-Dateien mit einer 4‑KB-ZIP-Ausrichtung.

Wenn der Paketmanager den 16‑KB-Abwärtskompatibilitätsmodus für eine App aktiviert hat, wird beim ersten Starten der App eine Warnung angezeigt, dass sie im 16‑KB-Abwärtskompatibilitätsmodus ausgeführt wird.

Im 16‑KB-Abwärtskompatibilitätsmodus funktionieren einige Apps, aber für maximale Zuverlässigkeit und Stabilität sollten Apps mit 16 KB ausgerichtet sein.

Aktiviere oder deaktiviere auf der Seite mit den App-Informationen unter Erweitert die Einstellung App im Kompatibilitätsmodus für die Seitengröße ausführen, um den 16 KB-Abwärtskompatibilitätsmodus für eine bestimmte App zu aktivieren oder zu deaktivieren. Diese Einstellung ist nur sichtbar, wenn das Gerät mit einer 16 KB-Seitengröße ausgeführt wird.

Einstellung für den Kompatibilitätsmodus für die Seitengröße

So erzwingst du den 16‑KB-Abwärtskompatibilitätsmodus für alle Apps auf dem Gerät:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

So erzwingst du, dass der 16‑KB-Abwärtskompatibilitätsmodus für alle Apps auf dem Gerät deaktiviert wird:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

In Android 17 kannst du den 16‑KB-Abwärtskompatibilitätsmodus auch für alle Apps erzwingen und alle inkompatiblen Binärdateien sofort abbrechen:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

Setze die Property android:pageSizeCompat auf „aktiviert“ oder „deaktiviert“, um den Abwärtskompatibilitätsmodus für eine bestimmte App in der Datei AndroidManifest.xml zu aktivieren oder zu deaktivieren. Wenn diese Property festgelegt ist, werden beim Starten der App keine Warnungen zum Abwärtskompatibilitätsmodus angezeigt.