64-Bit-Architekturen unterstützen

Apps, die bei Google Play veröffentlicht werden, müssen 64-Bit-Architekturen unterstützen. Durch das Hinzufügen einer 64-Bit-Version deiner App wird die Leistung verbessert und du kannst Geräte mit Nur-64-Bit-Hardware nutzen.

Anhand der folgenden Schritte wird sichergestellt, dass Ihre 32-Bit-App 64-Bit-Geräte unterstützt.

App bewerten

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

Schnelle Statusüberprüfung

Rufe die Play Console auf und sieh dir die vorhandenen Releases an, um zu prüfen, ob sie konform sind.

In der Play Console werden auch Warnungen für deine Release-Entwürfe angezeigt, wenn Probleme im Zusammenhang mit der 64-Bit-Anforderung auftreten. Hier sehen Sie ein Beispiel.

Wenn eine Warnung angezeigt wird, führe die folgenden Schritte aus, um deine App mit 64-Bit-Geräten kompatibel zu machen.

Verwendet Ihre App nativen Code?

Ihre App verwendet nativen Code, wenn:

• Verwendet beliebigen (nativen) C-/C++-Code in Ihrer App.
• Verknüpfungen mit nativen Bibliotheken von Drittanbietern
• Sie wird von einem Drittanbieter-App-Builder erstellt, der native Bibliotheken verwendet.

Enthält deine App 64-Bit-Bibliotheken?

Überprü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 gemäß ABI in verschiedenen Ordnern gespeichert. Sie muss nicht jede 64-Bit-Architektur unterstützen, aber für jede native 32-Bit-Architektur, die Sie unterstützen, müssen Sie die entsprechende 64-Bit-Architektur einbinden.

Für die ARM-Architektur befinden sich die 32-Bit-Bibliotheken in armeabi-v7a. Die 64-Bit-Entsprechung ist arm64-v8a.

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

Achten Sie darauf, dass in beiden Ordnern native Bibliotheken vorhanden sind. Hier noch einmal zusammengefasst:

Beachten Sie, dass je nach Anwendung in jedem Ordner der gleiche Satz von Bibliotheken vorhanden sein kann oder nicht. Das Ziel besteht darin, Ihre Anwendung in einer reinen 64-Bit-Umgebung ordnungsgemäß auszuführen.

In einem typischen Fall hat ein APK oder Bundle, das sowohl für 32-Bit- als auch für 64-Bit-Architekturen erstellt wurde, Ordner für beide ABIs mit jeweils einem entsprechenden Satz nativer Bibliotheken. Wenn 64-Bit nicht unterstützt werden, sehen Sie möglicherweise einen 32-Bit-ABI-Ordner, aber keinen 64-Bit-Ordner.

Mit APK Analyzer nach nativen Bibliotheken suchen

APK Analyzer ist ein Tool, mit dem Sie verschiedene Aspekte eines erstellten APKs bewerten können. Damit können Sie native Bibliotheken finden und dafür sorgen, dass 64-Bit-Bibliotheken vorhanden sind.

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

2. Wählen Sie im Menü Build > Analyze APK (Erstellen > APK analysieren...) aus.

   

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

4. Sehen Sie im Ordner lib nach, in dem ggf. „.so“-Dateien gehostet werden. Falls keine vorhanden sind, unterstützt deine App 64-Bit-Geräte und du musst nichts weiter tun. Wenn Sie armeabi-v7a oder x86 sehen, haben Sie 32-Bit-Bibliotheken.

5. Prüfen Sie, ob sich im Ordner arm64-v8a oder x86_64 ähnliche SO-Dateien befinden.

   

6. Wenn Sie keine arm64-v8a- oder x86_64-Bibliotheken haben, aktualisieren Sie Ihren Build-Prozess, um mit dem Erstellen und Packen dieser Artefakte in Ihrem APK zu beginnen.

