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 sich auf Geräte mit reiner 64‑Bit-Hardware vorbereiten.

Mit den folgenden Schritten stellen Sie sicher, dass Ihre 32‑Bit-App 64‑Bit-Geräte unterstützt.

App bewerten

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

Schnelle Statusprüfung

Rufen Sie die Play Console auf und sehen Sie sich vorhandene Releases an, um festzustellen, ob sie den Richtlinien entsprechen.

In der Play Console werden auch Warnungen für Ihre Release-Entwürfe angezeigt, wenn es Probleme mit der 64‑Bit-Anforderung gibt. Die folgende Abbildung zeigt ein Beispiel.

Wenn eine Benachrichtigung 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 sie

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

Enthält Ihre App 64‑Bit-Bibliotheken?

Sehen Sie sich die Struktur Ihrer APK-Datei an. Beim Erstellen des APKs werden alle nativen Bibliotheken, die für die App erforderlich sind, in das Paket aufgenommen. Native Bibliotheken werden in verschiedenen Ordnern basierend auf der ABI gespeichert. Es ist nicht erforderlich, jede 64-Bit-Architektur zu unterstützen. Für jede native 32-Bit-Architektur, die Sie unterstützen, müssen Sie jedoch die entsprechende 64-Bit-Architektur anbieten.

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

Bei der x86-Architektur suchen Sie nach x86 für 32-Bit und nach x86_64 für 64-Bit.

Prüfen Sie, ob in beiden Ordnern native Bibliotheken vorhanden sind. Zusammenfassung:

Je nach App ist in den einzelnen Ordnern möglicherweise nicht genau derselbe Satz von Bibliotheken enthalten. Ziel ist es, dass Ihre App in einer reinen 64-Bit-Umgebung korrekt ausgeführt wird.

In einem typischen Fall 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 mit jeweils einem entsprechenden Satz nativer Bibliotheken. Wenn keine Unterstützung für 64‑Bit vorhanden ist, sehen Sie möglicherweise einen 32‑Bit-ABI-Ordner, aber keinen 64‑Bit-Ordner.

Mit dem APK Analyzer nach nativen Bibliotheken suchen

Mit dem APK Analyzer können Sie verschiedene Aspekte eines erstellten APKs analysieren. Damit können Sie native Bibliotheken finden und prüfen, ob 64‑Bit-Bibliotheken vorhanden sind.

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

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

   

3. Wählen Sie die APK aus, die Sie auswerten möchten.

4. Suchen Sie im Ordner lib nach „.so“-Dateien. 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.

Native Bibliotheken durch Entzippen von APKs finden

APK-Dateien sind wie ZIP-Dateien strukturiert. Extrahieren Sie die APK-Datei über die Befehlszeile oder ein anderes 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 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 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: In diesen Schritten wird nur das Erstellen von Code und Bibliotheken behandelt, die Sie aus dem Quellcode erstellen können.

Mit Android Studio oder Gradle erstellen

Die meisten Android Studio-Projekte verwenden Gradle als zugrunde liegendes Build-System. Dieser Abschnitt gilt also 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 arm64-v8a und/oder x86_64 hinzu, je nachdem, welche Architekturen Sie unterstützen möchten:

// 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 wurde, 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 zu 64-Bit-Code portieren

Wenn Ihr Code bereits auf dem Computer oder unter iOS ausgeführt wird, sollten Sie für Android keine zusätzlichen Schritte ausführen müssen. Wenn Ihr Code zum ersten Mal für ein 64‑Bit-System erstellt wird, besteht das Hauptproblem darin, dass Zeiger nicht mehr in 32‑Bit-Ganzzahltypen wie int passen.

Aktualisieren Sie den Code, in dem Zeiger in Typen wie int, unsigned oder uint32_t gespeichert werden. Auf Unix-Systemen entspricht long der Zeigergröße, auf Windows-Systemen jedoch nicht. Verwenden Sie stattdessen die aussagekräftigen Typen uintptr_t oder intptr_t. Um die Differenz zwischen zwei Zeigern zu speichern, verwenden Sie den Typ ptrdiff_t.

Sie sollten immer die spezifischen, Integer-Typen mit fester Breite, die in <stdint.h> definiert sind, anstelle von Typen ohne feste Breite wie int oder long verwenden, auch für Nicht-Pointer.

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

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

Java-Klassen mit int-Feldern, die Zeiger auf C/C++-Objekte enthalten, haben dasselbe Problem. Suchen Sie in Ihrem JNI-Quellcode nach jint und stellen Sie sicher, dass Sie auf der Java-Seite zu long und auf der C++-Seite zu jlong wechseln.

