64-Bit-Architekturen unterstützen

Bei Google Play veröffentlichte Apps müssen 64-Bit-Architekturen unterstützen. Wenn Sie eine 64-Bit-Version Ihrer App hinzufügen, können Sie die Leistung verbessern und Ihre App für Geräte mit reiner 64-Bit-Hardware optimieren.

Mit den folgenden Schritten sorgen Sie dafür, dass Ihre 32-Bit-App 64-Bit-Geräte unterstützt.

App bewerten

Wenn in Ihrer App nur Code verwendet wird, der in der Programmiersprache Java oder Kotlin geschrieben wurde, einschließlich aller Bibliotheken oder SDKs, unterstützt Ihre App 64-Bit-Geräte. Wenn Ihre App nativen Code verwendet oder Sie sich nicht sicher sind, ob dies der Fall ist, sollten Sie Ihre App prüfen.

Schneller Statuscheck

Rufen Sie die Play Console auf und prüfen Sie, ob vorhandene Releases konform sind.

In der Play Console werden auch Warnungen für Ihre Release-Entwürfe angezeigt, wenn Probleme mit der 64-Bit-Anforderung auftreten. Das folgende Bild ist ein Beispiel.

Wenn eine Warnung angezeigt wird, folgen Sie der Anleitung unten, um Ihre App mit 64‑Bit-Geräten kompatibel zu machen.

Verwendet Ihre App nativen Code?

Ihre App verwendet nativen Code, wenn

• Ihre App verwendet C-/C++-Code (nativer Code).
• Verknüpfungen mit nativen Bibliotheken von Drittanbietern
• Sie wurde von einem Drittanbieter-App-Builder erstellt, der native Bibliotheken verwendet.

Enthält Ihre App 64-Bit-Bibliotheken?

Prüfen Sie die Struktur Ihrer APK-Datei. Beim Erstellen wird das APK mit allen nativen Bibliotheken verpackt, die von der App benötigt werden. Native Bibliotheken werden je nach ABI in verschiedenen Ordnern gespeichert. Es ist nicht erforderlich, jede 64-Bit-Architektur zu unterstützen. Für jede von Ihnen unterstützte native 32-Bit-Architektur muss jedoch die entsprechende 64-Bit-Architektur enthalten sein.

Bei der ARM-Architektur befinden sich die 32-Bit-Bibliotheken in armeabi-v7a. Die entsprechenden 64-Bit-Bibliotheken findest du in arm64-v8a.

Suchen Sie bei der x86-Architektur nach x86 für 32-Bit und x86_64 für 64-Bit.

Achten Sie darauf, dass sich in beiden Ordnern native Bibliotheken befinden. Zusammenfassung:

Je nach App befinden sich möglicherweise nicht in jedem Ordner genau dieselben Bibliotheken. Ziel ist es, dass Ihre App in einer reinen 64-Bit-Umgebung ordnungsgemäß ausgeführt wird.

Normalerweise enthält ein APK oder Bundle, das sowohl für 32-Bit- als auch für 64-Bit-Architekturen erstellt wurde, Ordner für beide ABIs, jeweils mit einer entsprechenden Reihe von nativen Bibliotheken. Wenn 64-Bit nicht unterstützt wird, wird möglicherweise ein Ordner für 32-Bit-ABI angezeigt, aber kein Ordner für 64-Bit.

Mit dem APK Analyzer nach nativen Bibliotheken suchen

Mit dem APK Analyzer können Sie verschiedene Aspekte eines erstellten APKs bewerten. Suchen Sie nach nativen Bibliotheken und prüfen Sie, ob 64-Bit-Bibliotheken vorhanden sind.

1. Öffnen Sie Android Studio und öffnen Sie ein beliebiges Projekt.

2. Wählen Sie im Menü Build > APK analysieren aus.

   

3. Wählen Sie das APK aus, das Sie bewerten möchten.

4. Suchen Sie im Ordner lib, in dem gegebenenfalls .so-Dateien gespeichert sind. Wenn keine vorhanden sind, unterstützt Ihre App 64-Bit-Geräte und Sie müssen nichts weiter tun. Wenn armeabi-v7a oder x86 angezeigt wird, haben Sie 32-Bit-Bibliotheken.