7. Wenn bereits beide Bibliotheken gepackt sind, können Sie mit dem Testen Ihrer App auf 64-Bit-Hardware fortfahren.

Native Bibliotheken durch Entpacken von APKs suchen

APK-Dateien sind wie ZIP-Dateien aufgebaut. 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.

Suchen Sie die extrahierten Dateien. Folgen Sie dazu der obigen Anleitung, um festzustellen, ob Ihre App 64-Bit-Geräte unterstützt. Sie können das folgende Befehlsbeispiel ü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 Anwendung 64-Bit-Architekturen unterstützt.

Apps mit 64-Bit-Bibliotheken erstellen

In der folgenden Anleitung wird beschrieben, wie Sie 64-Bit-Bibliotheken erstellen. Diese Schritte beziehen sich nur auf das Erstellen von Code und Bibliotheken, die Sie aus dem Quellcode erstellen können.

Mit Android Studio oder Gradle entwickeln

In den meisten Android Studio-Projekten wird Gradle als zugrunde liegendes Build-System verwendet. Daher gilt dieser Abschnitt für beide Fälle. Um Builds für Ihren nativen Code zu aktivieren, fügen Sie der Einstellung ndk.abiFilters in der Datei „build.gradle“ Ihrer App je nach der zu unterstützenden Architektur 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 entwickeln

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

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

Mit ndk-build erstellen

Wenn Ihre Anwendung mit ndk-build erstellt wurde, können Sie für 64-Bit-ABIs erstellen. Modifizieren Sie dazu die Datei „Application.mk“ mit der Variablen APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Port des 32-Bit-Codes auf 64-Bit

Wenn Ihr Code bereits auf dem Desktop oder unter iOS ausgeführt wird, müssen Sie für Android normalerweise keine zusätzlichen Schritte ausführen. Wenn Sie Ihren Code zum ersten Mal für ein 64-Bit-System erstellen, müssen Sie sich hauptsächlich damit befassen, dass Zeiger nicht mehr in 32-Bit-Ganzzahlentypen wie int passen.

Aktualisieren Sie den Code, mit dem Zeiger in Typen wie int, unsigned oder uint32_t gespeichert werden. Auf Unix-Systemen entspricht long der Zeigergröße, was unter Windows jedoch nicht der Fall ist. Verwende stattdessen die Typen uintptr_t oder intptr_t, um die Absicht zu erkennen. Verwenden Sie den Typ ptrdiff_t, um die Differenz zwischen zwei Zeigern zu speichern.

Sie sollten immer die spezifischen Ganzzahltypen mit fester Breite, die in <stdint.h> definiert sind, gegenüber Typen ohne feste Breite wie int oder long bevorzugen. Das gilt auch für Nicht-Zeiger.

Verwenden Sie die folgenden Compiler-Flags, um Fälle zu erfassen, in denen Ihr Code fälschlicherweise zwischen Zeigern und Ganzzahlen konvertiert wird:

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

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

Implizite Funktionsdeklarationen sind für 64-Bit-Code wesentlich 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 gesehen hat) int ist. Wenn der tatsächliche Rückgabetyp Ihrer Funktion ein Zeiger ist, funktioniert dies problemlos auf einem 32-Bit-System, in dem der Zeiger in eine Ganzzahl passt. Auf einem 64-Bit-System löscht der Compiler jedoch die obere Hälfte des Zeigers. Beispiele:

// 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`.

Das folgende Compiler-Flag wandelt implizite Warnungen zur Funktionsdeklaration in Fehler um, damit Sie das Problem leichter finden und beheben können:

-Werror=implicit-function-declaration

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

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

Wenn Sie bedingten Code für 32-Bit- als 64-Bit-Versionen 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 es bei herkömmlichen Formatspezifizierern nicht möglich ist, 64-Bit-Typen sowohl für 32-Bit- als auch für 64-Bit-Geräte korrekt anzugeben. Die Makros PRI und SCN in <inttypes.h> lösen dieses Problem, PRIxPTR und SCNxPTR zum Schreiben und Lesen von Hexadezimalzeigern sowie PRId64 und SCNd64 zum Portieren und Lesen von 64-Bit-Werten.

