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 kannst du die Leistung verbessern und Geräte mit reiner 64-Bit-Hardware einrichten.

Mit den folgenden Schritten kannst du sicherstellen, dass deine 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 und 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, bewerten Sie sie.

Schnelle Statusprüfung

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

In der Play Console werden auch Warnungen angezeigt, die für deine Versionsentwürfe gelten, wenn Probleme im Zusammenhang mit der 64-Bit-Anforderung auftreten. In der folgenden Abbildung 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 nutzt nativen Code, wenn:

• Verwendet beliebigen (nativen) C/C++ Code in Ihrer App.
• Links zu nativen Bibliotheken von Drittanbietern.
• Wurde 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 die App benötigt. Native Bibliotheken werden basierend auf dem ABI in verschiedenen Ordnern gespeichert. Es muss nicht jede 64-Bit-Architektur unterstützt werden. Sie müssen jedoch für jede native 32-Bit-Architektur die entsprechende 64-Bit-Architektur hinzufügen.

Für die ARM-Architektur befinden sich die 32-Bit-Bibliotheken in armeabi-v7a. Das 64-Bit-Äquivalent ist 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. Hier noch einmal zusammengefasst:

Je nach Anwendung kann es sein, dass in jedem Ordner genau derselbe Satz von Bibliotheken vorhanden ist. Ziel ist es, dafür zu sorgen, dass Ihre Anwendung in einer reinen 64-Bit-Umgebung korrekt ausgeführt wird.

In einem typischen Fall hat ein APK oder Bundle, das für 32-Bit- und 64-Bit-Architekturen erstellt wurde, Ordner für beide ABIs, jeweils mit 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 prüfen, ob 64-Bit-Bibliotheken vorhanden sind.

1. Öffnen Sie Android Studio und 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. Sehen Sie im Ordner lib nach, in dem gegebenenfalls „.so“-Dateien gehostet werden. Wenn keine vorhanden sind, unterstützt deine App 64-Bit-Geräte und es sind keine weiteren Maßnahmen erforderlich. Wenn armeabi-v7a oder x86 angezeigt wird, haben Sie 32-Bit-Bibliotheken.

5. Überprüfen Sie, ob sich ähnliche ".so"-Dateien im Ordner arm64-v8a oder x86_64 befinden.

   

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

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

APKs entpacken und nach nativen Bibliotheken 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 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

Beachten Sie, dass in diesem Beispiel die Bibliotheken armeabi-v7a und arm64-v8a vorhanden sind, was bedeutet, dass die App 64-Bit-Architekturen unterstützt.

Apps mit 64-Bit-Bibliotheken erstellen

In der folgenden Anleitung wird beschrieben, wie 64-Bit-Bibliotheken erstellt werden. Beachten Sie, dass diese Schritte nur den Erstellungscode und Bibliotheken abdecken, die Sie aus dem Quellcode erstellen können.

Apps 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 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 Anwendung mit CMake erstellt wurde, können Sie für 64-Bit-ABIs erstellen. Dazu übergeben Sie arm64-v8a in 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, indem Sie die Datei 'Application.mk' mit der Variable APP_ABI ändern:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

32-Bit-Code auf 64-Bit übertragen

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

Aktualisieren Sie Code, der Cursor in Typen wie int, unsigned oder uint32_t speichert. Auf Unix-Systemen entspricht long der Zeigergröße, aber dies ist nicht der Fall unter Windows. Verwende stattdessen die Typen uintptr_t oder intptr_t, die die Absicht zeigen. Verwenden Sie den Typ ptrdiff_t, um die Differenz zwischen zwei Zeigern zu speichern.

Auch für Nicht-Zeiger sollten Sie immer die spezifischen Ganzzahltypen mit fester Breite, die in <stdint.h> definiert sind, und nicht Typen ohne fester Breite wie int oder long bevorzugen.

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