5. Prüfen Sie, ob Sie ähnliche .so-Dateien im Ordner arm64-v8a oder x86_64 haben.

   

6. Wenn Sie keine arm64-v8a- oder x86_64-Bibliotheken haben, aktualisieren Sie Ihren Build-Prozess, um diese Artefakte in Ihrem APK zu erstellen und zu verpacken.

7. Wenn Sie bereits sehen, dass beide Bibliotheken verpackt werden, können Sie mit dem Testen Ihrer App auf 64-Bit-Hardware fortfahren.

Nach nativen Bibliotheken suchen, indem APKs entpackt werden

APK-Dateien sind wie ZIP-Dateien strukturiert. Extrahieren Sie die APK-Datei mit der Befehlszeile oder einem anderen Extraktionstool. Je nach Extraktionstool müssen Sie die Datei möglicherweise in „.zip“ umbenennen.

Sehen Sie sich die extrahierten Dateien an und folgen Sie der Anleitung oben, um festzustellen, ob Ihre App 64‑Bit-Geräte unterstützt. Sie können den folgenden Befehl beispielsweise über die Befehlszeile ausführen:

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

In diesem Beispiel sind die Bibliotheken armeabi-v7a und arm64-v8a vorhanden. Das bedeutet, dass die App 64-Bit-Architekturen unterstützt.

App mit 64-Bit-Bibliotheken erstellen

In der folgenden Anleitung wird beschrieben, wie Sie 64-Bit-Bibliotheken erstellen. Hinweis: Diese Schritte gelten nur für Code und Bibliotheken, die Sie aus der Quelle erstellen können.

Mit Android Studio oder Gradle erstellen

Die meisten Android Studio-Projekte verwenden Gradle als zugrunde liegendes Build-System. Daher gilt dieser Abschnitt für beide Fälle. Wenn Sie Builds für Ihren nativen Code aktivieren möchten, fügen Sie der Einstellung ndk.abiFilters in der Datei „build.gradle“ Ihrer App je nach den zu unterstützenden Architekturen arm64-v8a und/oder x86_64 hinzu:

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

Mit CMake erstellen

Wenn Ihre App mit CMake erstellt wird, können Sie sie für 64-Bit-ABIs erstellen, indem Sie arm64-v8a an den Parameter „-DANDROID_ABI“ übergeben:

:: Command Line
> cmake -DANDROID_ABI=arm64-v8a … or
> cmake -DANDROID_ABI=x86_64 …

Mit ndk-build erstellen

Wenn Ihre App mit ndk-build erstellt wird, können Sie sie für 64-Bit-ABIs erstellen, indem Sie die Datei Application.mk mit der Variablen APP_ABI ändern:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

32-Bit-Code auf 64-Bit umstellen

Wenn Ihr Code bereits auf dem Computer oder iOS-Geräten ausgeführt wird, sollten Sie für Android keine zusätzlichen Arbeiten ausführen müssen. Wenn Ihr Code zum ersten Mal für ein 64‑Bit-System erstellt wird, müssen Sie vor allem darauf achten, dass Zeiger nicht mehr in 32‑Bit-Ganzzahltypen wie int passen.

Aktualisieren Sie Code, in dem Verweise in Typen wie int, unsigned oder uint32_t gespeichert werden. Unter Unix-Systemen entspricht long der Größe des Cursors, unter Windows ist das jedoch nicht der Fall. Verwenden Sie stattdessen die Typen uintptr_t oder intptr_t, die die Absicht offenlegen. Verwenden Sie den Typ ptrdiff_t, um den Unterschied zwischen zwei Zeiger zu speichern.

Sie sollten immer die in <stdint.h> definierten Ganzzahltypen mit fester Breite anstelle von Typen ohne feste Breite wie int oder long verwenden, auch bei Nicht-Pointern.

Mit den folgenden Compiler-Flags können Sie Fälle erkennen, in denen Ihr Code zwischen Pointern und Ganzzahlen falsch konvertiert wird:

-Werror=pointer-to-int-cast
-Werror=int-to-pointer-cast
-Werror=shorten-64-to-32