Beim Verschieben müssen Sie möglicherweise 1ULL verwenden, um eine 64-Bit-Konstante für die Verschiebung zu erhalten, anstatt 1, das nur 32 Bit umfasst.

Mit Android App Bundle Größenanstiege verringern

Wenn du deiner App die Unterstützung für 64-Bit-Architekturen hinzufügst, kann die APK-Größe zunehmen. Wir empfehlen dringend, das Android App Bundle zu nutzen, um die Auswirkungen auf die Größe, die durch die Aufnahme von nativem 32- und 64-Bit-Code in dasselbe APK, minimiert werden.

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 leistungsstarke Versionen durchführen

Unity bietet 64-Bit-Unterstützung für die Versionen 2018.2 und 2017.4.16.

Wenn Sie eine Version von Unity verwenden, die 64-Bit nicht unterstützt, ermitteln Sie die Version, auf die Sie upgraden möchten, und folgen Sie den Anleitungen von Unity zum Migrieren Ihrer Umgebung. Sorgen Sie dafür, dass Ihre Anwendung auf eine Version aktualisiert wird, die 64-Bit-Bibliotheken erstellen kann. Unity empfiehlt, Zugriff auf die neuesten Features und Updates zu erhalten. Führen Sie dazu ein Upgrade auf die neueste Langzeitsupport-Version des Editors durch.

Das folgende Diagramm veranschaulicht die verschiedenen Unity-Versionen und was Sie tun sollten:

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-Back-End als Scripting-Back-End. So richten Sie Ihr Unity-Projekt für das Erstellen einer 64-Bit-Architektur ein:

1. Rufe Build Settings (Build-Einstellungen) auf und entwickle Inhalte für Android. Das Unity-Symbol muss sich unter Platform (Plattform) neben Android befinden. 1. Wenn sich das Unity-Symbol nicht neben der Android-Plattform befindet, wählen Sie Android aus und klicken Sie auf Plattform wechseln.

2. Klicken Sie auf Playereinstellungen.

   

3. Gehe zu Bereich "Player Settings" (Playereinstellungen) > Einstellungen für Android > Weitere Einstellungen > "Configuration" (Konfiguration).

4. Setzen Sie Scripting-Back-End auf IL2CPP.

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

   

6. Baue wie gewohnt!

Für ARM64 müssen alle Assets speziell für diese Plattform erstellt werden. Folgen Sie den Hinweisen von Unity zum Reduzieren der APK-Größe. Nutzen Sie gegebenenfalls die Funktion Android App Bundle, um diese Größe zu minimieren.

Multi-APK und 64-Bit-Compliance

Wenn Sie zum Veröffentlichen Ihrer App die Unterstützung für mehrere APKs von Google Play nutzen, 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 vertrieben werden.

Wenn eines Ihrer APKs als nicht konform gekennzeichnet ist, es sich aber um eine ältere Version handelt und es nicht möglich ist, den Verstoß zu beheben, können Sie dem Element uses-sdk im Manifest dieses APKs ein maxSdkVersion="27"-Attribut hinzufügen. Dieses APK wird nicht an Geräte mit Android 9 Pie oder höher bereitgestellt und blockiert nicht mehr die Konformität.

RenderScript und 64-Bit-Compliance

Wenn Ihre App RenderScript verwendet und mit einer früheren Version der Android-Tools erstellt wurde, treten möglicherweise Probleme mit der 64-Bit-Compliance für die App auf. Bei Build-Tools vor Version 21.0.0 generiert der Compiler möglicherweise Bitcode in eine externe .bc-Datei. Diese Legacy-.bc-Dateien werden für 64-Bit-Architekturen nicht mehr unterstützt. Wenn die Datei in Ihrem APK vorhanden ist, verursacht sie also ein Complianceproblem.