Implizite Funktionsdeklarationen sind für 64-Bit-Code viel gefährlicher. Bei 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 auf einem 32-Bit-System, auf dem Ihr Zeiger in einen int passt. Auf einem 64-Bit-System verwirft der Compiler jedoch die obere Hälfte Ihres 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 verwenden, schreiben Sie ihn neu oder verwenden Sie eine reine C/C++-Implementierung.

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

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

Passen Sie Formatstrings für Funktionen wie printf oder scanf an, da Sie mit den herkömmlichen Formatspezifizierern keine 64-Bit-Typen angeben können, die 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 zum Schreiben und Lesen von Hexadezimalzeigern sowie PRId64 und SCNd64 zum portablen 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 umfasst.

Größensteigerungen mit Android App Bundles abmildern

Wenn Sie Ihrer App Unterstützung für 64-Bit-Architekturen hinzufügen, kann sich die Größe Ihrer APK erhöhen. Wir empfehlen dringend, die Funktion Android App Bundle zu nutzen, um die Auswirkungen auf die Größe zu minimieren, wenn sowohl 32‑Bit- als auch 64‑Bit-Nativcode in dasselbe APK aufgenommen 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 leistungsfähige Versionen

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

Wenn Sie eine Unity-Version verwenden, die keine 64-Bit-Unterstützung bietet, müssen Sie ein Upgrade auf eine Version durchführen, die 64-Bit-Unterstützung bietet. Folgen Sie dazu der Anleitung von Unity, um Ihre Umgebung zu migrieren und Ihre App auf eine Version zu aktualisieren, mit der 64-Bit-Bibliotheken erstellt werden können. Unity empfiehlt, dass Sie durch Aktualisieren auf die aktuelle LTS-Version des Editors Zugriff auf die neuesten Funktionen und Updates haben.

In der folgenden Tabelle sind die verschiedenen Unity-Versionen und die entsprechenden Maßnahmen aufgeführt:

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

Wenn Sie eine Unity-Version verwenden, die 64‑Bit-Android-Bibliotheken unterstützt, können Sie eine 64‑Bit-Version Ihrer App erstellen, indem Sie die 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 Settings (Build-Einstellungen) auf und prüfen Sie, ob Sie für Android entwickeln. Das Unity-Symbol muss neben Android unter Platform (Plattform) 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. Rufen Sie das Player Settings Panel > Settings for Android > Other settings > Configuration auf.

4. Setzen Sie Scripting Backend auf IL2CPP.

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

   

6. Bauen Sie wie gewohnt!

Wenn Sie für ARM64 entwickeln, müssen alle Ihre Assets speziell für diese Plattform erstellt werden. Folgen Sie den Anleitungen von Unity, um die APK-Größe zu verringern, und nutzen Sie die Funktion Android App Bundle, um die Zunahme der Größe zu minimieren.

Mehrere APKs und 64‑Bit-Compliance

Wenn du die Unterstützung für mehrere APKs nutzt, um deine 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 bereitgestellt werden.

Wenn eines Ihrer APKs als nicht richtlinienkonform markiert ist, es sich aber um eine frühere Version handelt und es nicht möglich ist, die Richtlinienkonformität herzustellen, können Sie dem uses-sdk-Element im Manifest dieses APKs das Attribut maxSdkVersion="27" hinzufügen. Diese APK wird nicht auf Geräten mit Android 9 Pie oder höher bereitgestellt und blockiert die Einhaltung der Richtlinien nicht mehr.

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-Kompatibilität auf. Bei Build-Tools vor Version 21.0.0 kann der Compiler Bitcode in einer externen .bc-Datei generieren. Diese alten .bc-Dateien werden für 64-Bit-Architekturen nicht mehr unterstützt. Das Vorhandensein der Datei in Ihrem APK führt daher zu einem Compliance-Problem.

Entfernen Sie alle .bc-Dateien in Ihrem Projekt, aktualisieren Sie Ihre Umgebung auf build-tools-21.0.0 oder höher und legen Sie renderscriptTargetApi in Android Studio auf 21 oder höher fest, damit der Compiler keine .bc-Dateien ausgibt. Erstellen Sie dann Ihre App neu, suchen Sie nach .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 denselben Funktionsumfang wie die 32-Bit-Version bieten. Testen Sie Ihre App, um sicherzustellen, dass Nutzer auf den neuesten 64‑Bit-Geräten eine gute Nutzererfahrung haben.