Java-Klassen mit int-Feldern, die Verweise auf C/C++-Objekte enthalten, haben das gleiche Problem. Suchen Sie in Ihrer JNI-Quelldatei nach jint und wechseln Sie auf der Java-Seite zu long und auf der C++-Seite zu jlong.

Implizite Funktionsdeklarationen sind für 64‑Bit-Code viel gefährlicher. In C/C++ wird davon ausgegangen, dass der Rückgabetyp einer implizit deklarierten Funktion (d. h. einer Funktion, für die der Compiler keine Deklaration gefunden hat) int ist. Wenn der tatsächliche Rückgabetyp Ihrer Funktion ein Zeiger ist, funktioniert dies auf einem 32-Bit-System einwandfrei, da der Zeiger in eine Ganzzahl passt. Auf einem 64-Bit-System verwirft der Compiler jedoch die obere Hälfte des Zeigers. Beispiel:

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

Mit dem folgenden Compiler-Flag werden Warnungen zu impliziten Funktionsdeklarationen in Fehler umgewandelt, damit Sie dieses Problem leichter finden und beheben können:

-Werror=implicit-function-declaration

Wenn Sie Inline-Assembler haben, schreiben Sie ihn neu oder verwenden Sie eine einfache C/C++-Implementierung.

Wenn Sie hartcodierte Größen von Typen haben (z. B. 8 oder 16 Byte), ersetzen Sie sie durch den entsprechenden sizeof(T)-Ausdruck, z. B. sizeof(void*).

Wenn Sie bedingt unterschiedliche Code für 32-Bit- und 64-Bit-Geräte kompilieren müssen, können Sie #if defined(__LP64__) für allgemeine 32/64-Unterschiede oder __arm__, __aarch64__ (arm64), __i386__ (x86) und __x86_64__ für die von Android unterstützten Architekturen verwenden.

Passen Sie Formatstrings für printf- oder scanf-ähnliche Funktionen an, da Sie mit den herkömmlichen Formatanweisungen keine 64-Bit-Typen so angeben können, dass sie sowohl für 32-Bit- als auch für 64-Bit-Geräte korrekt sind. Die Makros PRI und SCN in <inttypes.h> lösen dieses Problem. PRIxPTR und SCNxPTR dienen zum Schreiben und Lesen von Hexadezimalzeigern und PRId64 und SCNd64 zum plattformunabhängigen Schreiben und Lesen von 64‑Bit-Werten.

Beim Verschieben müssen Sie möglicherweise 1ULL verwenden, um eine 64‑Bit-Konstante zu erhalten, die verschoben werden soll, anstatt 1, das nur 32 Bit hat.

Größerhöhungen mit Android App Bundles abmildern

Wenn Sie Ihrer App die Unterstützung für 64-Bit-Architekturen hinzufügen, kann die APK-Größe zunehmen. Wir empfehlen Ihnen dringend, die Funktion Android App Bundle zu verwenden, um die Auswirkungen auf die Größe zu minimieren, die sich daraus ergeben, dass sowohl 32-Bit- als auch 64-Bit-nativer Code im selben APK enthalten ist.

Spieleentwickler

Die drei am häufigsten verwendeten Engines unterstützen 64-Bit:

• Unreal seit 2015
• Cocos2d seit 2015
• Unity seit 2018

Unity-Entwickler

Upgrade auf unterstützte Versionen ausführen

Unity bietet 64-Bit-Unterstützung mit den Versionen 2018.2 und 2017.4.16.

Wenn Sie eine Version von Unity verwenden, die keine 64-Bit-Unterstützung bietet, ermitteln Sie die Version, auf die Sie ein Upgrade durchführen möchten, und folgen Sie der Anleitung von Unity zur Migration Ihrer Umgebung. Achten Sie darauf, dass Ihre App auf eine Version umgestellt wird, mit der 64-Bit-Bibliotheken erstellt werden können. Unity empfiehlt, auf die neuesten Funktionen und Updates zuzugreifen, indem Sie auf die neueste LTS-Version des Editors aktualisieren.

In diesem Diagramm sind die verschiedenen Unity-Versionen und die entsprechenden Maßnahmen aufgeführt:

Build-Einstellungen ändern, um 64-Bit-Bibliotheken auszugeben