Entfernen Sie zum Beheben des Problems alle .bc-Dateien in Ihrem Projekt, führen Sie ein Upgrade Ihrer Umgebung auf build-tools-21.0.0 oder höher aus und setzen Sie renderscriptTargetApi in Android Studio auf 21 oder höher, damit der Compiler keine .bc-Dateien ausgeben soll. Erstellen Sie dann Ihre App neu, suchen Sie nach .bc-Dateien und laden Sie sie in die Play Console hoch.

Apps auf 64-Bit-Hardware testen

Die 64-Bit-Version deiner App sollte dieselbe Qualität und denselben Funktionsumfang wie die 32-Bit-Version bieten. Testen Sie Ihre App, um dafür zu sorgen, dass die App auch auf den neuesten 64-Bit-Geräten optimal funktioniert.

64-Bit-Geräte

Testen Sie Ihre Anwendung nach Möglichkeit in einer strikten 64-Bit-Umgebung mit einer der folgenden Optionen:

• Google Pixel mit einem Nur-64-Bit-Systemimage
• Android-Emulator

Google Pixel mit einem 64-Bit-Systemimage

Um die Entwicklung und Tests von Apps zu erleichtern, stellen wir für einige Pixel-Geräte spezielle System-Images mit einer strikten 64-Bit-Umgebung zur Verfügung. Diese reinen 64-Bit-Images wurden ursprünglich gleichzeitig mit den Standard-Werksystem-Images für die Vorabversionen von Android 13 und 14 zur Verfügung gestellt. Sie können sie aber weiterhin verwenden, wenn Sie Ihre App auf 64-Bit-Kompatibilität testen.

Nur 64-Bit-Bild herunterladen

Ähnlich wie bei werkseitigen System-Images können Sie mit dem Android Flash Tool oder durch manuelles Flashen des Geräts ein Nur-64-Bit-Image auf Ihr Gerät flashen. Eine Anleitung hierzu finden Sie in den folgenden Abschnitten.

Gerät mit dem Android Flash Tool flashen

Mit dem Android Flash Tool kannst du ein Systemimage sicher auf dein unterstütztes Pixel-Gerät flashen. Das Android Flash Tool funktioniert mit jedem Webbrowser, der WebUSB unterstützt, wie Chrome oder Edge 79+.

Das Android Flash-Tool führt Sie Schritt für Schritt durch den Flash-Prozess Ihres Geräts. Es müssen keine Tools installiert sein. 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.

Verbinde dein Gerät über USB. Navigiere dann abhängig von der Art des System-Images, das du blinken möchtest, über einen der folgenden Links zum Android Flash Tool und folge der Anleitung auf dem Bildschirm:

• Android 14 (Beta 5.2) 64-Bit-System-Images

  Wähle das Gerät aus, für das du den Blitz aktivieren möchtest:

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

• 64-Bit-Systemimages von Android 13 (QPR3 Beta 3.2)

  Wähle das Gerät aus, für das du den Blitz aktivieren möchtest:

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

Manuelles Flashen des Geräts

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

Nachdem du deine Gerätedaten gesichert und das entsprechende Systemimage heruntergeladen hast, kannst du das Bild auf dein Gerät flashen.

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

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

Diese Images bieten eine strikte 64-Bit-Umgebung zum Testen der 64-Bit-Kompatibilität von Anwendungen. Diese 64-Bit-Konfigurationen sind nur für Entwickler bestimmt.

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

Diese Images bieten eine strikte 64-Bit-Umgebung zum Testen der 64-Bit-Kompatibilität von Anwendungen. Diese 64-Bit-Konfigurationen sind nur für Entwickler bestimmt.

Zu einem öffentlichen Build zurückkehren

Sie können entweder das Android Flash Tool verwenden, um das Factory Image zu flashen, oder ein werksspezifische Systemimage von der Seite Factory Images for Nexus and Pixel Devices herunterladen und es dann manuell auf das Gerät flashen.