-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 das gleiche Problem. Suchen Sie in Ihrer JNI-Quelle 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 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 in einem 32-Bit-System, bei dem Ihr Zeiger in eine Ganzzahl passt. In 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`.

Das folgende Compiler-Flag wandelt implizite Warnungen zu Funktionsdeklarationen in Fehler um, sodass Sie dieses 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 (z. B. 8 oder 16 Byte) haben, ersetzen Sie sie durch den entsprechenden sizeof(T)-Ausdruck, z. B. sizeof(void*).

Wenn Sie bedingten anderen Code für 32-Bit als 64-Bit 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 mit herkömmlichen Formatspezifizierern nicht möglich ist, 64-Bit-Typen so anzugeben, dass dies sowohl für 32-Bit- als auch für 64-Bit-Geräte korrekt ist. 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 Schreiben und Lesen von 64-Bit-Werten.

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

Größenerhöhungen mit Android App Bundle abschwächen

Wenn du deiner App eine 64-Bit-Architektur hinzufügst, kann dein APK größer werden. Wir empfehlen dir dringend, die Funktion Android App Bundle zu nutzen, um die Auswirkungen der Verwendung von nativem 32- und 64-Bit-Code in dasselbe APK zu minimieren.

Spieleentwickler

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

• Unglaublich seit 2015
• Cocos2d seit 2015
• Unity seit 2018

Unity-Entwickler

Auf leistungsfähige Versionen upgraden

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

Wenn Sie eine Unity-Version verwenden, die 64-Bit nicht unterstützt, ermitteln Sie die Version, auf die Sie upgraden möchten, und folgen Sie den von Unity bereitgestellten Anleitungen für die Migration Ihrer Umgebung. Achten Sie darauf, dass Ihre Anwendung auf eine Version aktualisiert wurde, die 64-Bit-Bibliotheken erstellen kann. Unity empfiehlt, ein Upgrade auf die neueste LTS-Version des Editors durchzuführen, um Zugriff auf die neuesten Funktionen und Updates zu erhalten.

Die folgende Tabelle bietet einen Überblick über die verschiedenen Unity-Versionen und mögliche Maßnahmen:

Build-Einstellungen zur Ausgabe von 64-Bit-Bibliotheken ändern

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 Skript-Back-End. So richten Sie Ihr Unity-Projekt zum Erstellen einer 64-Bit-Architektur ein:

1. Rufen Sie Build Settings (Build-Einstellungen) auf und achten Sie darauf, dass Sie den Build für Android erstellen. Achten Sie darauf, dass sich das Unity-Symbol neben Android unter Platform befindet. 1. Wenn das Unity-Symbol nicht neben der Android-Plattform angezeigt wird, wählen Sie Android aus und klicken Sie auf Plattform wechseln.

2. Klicken Sie auf Player-Einstellungen.

   

3. Gehen Sie zu Player Settings Panel > Settings for Android (Einstellungen für Android) > Weitere Einstellungen > Konfiguration.

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

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

   

6. Build wie gewohnt!

Für ARM64 müssen alle Assets speziell für diese Plattform erstellt werden. Beachte die Unity-Anleitung zum Reduzieren der APK-Größe und erwäge, das Android App Bundle-Feature zu nutzen, um diese Erhöhung einzudämmen.

Multi-APK und 64-Bit-Compliance

Wenn du die Unterstützung für mehrere APKs von Google Play zum Veröffentlichen deiner App verwendest, wird die Einhaltung der 64-Bit-Anforderung auf Releasestufe bewertet. Die 64-Bit-Anforderung gilt jedoch nicht für APKs oder App Bundles, die nicht für Geräte mit Android 9 Pie oder höher bereitgestellt werden.

Wenn eines deiner APKs als nicht konform gekennzeichnet ist, aber eine ältere Version ist und es nicht möglich ist, es entsprechend anzupassen, kannst du beispielsweise ein maxSdkVersion="27"-Attribut in das Element uses-sdk im Manifest dieses APKs einfügen. Dieses APK wird nicht für Geräte mit Android 9 Pie oder höher bereitgestellt und blockiert die Compliance 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 64-Bit-Compliance-Probleme für die App auf. Bei Build-Tools vor Version 21.0.0 kann der Compiler Bitcode in eine externe .bc-Datei generieren. Diese älteren .bc-Dateien werden für 64-Bit-Architekturen nicht mehr unterstützt. Wenn die Datei in deinem APK vorhanden ist, kommt es daher zu Complianceproblemen.

Entfernen Sie zum Beheben des Problems 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, um den Compiler anzuweisen, keine .bc-Dateien auszugeben. Erstelle dann deine App neu, suche nach .bc-Dateien und lade sie in die Play Console hoch.

App auf 64-Bit-Hardware testen

Die 64-Bit-Version deiner App sollte dieselbe Qualität und denselben Funktionsumfang wie die 32-Bit-Version bieten. Teste deine App, um dafür zu sorgen, dass Nutzer mit aktuellen 64-Bit-Geräten eine positive Erfahrung damit haben.

Nur 64-Bit-Geräte

Wir empfehlen dir, deine Anwendung nach Möglichkeit in einer strikten 64-Bit-Umgebung zu testen. Verwende dazu eine der folgenden Optionen:

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

Google Pixel mit einem 64-Bit-System-Image

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

Nur 64-Bit-Bild abrufen

Ähnlich wie die werkseitigen System-Images können Sie mit dem Android Flash Tool ein reines 64-Bit-Image auf Ihr Gerät flashen. Alternativ können Sie Ihr Gerät manuell flashen, wie in den folgenden Abschnitten beschrieben.

Gerät mit dem Android Flash Tool flashen

Mit dem Android Flash Tool können Sie ein Systemimage sicher auf Ihr unterstütztes Pixel-Gerät laden. 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 den Vorgang des Flashens Ihres Geräts. Sie müssen dafür keine Tools installieren. Sie müssen jedoch Ihr Gerät entsperren und USB-Debugging in den Entwickleroptionen aktivieren. Eine ausführliche Anleitung finden Sie in der Dokumentation zum Android Flash Tool.

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

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

  Wähle das Gerät aus, das du flashen möchtest:

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

• Android 13 (QPR3 Beta 3.2) 64-Bit-System-Images

  Wähle das Gerät aus, das du flashen möchtest:

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

Gerät manuell blinken lassen

Du kannst auch das neueste System-Image herunterladen und es manuell auf dein Gerät flashen. Informationen zum Herunterladen des System-Images für dein Testgerät findest du in der folgenden Tabelle. Das manuelle Flashen eines Geräts ist nützlich, wenn Sie präzise Kontrolle über die Testumgebung benötigen oder wenn Sie häufig neu installieren müssen, z. B. bei automatischen Tests.

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

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

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

Diese Images bieten eine strikte 64-Bit-Umgebung zum Testen der 64-Bit-Anwendungskompatibilität. Diese reinen 64-Bit-Konfigurationen sind nur für Entwickler gedacht.

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

Diese Images bieten eine strikte 64-Bit-Umgebung zum Testen der 64-Bit-Anwendungskompatibilität. Diese reinen 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 Systemimage mit den Spezifikationen der Werkseinstellungen von der Seite Factory Images für Nexus- und Pixel-Geräte abrufen und es dann manuell auf dem Gerät installieren.

Android-Emulator

Ab Android 12 (API-Level 31) sind Android-Emulator-Systemimages nur noch 64-Bit-Versionen. Erstelle ein virtuelles Android-Gerät (AVD) mithilfe eines System-Images 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, verwenden Sie am besten ein 64-Bit-fähiges Gerät wie Google Pixel oder andere aktuelle Flagship-Geräte anderer Gerätehersteller.

App installieren und testen

Am einfachsten testen Sie Ihr APK, 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

Nach der erfolgreichen Installation testest du deine App 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 auswirken, wenn sie auf 64-Bit-Geräten ausgeführt werden. Auch wenn Ihre App nicht direkt von den betroffenen Bibliotheken abhängig ist, kann es passieren, dass Drittanbieter-Bibliotheken und -SDKs in den Abhängigkeiten Ihrer App vorhanden sind.

SoLoader

Wenn Sie das SDK SoLoader zum Hochladen von nativem Code verwenden, führen Sie ein Update auf Version 0.10.4 oder höher durch. Wenn Ihre App SDKs verwendet, die von SoLoader abhängen, müssen Sie auch die betroffenen SDKs auf die neueste stabile Version aktualisieren.

Für SoLoader v0.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 vorhanden ist, ist dieser Fehler nicht erkennbar. Diese Annahme führt jedoch zu Abstürzen auf Geräten, die nur Systembibliotheken in /vendor/lib64:/system/lib64 haben.

Weitere Informationen zur Behebung dieses und anderer durch SoLoader verursachter Probleme findest du in der entsprechenden Antwort 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 eine Kommunikation über HTTPS oder andere von OpenSSL abhängige SDKs ermöglichen, müssen Sie auch ein Update auf die neueste SDK-Version vornehmen, die eine neuere OpenSSL-Version verwendet. Wende dich an den SDK-Anbieter, falls keiner verfügbar ist.

ARMv8.3 PAC aktiviert die hardwaregestützte Steuerung der Integritätsprüfung, 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 in zufällige Offsets von Bibliotheken verzweigt werden, die mit BTI erstellt wurden, können zum Absturz von Apps führen. Da die Anleitung als HINTs codiert ist, kann dieser Fehler auf Geräten, die BTI nicht unterstützen, nicht beobachtet werden.

Veröffentlichen

Wenn du der Meinung bist, dass deine App fertig ist, kannst du sie wie gewohnt veröffentlichen. Folgen Sie wie immer den Best Practices für die Bereitstellung Ihrer App. Wir empfehlen die Nutzung von geschlossenen Test-Tracks für eine begrenzte Anzahl von Nutzern, um für eine konstante Qualität Ihrer Anwendung zu sorgen.

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