Wenn Sie eine Version von Unity verwenden, die 64-Bit-Android-Bibliotheken unterstützt, können Sie eine 64-Bit-Version Ihrer App generieren, indem Sie Ihre Build-Einstellungen anpassen. Verwenden Sie das IL2CPP-Backend als Scripting-Backend. So richten Sie Ihr Unity-Projekt für die Erstellung einer 64-Bit-Architektur ein:

1. Rufen Sie die Build-Einstellungen auf und prüfen Sie, ob Sie ein Android-Build erstellen. Das Unity-Symbol muss unter Plattform neben Android angezeigt werden. 1. Wenn das Unity-Symbol nicht neben der Android-Plattform angezeigt wird, wählen Sie Android aus und klicken Sie auf Plattform wechseln.

2. Klicke auf Player-Einstellungen.

   

3. Gehe zu Player-Einstellungspanel > Einstellungen für Android > Sonstige Einstellungen > Konfiguration.

4. Legen Sie für Scripting-Backend die Option IL2CPP fest.

5. Klicken Sie das Kästchen Zielarchitektur > ARM64 an.

   

6. Bauen Sie wie gewohnt weiter.

Hinweis: Wenn Sie für ARM64-Geräte erstellen möchten, müssen alle Ihre Assets speziell für diese Plattform erstellt werden. Folgen Sie der Anleitung von Unity zum Verringern der APK-Größe und nutzen Sie gegebenenfalls die Funktion Android App Bundle, um diese Größenzunahme zu verringern.

Mehrfach-APK und 64-Bit-Compliance

Wenn Sie die Unterstützung für mehrere APKs von Google Play nutzen, um Ihre App zu veröffentlichen, wird die Einhaltung der 64-Bit-Anforderung auf Release-Ebene geprüft. Die 64-Bit-Anforderung gilt jedoch nicht für APKs oder App-Bundles, die nicht auf Geräten mit Android 9 Pie oder höher verteilt werden.

Wenn eines Ihrer APKs als nicht konform gekennzeichnet ist, aber eine ältere Version ist und es nicht möglich ist, es konform zu machen, können Sie im Manifest dieses APKs dem Element uses-sdk das Attribut maxSdkVersion="27" hinzufügen. Diese APK wird nicht an Geräte mit Android 9 Pie oder höher ausgeliefert und verhindert nicht mehr die Einhaltung der Richtlinien.

RenderScript und 64-Bit-Kompatibilität

Wenn Ihre App RenderScript verwendet und mit einer älteren Version der Android-Tools erstellt wurde, treten möglicherweise Probleme mit der 64-Bit-Kompatibilität auf. Bei Build-Tools vor Version 21.0.0 generiert der Compiler möglicherweise Bitcode in einer externen .bc-Datei. Diese älteren .bc-Dateien werden für 64-Bit-Architekturen nicht mehr unterstützt. Daher führt die Datei in Ihrem APK zu einem Compliance-Problem.

Entfernen Sie alle .bc-Dateien aus Ihrem Projekt, aktualisieren Sie Ihre Umgebung auf build-tools-21.0.0 oder höher und legen Sie in Android Studio für renderscriptTargetApi die Version 21 oder höher fest, damit der Compiler keine .bc-Dateien generiert. Erstellen Sie dann Ihre App neu, prüfen Sie sie auf .bc-Dateien und laden Sie sie in die Play Console hoch.

App auf 64-Bit-Hardware testen

Die 64-Bit-Version Ihrer App sollte dieselbe Qualität und Ausstattung wie die 32-Bit-Version bieten. Testen Sie Ihre App, um sicherzustellen, dass Nutzer auf den neuesten 64-Bit-Geräten Ihre App optimal nutzen können.

Nur 64-Bit-Geräte

Wir empfehlen, Ihre App nach Möglichkeit in einer reinen 64-Bit-Umgebung mit einer der folgenden Optionen zu testen:

• Google Pixel mit einem 64‑Bit-System-Image
• Android-Emulator

Google Pixel mit einem reinen 64-Bit-System-Image