Android-Emulator

Ab Android 12 (API-Level 31) sind die Systemimages des Android Emulators nur noch 64-Bit verfügbar. Erstellen Sie ein virtuelles Android-Gerät mit einem System-Image mit Android 12 (API-Level 31) oder höher, um eine strikte 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, sollten Sie ein 64-Bit-fähiges Gerät verwenden, z. B. ein Google Pixel oder andere aktuelle Flagship-Geräte anderer Gerätehersteller.

App installieren und testen

Am einfachsten können Sie Ihr APK testen, indem Sie die App mit der 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

Teste deine App nach der Installation wie gewohnt, um sicherzustellen, dass die Qualität der 32-Bit-Version entspricht.

Auf bekannte Kompatibilitätsprobleme prüfen

Prüfe deine App beim Testen auf die folgenden Probleme, die sich auf Apps auf 64-Bit-Geräten auswirken. Auch wenn Ihre Anwendung nicht direkt von den betroffenen Bibliotheken abhängig ist, können in den Abhängigkeiten Ihrer App Bibliotheken und SDKs von Drittanbietern enthalten sein.

SoLoader

Wenn Sie das native Codeladeprogramm-SDK SoLoader verwenden, führen Sie ein Update auf Version 0.10.4 oder höher durch. Wenn deine App SDKs verwendet, die von SoLoader abhängig sind, muss außerdem ein Update auf die neueste stabile Version der betroffenen SDKs durchgeführt werden.

Bei SoLoader 0.9.0 und niedriger wird davon ausgegangen, dass Systembibliotheken in /vendor/lib:/system/lib vorhanden sind. Auf Geräten wie Pixel 7, auf denen der Pfad existiert, kann dieser Fehler nicht beobachtet werden. Diese Annahme führt jedoch zu Abstürzen bei Geräten, die nur Systembibliotheken in /vendor/lib64:/system/lib64 haben.

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

OpenSSL

Wenn Sie die OpenSSL-Bibliothek verwenden, führen Sie ein Update auf OpenSSL 1.1.1i oder höher durch. Wenn Ihre App SDKs für die Kommunikation über HTTPS oder andere von OpenSSL abhängige SDKs verwendet, muss sie auf die neueste Version des SDKs aktualisiert werden, die eine neuere OpenSSL-Version verwendet. Wenn kein SDK-Anbieter verfügbar ist, wenden Sie sich an den Anbieter.

ARMv8.3 PAC aktiviert hardwaregestützte Integrität des Steuerflusses, indem Zeiger zur Laufzeit authentifiziert werden. Frühere Versionen von OpenSSL verwenden diese Funktionen falsch, was zu Laufzeitabstürzen auf allen Geräten mit Prozessoren führt, die auf ARMv8.3a und höher basieren.

Weitere Informationen zur Behebung dieses Problems 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 sich vor JOP-Angriffen zu schützen. Frühere Versionen von Verschleierungs-SDKs, die sich in zufälligen Offsets von Bibliotheken verzweigen, die mit BTI erstellt wurden, können zum Absturz von Anwendungen führen. Da die Anweisungen als HINTs codiert sind, lässt sich dieser Fehler bei Geräten, die BTI nicht unterstützen, nicht beobachten.

Veröffentlichen

Wenn du der Meinung bist, dass deine App bereit ist, veröffentliche sie wie gewohnt. Halte dich wie immer an die Best Practices für die Bereitstellung deiner App. Wir empfehlen, geschlossene Test-Tracks zu nutzen, um sie für eine begrenzte Anzahl von Nutzern einzuführen, um für eine konsistente Qualität deiner App zu sorgen.

Wie bei der Einführung eines großen Updates sollten Sie vor der Veröffentlichung für ein größeres Publikum gründlich auf 64-Bit-fähigen Geräten getestet werden.