Nur 64-Bit-Geräte

Wir empfehlen, Ihre App nach Möglichkeit in einer reinen 64-Bit-Umgebung zu testen. Verwenden Sie dazu eine der folgenden Optionen:

• Google Pixel mit einem System-Image, das nur 64 Bit unterstützt
• Android Emulator

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

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

Nur 64‑Bit-Image herunterladen

Ähnlich wie bei Factory-System-Images können Sie ein reines 64-Bit-Image auf Ihr Gerät flashen. Verwenden Sie dazu das Android Flash Tool oder flashen Sie Ihr Gerät manuell, wie in den folgenden Abschnitten beschrieben.

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+.

Das Android Flash Tool führt Sie Schritt für Schritt durch den Flash-Vorgang. Sie müssen keine Tools installieren, aber Ihr Gerät entsperren und 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. Rufen Sie dann je nach dem Typ des Systemabbilds, das Sie flashen möchten, das Android Flash Tool über einen der folgenden Links auf und folgen Sie der Anleitung auf dem Bildschirm:

• Android 14 (Beta 5.2) – Systemimages nur für 64-Bit-Geräte

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

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

• Android 13 (QPR3 Beta 3.2) – Systemimages nur für 64-Bit-Geräte

  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 aktuelle System-Image herunterladen und manuell auf Ihrem Gerät installieren. In der folgenden Tabelle finden Sie das System-Image für Ihr Testgerät. Das manuelle Flashen eines Geräts ist nützlich, wenn Sie die Testumgebung genau steuern müssen oder wenn Sie das Gerät häufig neu installieren müssen, z. B. bei automatisierten Tests.

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

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

Nur 64-Bit-Factory 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 reinen 64‑Bit-Konfigurationen sind nur für Entwickler vorgesehen.

Nur 64-Bit-Factory-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 reinen 64‑Bit-Konfigurationen sind nur für Entwickler vorgesehen.

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 Factory-Spezifikationen von der Seite Factory Images für Nexus und Pixel herunterladen und es dann manuell auf das Gerät flashen.

Android Emulator

Ab Android 12 (API-Level 31) sind Android Emulator-Systemimages nur als 64-Bit-Version verfügbar. Erstellen Sie ein AVD (Android Virtual Device) mit einem System-Image mit Android 12 (API-Level 31) oder höher, um eine reine 64-Bit-Umgebung für das Testen von Apps zu erhalten.

Weitere Geräteoptionen

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

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 festzulegen, 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

Nach der erfolgreichen Installation testen Sie Ihre App wie gewohnt, um sicherzustellen, dass die Qualität der 64‑Bit-Version der 32‑Bit-Version entspricht.

Auf bekannte Kompatibilitätsprobleme prüfen

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

SoLoader

Wenn Sie das SDK für den nativen Code-Loader SoLoader verwenden, aktualisieren Sie es auf Version 0.10.4 oder höher. Wenn in Ihrer App SDKs verwendet werden, die vom SoLoader abhängig sind, aktualisieren Sie diese SDKs ebenfalls auf die neueste stabile Version.

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

Weitere Informationen zum Beheben dieses und anderer Probleme, die durch SoLoader verursacht werden, finden Sie in der Google-Hilfe.

OpenSSL

Wenn Sie die OpenSSL-Bibliothek verwenden, aktualisieren 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ängig sind, aktualisieren Sie auch auf die neueste Version des SDK, das eine neuere OpenSSL-Version verwendet. Wenden Sie sich an den SDK-Anbieter, wenn keiner verfügbar ist.

ARMv8.3 PAC ermöglicht die hardwaregestützte Kontrollflussintegrität durch die Authentifizierung von Zeigern zur Laufzeit. Frühere Versionen von OpenSSL 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 zum Beheben dieses und anderer Probleme, die durch OpenSSL verursacht werden, 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. Bei früheren Versionen von Obfuskierungs-SDKs, die in zufällige Offsets von mit BTI erstellten Bibliotheken verzweigen, kann es zu App-Abstürzen kommen. 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 bereit ist, können Sie sie wie gewohnt veröffentlichen. Halten Sie sich wie immer an die Best Practices für die Bereitstellung Ihrer App. Wir empfehlen, geschlossene Testtracks zu nutzen, um die App für eine begrenzte Anzahl von Nutzern bereitzustellen und so die Qualität Ihrer App zu gewährleisten.

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