Um die App-Entwicklung und -Tests zu erleichtern, haben wir für einige Pixel-Geräte spezielle Systemabbilder mit einer strikten 64-Bit-Umgebung bereitgestellt. Diese 64-Bit-Images wurden ursprünglich gleichzeitig mit den Standard-System-Images für die Android 13- und 14-Preview-Releases bereitgestellt. Sie können sie jedoch weiterhin verwenden, wenn Sie Ihre App auf 64-Bit-Kompatibilität testen.

Nur 64-Bit-Image abrufen

Ähnlich wie bei den System-Images aus der Fabrik können Sie ein reines 64-Bit-Image mit dem Android-Flash-Tool oder durch manuelles Flashen des Geräts auf Ihr Gerät aufspielen. Weitere Informationen finden Sie in den folgenden Abschnitten.

Gerät mit dem Android Flash Tool flashen

Mit dem Android Flash Tool können Sie ein System-Image sicher auf Ihr unterstütztes Pixel-Gerät flashen. Das Android Flash Tool funktioniert mit jedem Webbrowser, der WebUSB unterstützt, z. B. Chrome oder Edge 79 oder höher.

Das Android Flash Tool führt Sie Schritt für Schritt durch das Flashen Ihres Geräts. Es sind keine Tools erforderlich. Sie müssen jedoch Ihr Gerät entsperren und das USB-Debugging in den Entwickleroptionen aktivieren. Eine vollständige Anleitung finden Sie in der Dokumentation zum Android-Flash-Tool.

Verbinden Sie Ihr Gerät über USB und rufen Sie je nach Art des System-Images, das Sie flashen möchten, über einen der folgenden Links das Android-Flash-Tool auf und folgen Sie der Anleitung auf dem Bildschirm:

• Nur 64-Bit-Systemimages für Android 14 (Beta 5.2)

  Wählen Sie das Gerät aus, das Sie flashen möchten:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

• Nur 64-Bit-Systemimages für Android 13 (QPR3 Beta 3.2)

  Wählen Sie das Gerät aus, das Sie flashen möchten:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

Gerät manuell flashen

Sie können auch das neueste System-Image herunterladen und manuell auf Ihr Gerät flashen. In der folgenden Tabelle finden Sie Informationen zum Herunterladen des System-Images für Ihr Testgerät. Das manuelle Flashen eines Geräts ist nützlich, wenn Sie die Testumgebung genau steuern oder häufig neu installieren müssen, z. B. bei automatisierten Tests.

Nachdem Sie Ihre Gerätedaten gesichert und das entsprechende System-Image heruntergeladen haben, können Sie das Image auf Ihr Gerät aufspielen.

Sie können jederzeit zum aktuellen öffentlichen Build zurückkehren.

Nur 64-Bit-Images für Android 14 (Beta 5.3)

Diese Images bieten eine reine 64-Bit-Umgebung zum Testen der Kompatibilität von 64-Bit-Apps. Diese 64-Bit-Konfigurationen sind nur für Entwickler gedacht.

Nur 64-Bit-Betriebssystem-Images für Android 13 (QPR3 Beta 3.2)

Diese Images bieten eine reine 64-Bit-Umgebung zum Testen der Kompatibilität von 64-Bit-Apps. Diese 64-Bit-Konfigurationen sind nur für Entwickler gedacht.

Zu einem öffentlichen Build zurückkehren

Sie können entweder das Android-Flash-Tool verwenden, um das Factory Image zu flashen, oder ein System-Image mit den Werksspezifikationen auf der Seite Factory Images für Nexus- und Pixel-Geräte herunterladen und dann manuell auf das Gerät flashen.

Android-Emulator

Ab Android 12 (API-Level 31) sind Android Emulator-Systemimages nur noch 64-Bit. Erstellen Sie ein virtuelles Android-Gerät (AVD) mit einem System-Image mit Android 12 (API-Level 31) oder höher, um eine reine 64-Bit-Umgebung für App-Tests zu erhalten.

Weitere Geräteoptionen

Wenn Sie keines dieser Geräte haben oder den Android-Emulator nicht verwenden können, ist die beste Alternative ein 64-Bit-fähiges Gerät wie Google Pixel oder andere aktuelle Flaggschiffe anderer Gerätehersteller.

App installieren und testen

Am einfachsten testen Sie Ihr APK, indem Sie die App mit Android Debug Bridge (adb) installieren. In den meisten Fällen können Sie --abi als Parameter angeben, um anzugeben, welche Bibliotheken auf dem Gerät installiert werden sollen. Dadurch wird die App nur mit den 64-Bit-Bibliotheken auf dem Gerät installiert.

:: Command Line
# A successful install:
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# If your APK does not have the 64-bit libraries:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# If your device does not support 64-bit, an emulator, for example:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

Testen Sie Ihre App nach der erfolgreichen Installation wie gewohnt, um sicherzustellen, dass die Qualität der 64-Bit-Version entspricht.

Nach bekannten Kompatibilitätsproblemen suchen

Prüfen Sie bei den Tests, ob Ihre App die folgenden Probleme aufweist, die sich auf Apps auswirken, die auf 64-Bit-Geräten ausgeführt werden. Selbst wenn Ihre App nicht direkt von den betroffenen Bibliotheken abhängt, kann dies für Drittanbieterbibliotheken und ‑SDKs in den Abhängigkeiten Ihrer App der Fall sein.

SoLoader

Wenn Sie das Native Code Loader SDK SoLoader verwenden, aktualisieren Sie es auf Version 0.10.4 oder höher. Wenn Ihre App SDKs verwendet, die von SoLoader abhängen, müssen Sie auch die betroffenen SDKs auf die neueste stabile Version aktualisieren.

Bei SoLoader v0.9.0 und niedriger wird davon ausgegangen, dass Systembibliotheken in /vendor/lib:/system/lib vorhanden sind. Dieser Fehler tritt auf Geräten wie Google Pixel 7 nicht auf, da der Pfad dort vorhanden ist. Auf Geräten, auf denen sich nur Systembibliotheken in /vendor/lib64:/system/lib64 befinden, führt diese Annahme jedoch zu Abstürzen.

Weitere Informationen zur Behebung dieses und anderer Probleme, die durch SoLoader verursacht werden, finden Sie in der entsprechenden Antwort in der Google-Hilfe.

OpenSSL

Wenn Sie die OpenSSL-Bibliothek verwenden, aktualisieren Sie sie auf OpenSSL 1.1.1i oder höher. Wenn Ihre App SDKs verwendet, die die Kommunikation über HTTPS ermöglichen, oder andere SDKs, die von OpenSSL abhängen, aktualisieren Sie auch auf die neueste Version des SDKs, die eine neuere OpenSSL-Version verwendet. Wenden Sie sich an den SDK-Anbieter, falls keiner verfügbar ist.

ARMv8.3 PAC ermöglicht die hardwaregestützte Kontrollflussintegrität durch die Authentifizierung von Zeigern zur Laufzeit. Frühere OpenSSL-Versionen verwenden diese Funktionen nicht richtig, was zu Laufzeitabstürzen auf allen Geräten mit Prozessoren auf Basis von ARMv8.3a und höher führt.

Weitere Informationen zur Behebung dieses und anderer durch OpenSSL verursachter Probleme finden Sie in der entsprechenden Antwort in der Google-Hilfe.

BTI

ARMv8.5 und höher verwenden Branch Target Instructions (BTIs), um vor JOP-Angriffen zu schützen. Frühere Versionen von Obfuscation-SDKs, die zu zufälligen Abweichungen von Bibliotheken führen, die mit BTI erstellt wurden, können zu Abstürzen von Apps führen. Da die Anweisungen als HINTs codiert sind, ist dieser Fehler auf Geräten, die BTI nicht unterstützen, nicht zu beobachten.

Veröffentlichen

Wenn Sie der Meinung sind, dass Ihre App fertig ist, veröffentlichen Sie sie wie gewohnt. Beachten Sie wie immer die Best Practices für die Bereitstellung Ihrer App. Wir empfehlen Ihnen, geschlossene Test-Tracks zu nutzen, um die App für eine begrenzte Anzahl von Nutzern bereitzustellen und so für eine gleichbleibende Qualität zu sorgen.

Wie bei der Einführung eines größeren Updates sollten Sie die Funktion gründlich auf 64-Bit-fähigen Geräten testen, bevor Sie sie für eine größere Zielgruppe veröffentlichen.