Obsługa architektury 64-bitowej

Aplikacje publikowane w Google Play muszą obsługiwać architekturę 64-bitową. Dodanie 64-bitowej wersji aplikacji zwiększa jej wydajność i przygotowuje ją do działania na urządzeniach z 64-bitowym sprzętem.

Wykonaj te czynności, aby aplikacja 32-bitowa obsługiwała urządzenia 64-bitowe.

Ocena aplikacji

Jeśli aplikacja korzysta tylko z kodu napisanego w języku programowania Java lub Kotlin, w tym ze wszystkich bibliotek i pakietów SDK, obsługuje urządzenia 64-bitowe. Jeśli Twoja aplikacja używa kodu natywnego lub nie masz pewności, czy tak jest, przeprowadź ocenę aplikacji.

Szybkie sprawdzenie stanu

Otwórz Konsolę Play i sprawdź, czy istniejące wersje są zgodne z zasadami.

Konsola Play wyświetla też ostrzeżenia dotyczące wersji roboczych, jeśli występują problemy związane z wymaganiami dotyczącymi kodu 64-bitowego. Obraz poniżej jest przykładem.

Jeśli pojawi się alert, wykonaj te czynności, aby dostosować aplikację do urządzeń 64-bitowych.

Czy Twoja aplikacja korzysta z kodu natywnego?

Aplikacja korzysta z kodu natywnego, jeśli:

• używa w aplikacji kodu C/C++ (natywnego);
• linki do zewnętrznych bibliotek natywnych;
• została utworzona przez twórcę aplikacji innej firmy, który korzysta z bibliotek natywnych;

Czy Twoja aplikacja zawiera biblioteki 64-bitowe?

Sprawdź strukturę pliku APK. Po skompilowaniu plik APK jest pakowany z bibliotekami natywnymi potrzebnymi aplikacji. Biblioteki natywne są przechowywane w różnych folderach w zależności od ABI. Nie musisz obsługiwać wszystkich architektur 64-bitowych, ale w przypadku każdej obsługiwanej architektury 32-bitowej musisz uwzględnić odpowiednią architekturę 64-bitową.

W przypadku architektury ARM biblioteki 32-bitowe znajdują się w folderze armeabi-v7a. Odpowiednikiem 64-bitowym jest arm64-v8a.

W przypadku architektury x86 szukaj x86 dla wersji 32-bitowej i x86_64 dla wersji 64-bitowej.

Upewnij się, że w obu tych folderach znajdują się biblioteki natywne. Podsumowując:

Pamiętaj, że w zależności od aplikacji w każdym folderze może znajdować się taki sam zestaw bibliotek. Chodzi o to, aby mieć pewność, że aplikacja działa prawidłowo w środowisku 64-bitowym.

Zwykle plik APK lub pakiet utworzony dla architektur 32-bitowej i 64-bitowej zawiera foldery dla obu interfejsów ABI, a w każdym z nich znajduje się odpowiedni zestaw bibliotek natywnych. Jeśli nie ma obsługi 64-bitowej, może być widoczny folder ABI 32-bitowy, ale nie 64-bitowy.

Wyszukiwanie bibliotek natywnych za pomocą narzędzia APK Analyzer

Analizator APK to narzędzie, które umożliwia ocenę różnych aspektów utworzonego pliku APK. Użyj go, aby znaleźć wszystkie biblioteki natywne i upewnić się, że są dostępne biblioteki 64-bitowe.

1. Otwórz Android Studio i dowolny projekt.

2. W menu wybierz Build > Analyze APK (Utwórz > Przeanalizuj pakiet APK)…

   

3. Wybierz plik APK, który chcesz ocenić.

4. Sprawdź folder lib, w którym znajdują się pliki „.so” (jeśli są). Jeśli nie ma żadnych takich plików, oznacza to, że aplikacja obsługuje urządzenia 64-bitowe i nie musisz podejmować żadnych działań. Jeśli widzisz armeabi-v7a lub x86, oznacza to, że masz biblioteki 32-bitowe.

5. Sprawdź, czy w folderze arm64-v8a lub x86_64 znajdują się podobne pliki „.so”.

   

6. Jeśli nie masz bibliotek arm64-v8a ani x86_64, zaktualizuj proces kompilacji, aby rozpocząć tworzenie i pakowanie tych artefaktów w pliku APK.

7. Jeśli widzisz, że obie biblioteki są już spakowane, możesz przejść do testowania aplikacji na sprzęcie 64-bitowym.

Wyszukiwanie bibliotek natywnych przez rozpakowywanie plików APK

Pliki APK mają strukturę podobną do plików ZIP. Za pomocą wiersza poleceń lub innego narzędzia do wyodrębniania wyodrębnij plik APK. W zależności od narzędzia do wyodrębniania może być konieczne zmiana nazwy pliku na .zip.

Przejrzyj wyodrębnione pliki i postępuj zgodnie z powyższymi wskazówkami, aby sprawdzić, czy Twoja aplikacja obsługuje urządzenia 64-bitowe. W wierszu poleceń możesz uruchomić to polecenie:

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

Zwróć uwagę, że w tym przykładzie występują biblioteki armeabi-v7a i arm64-v8a, co oznacza, że aplikacja obsługuje architektury 64-bitowe.

Kompilowanie aplikacji z bibliotekami 64-bitowymi

Poniżej znajdziesz instrukcje tworzenia bibliotek 64-bitowych. Pamiętaj, że te kroki obejmują tylko tworzenie kodu i bibliotek, które możesz utworzyć na podstawie kodu źródłowego.

Tworzenie w Android Studio lub Gradle

Większość projektów Androida Studio korzysta z Gradle jako podstawowego systemu kompilacji, więc ta sekcja dotyczy obu przypadków. Aby włączyć kompilacje kodu natywnego, dodaj arm64-v8a lub x86_64 (w zależności od architektur, które chcesz obsługiwać) do ustawienia ndk.abiFilters w pliku „build.gradle” aplikacji:

// 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")
        }
// ...

Kompilowanie za pomocą CMake

Jeśli Twoja aplikacja została utworzona za pomocą CMake, możesz utworzyć wersję dla 64-bitowych interfejsów ABI, przekazując parametr arm64-v8a do parametru „-DANDROID_ABI”:

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

Tworzenie za pomocą ndk-build

Jeśli aplikacja została utworzona za pomocą narzędzia ndk-build, możesz utworzyć wersję dla 64-bitowych interfejsów ABI, modyfikując plik „Application.mk” za pomocą zmiennej APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Przenoszenie kodu 32-bitowego do 64-bitowego

Jeśli kod działa już na komputerach lub urządzeniach z iOS, nie musisz wykonywać żadnych dodatkowych czynności w przypadku Androida. Jeśli kod jest kompilowany na system 64-bitowy po raz pierwszy, głównym problemem, który musisz rozwiązać, jest to, że wskaźniki nie mieszczą się już w 32-bitowych typach liczb całkowitych, takich jak int.

Zaktualizuj kod, który przechowuje wskaźniki w typach takich jak int, unsigned lub uint32_t. W systemach Unix wartość long odpowiada rozmiarowi wskaźnika, ale w systemie Windows tak nie jest. Zamiast tego użyj typów uintptr_t lub intptr_t, które ujawniają intencję. Aby zapisać różnicę między dwoma wskaźnikami, użyj typu ptrdiff_t.

Zawsze preferuj konkretne typy liczb całkowitych o stałej szerokości zdefiniowane w <stdint.h> zamiast typów o zmiennej szerokości, takich jak int lub long, nawet w przypadku wskaźników.

Użyj tych flag kompilatora, aby wykryć przypadki, w których kod nieprawidłowo konwertuje wskaźniki na liczby całkowite i odwrotnie:

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

Ten sam problem występuje w przypadku klas Java z polami int, które zawierają wskaźniki do obiektów C/C++. Wyszukaj w kodzie źródłowym JNI symbol jint i upewnij się, że po stronie Javy używasz symbolu long, a po stronie C++ – symbolu jlong.

Deklaracje funkcji niejawnych są znacznie bardziej niebezpieczne w przypadku kodu 64-bitowego. W językach C/C++ zakłada się, że typ zwracany funkcji zadeklarowanej niejawnie (czyli funkcji, której deklaracji kompilator nie widział) to int. Jeśli rzeczywisty typ zwracany funkcji jest wskaźnikiem, w 32-bitowym systemie, w którym wskaźnik mieści się w liczbie całkowitej, wszystko działa prawidłowo. Jednak w 64-bitowym systemie kompilator odrzuca górną połowę wskaźnika. Na przykład:

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

Ten flaga kompilatora zamienia ostrzeżenia o niejawnej deklaracji funkcji w błędy, dzięki czemu możesz łatwiej znaleźć i rozwiązać ten problem:

-Werror=implicit-function-declaration

Jeśli masz asembler wbudowany, przepisz go lub użyj implementacji w języku C/C++.

Jeśli masz zakodowane na stałe rozmiary typów (np. 8 lub 16 bajtów), zastąp je odpowiednim wyrażeniem sizeof(T), np. sizeof(void*).

Jeśli musisz warunkowo kompilować inny kod dla wersji 32-bitowej niż dla 64-bitowej, możesz użyć #if defined(__LP64__) w przypadku ogólnych różnic między wersjami 32-bitową i 64-bitową lub __arm__, __aarch64__ (arm64), __i386__ (x86) i __x86_64__ w przypadku konkretnych architektur obsługiwanych przez Androida.

Dostosuj ciągi formatu do funkcji podobnych do printf lub scanf, ponieważ tradycyjne specyfikatory formatu nie pozwalają określać typów 64-bitowych w sposób prawidłowy zarówno w przypadku urządzeń 32-bitowych, jak i 64-bitowych. Makrodefinicje PRI i SCN w <inttypes.h> rozwiązują ten problem. PRIxPTR i SCNxPTR służą do zapisywania i odczytywania wskaźników szesnastkowych, a PRId64 i SCNd64 do zapisywania i odczytywania 64-bitowych wartości w sposób przenośny.

Podczas przesuwania możesz potrzebować użyć 1ULL, aby przesunąć stałą 64-bitową, zamiast 1, która ma tylko 32 bity.

Ograniczanie wzrostu rozmiaru aplikacji dzięki pakietom Android App Bundle

Dodanie do aplikacji obsługi architektury 64-bitowej może spowodować zwiększenie rozmiaru pliku APK. Zdecydowanie zalecamy korzystanie z funkcji pakietu Android App Bundle, aby zminimalizować wpływ rozmiaru na uwzględnienie w tym samym pliku APK 32- i 64-bitowego kodu natywnego.

Twórcy gier

3 najczęściej używane wyszukiwarki obsługują 64-bitową wersję:

• Unreal od 2015 r.
• Cocos2d od 2015 r.
• Unity od 2018 r.

Deweloperzy Unity

Uaktualnianie do wersji z możliwością

Unity obsługuje 64-bitowe wersje 2018.2 i 2017.4.16.

Jeśli używasz wersji Unity, która nie obsługuje 64-bitowej architektury, określ wersję, do której chcesz przejść, i postępuj zgodnie z przewodnikami udostępnianymi przez Unity, aby przenieść środowisko. Upewnij się, że aplikacja została zaktualizowana do wersji, która może tworzyć biblioteki 64-bitowe. Aby mieć dostęp do najnowszych funkcji i aktualizacji, Unity zaleca uaktualnienie do najnowszej wersji LTS edytora.

Poniższa tabela zawiera informacje o różnych wersjach Unity i odpowiednie działania:

Zmienianie ustawień kompilacji w celu generowania bibliotek 64-bitowych

Jeśli używasz wersji Unity, która obsługuje 64-bitowe biblioteki Androida, możesz wygenerować 64-bitową wersję aplikacji, dostosowując ustawienia kompilacji. Użyj backendu IL2CPP jako backendu skryptów. Aby skonfigurować projekt Unity pod kątem kompilacji architektury 64-bitowej, wykonaj te czynności:

1. Otwórz Ustawienia kompilacji i upewnij się, że kompilujesz projekt na Androida. W tym celu sprawdź, czy obok Android w sekcji Platforma znajduje się symbol Unity. 1. Jeśli obok platformy Android nie ma symbolu Unity, wybierz Android i kliknij Przełącz platformę.

2. Kliknij Ustawienia odtwarzacza.

   

3. Otwórz Panel ustawień odtwarzacza > Ustawienia Androida > Inne ustawienia > Konfiguracja.

4. Ustaw Scripting Backend na IL2CPP.

5. Zaznacz pole wyboru Architektura docelowa > ARM64.

   

6. Buduj jak zwykle.

Pamiętaj, że kompilacja na platformę ARM64 wymaga, aby wszystkie zasoby były tworzone specjalnie dla tej platformy. Postępuj zgodnie z wytycznymi Unity dotyczącymi zmniejszania rozmiaru pliku APK i rozważ skorzystanie z funkcji pakietu aplikacji na Androida, aby ograniczyć ten wzrost rozmiaru.

Zgodność z wieloma plikami APK i kodem 64-bitowym

Jeśli do publikowania aplikacji używasz obsługi wielu plików APK w Google Play, pamiętaj, że zgodność z wymaganiami dotyczącymi kodu 64-bitowego jest oceniana na poziomie wersji. Wymaganie dotyczące kodu 64-bitowego nie dotyczy jednak plików APK ani pakietów aplikacji, które nie są rozpowszechniane na urządzeniach z Androidem 9 Pie lub nowszym.

Jeśli jeden z Twoich plików APK jest oznaczony jako niezgodny, ale jest starszą wersją i nie można go dostosować do zasad, możesz dodać atrybut maxSdkVersion="27" do elementu uses-sdk w pliku manifestu tego pliku APK. Ten plik APK nie jest dostarczany na urządzenia z Androidem 9 Pie lub nowszym i nie blokuje już zgodności.

Zgodność z RenderScript i 64-bitową architekturą

Jeśli Twoja aplikacja korzysta z RenderScript i została utworzona za pomocą starszej wersji narzędzi Androida, mogą w niej występować problemy ze zgodnością z 64-bitową architekturą. W przypadku narzędzi do kompilacji w wersji starszej niż 21.0.0 kompilator może generować kod pośredni w zewnętrznym pliku .bc. Te starsze pliki .bc nie są już obsługiwane w przypadku architektur 64-bitowych, więc obecność tego pliku w pakiecie APK powoduje problem ze zgodnością.

Aby rozwiązać ten problem, usuń z projektu wszystkie pliki .bc, zaktualizuj środowisko do wersji build-tools-21.0.0 lub nowszej i ustaw wartość renderscriptTargetApi w Android Studio na 21+, aby poinformować kompilator, że nie ma emitować plików .bc. Następnie ponownie skompiluj aplikację, sprawdź, czy zawiera pliki .bc, i prześlij ją do Konsoli Play.

Testowanie aplikacji na sprzęcie 64-bitowym

64-bitowa wersja aplikacji powinna oferować taką samą jakość i zestaw funkcji jak wersja 32-bitowa. Przetestuj aplikację, aby mieć pewność, że użytkownicy najnowszych urządzeń 64-bitowych będą mogli z niej wygodnie korzystać.

Urządzenia obsługujące tylko 64-bitowe aplikacje

Jeśli to możliwe, zalecamy testowanie aplikacji w środowisku 64-bitowym, korzystając z jednej z tych opcji:

• Google Pixel z obrazem systemu 64-bitowego
• Emulator Androida

Google Pixel z obrazem systemu 64-bitowego

Aby ułatwić tworzenie i testowanie aplikacji, udostępniliśmy specjalne obrazy systemu z środowiskiem obsługującym tylko 64-bitowe aplikacje na niektórych urządzeniach Pixel. Te obrazy tylko 64-bitowe były pierwotnie udostępniane równolegle ze standardowymi obrazami systemu fabrycznego w przypadku wersji przedpremierowych Androida 13 i 14, ale możesz nadal ich używać podczas testowania aplikacji pod kątem zgodności z 64-bitową architekturą.

Uzyskiwanie obrazu tylko w wersji 64-bitowej

Podobnie jak w przypadku obrazów systemu fabrycznego możesz wgrać na urządzenie obraz tylko 64-bitowy za pomocą narzędzia Android Flash Tool lub ręcznie, jak opisano w kolejnych sekcjach.

Flashowanie urządzenia za pomocą narzędzia Android Flash Tool

Android Flash Tool umożliwia bezpieczne flashowanie obrazu systemu na obsługiwanym urządzeniu Pixel. Narzędzie Android Flash Tool działa w każdej przeglądarce internetowej obsługującej WebUSB, np. Chrome lub Edge w wersji 79 lub nowszej.

Narzędzie Android Flash Tool przeprowadzi Cię krok po kroku przez proces flashowania urządzenia. Nie musisz instalować żadnych narzędzi, ale musisz odblokować urządzenie i włączyć debugowanie USB w opcjach programisty. Pełne instrukcje znajdziesz w dokumentacji narzędzia Android Flash Tool.

Podłącz urządzenie przez USB, a następnie w zależności od typu obrazu systemu, który chcesz wgrać, otwórz narzędzie Android Flash Tool, korzystając z jednego z tych linków, i postępuj zgodnie z instrukcjami wyświetlanymi na ekranie:

• Obrazy systemu Android 14 (Beta 5.2) tylko w wersji 64-bitowej

  Wybierz urządzenie, na którym chcesz zainstalować oprogramowanie:

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

• Obrazy systemu Android 13 (QPR3 Beta 3.2) tylko w wersji 64-bitowej

  Wybierz urządzenie, na którym chcesz zainstalować oprogramowanie:

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

Ręczne flashowanie urządzenia

Możesz też pobrać najnowszy obraz systemu i ręcznie wgrać go na urządzenie. Aby pobrać obraz systemu na urządzenie testowe, zapoznaj się z tabelą poniżej. Ręczne flashowanie urządzenia jest przydatne, jeśli potrzebujesz precyzyjnej kontroli nad środowiskiem testowym lub jeśli musisz często ponownie instalować oprogramowanie, np. podczas przeprowadzania testów automatycznych.

Po utworzeniu kopii zapasowej danych urządzenia i pobraniu odpowiedniego obrazu systemu możesz wgrać go na urządzenie.

W każdej chwili możesz przywrócić najnowszą wersję publiczną.

Obrazy fabryczne tylko w wersji 64-bitowej dla Androida 14 (beta 5.3)

Te obrazy zapewniają środowisko 64-bitowe wyłącznie do testowania zgodności aplikacji 64-bitowych. Te konfiguracje 64-bitowe są przeznaczone wyłącznie dla deweloperów.

Obrazy fabryczne tylko w wersji 64-bitowej dla Androida 13 (QPR3 Beta 3.2)

Te obrazy zapewniają środowisko 64-bitowe wyłącznie do testowania zgodności aplikacji 64-bitowych. Te konfiguracje 64-bitowe są przeznaczone wyłącznie dla deweloperów.

Wracanie do wersji publicznej

Możesz użyć narzędzia Android Flash Tool, aby wgrać obraz fabryczny, lub pobrać obraz systemu o specyfikacji fabrycznej ze strony Obrazy fabryczne dla urządzeń Nexus i Pixel, a następnie ręcznie wgrać go na urządzenie.

Android Emulator

Od Androida 12 (API na poziomie 31) obrazy systemu Android Emulator są dostępne tylko w wersji 64-bitowej. Utwórz wirtualne urządzenie z Androidem (AVD), używając obrazu systemu z Androidem 12 (API na poziomie 31) lub nowszym, aby uzyskać środowisko 64-bitowe do testowania aplikacji.

Inne opcje urządzenia

Jeśli nie masz jednego z tych urządzeń lub nie możesz użyć emulatora Androida, najlepszym rozwiązaniem będzie użycie urządzenia 64-bitowego, takiego jak Google Pixel lub inne najnowsze flagowe urządzenia innych producentów.

Instalowanie i testowanie aplikacji

Najprostszym sposobem przetestowania pliku APK jest zainstalowanie aplikacji za pomocą Android Debug Bridge (adb). W większości przypadków możesz podać --abi jako parametr, aby wskazać, które biblioteki mają zostać zainstalowane na urządzeniu. Spowoduje to zainstalowanie na urządzeniu aplikacji zawierającej tylko biblioteki 64-bitowe.

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

Po pomyślnej instalacji przetestuj aplikację w zwykły sposób, aby upewnić się, że jej jakość jest taka sama jak w przypadku wersji 32-bitowej.

Sprawdzanie znanych problemów ze zgodnością

Podczas testowania sprawdź, czy w aplikacji nie występują te problemy, które mają wpływ na działanie aplikacji na urządzeniach 64-bitowych. Nawet jeśli aplikacja nie bazuje bezpośrednio na bibliotekach, których dotyczy problem, mogą z nich korzystać biblioteki i pakiety SDK innych firm, na których polega aplikacja.

SoLoader

Jeśli używasz pakietu SDK do ładowania kodu natywnego SoLoader, zaktualizuj go do wersji 0.10.4 lub nowszej. Jeśli Twoja aplikacja korzysta z pakietów SDK, które są zależne od SoLoader, zaktualizuj je do najnowszej stabilnej wersji.

W wersjach SoLoader 0.9.0 i starszych zakłada się, że biblioteki systemowe znajdują się w katalogu /vendor/lib:/system/lib. Ten błąd nie występuje na urządzeniach takich jak Pixel 7, na których ścieżka istnieje, ale to założenie powoduje awarie na urządzeniach, które mają tylko biblioteki systemowe w /vendor/lib64:/system/lib64.

Więcej informacji o rozwiązywaniu tego i innych problemów spowodowanych przez SoLoader znajdziesz w odpowiednim artykule w Centrum pomocy Google.

OpenSSL

Jeśli używasz biblioteki OpenSSL, zaktualizuj ją do wersji 1.1.1i lub nowszej. Jeśli Twoja aplikacja korzysta z pakietów SDK, które zapewniają komunikację za pomocą protokołu HTTPS, lub innych pakietów SDK, które bazują na OpenSSL, pamiętaj, aby zaktualizować je do najnowszej wersji, która korzysta z nowszej wersji OpenSSL. Jeśli nie jest dostępny, skontaktuj się z dostawcą pakietu SDK.

ARMv8.3 PAC umożliwia działanie wspomaganego sprzętowo mechanizmu Control-flow integrity przez uwierzytelnianie wskaźników w czasie działania. Starsze wersje OpenSSL używają tych funkcji nieprawidłowo, co powoduje awarie w czasie działania na wszystkich urządzeniach z procesorami opartymi na architekturze ARMv8.3a i nowszych.

Więcej informacji o rozwiązywaniu tego i innych problemów spowodowanych przez OpenSSL znajdziesz w odpowiednim artykule w Centrum pomocy Google.

BTI

Architektura ARMv8.5 i nowsze korzystają z instrukcji docelowych rozgałęzienia (BTI), aby chronić przed atakami JOP. Starsze wersje pakietów SDK do zaciemniania, które rozgałęziają się na losowe przesunięcia bibliotek utworzonych za pomocą BTI, mogą powodować awarie aplikacji. Ponieważ instrukcje są zakodowane jako podpowiedzi, ten błąd nie występuje na urządzeniach, które nie obsługują BTI.

Opublikuj

Gdy uznasz, że aplikacja jest gotowa, opublikuj ją w standardowy sposób. Jak zawsze, postępuj zgodnie ze sprawdzonymi metodami wdrażania aplikacji. Zalecamy korzystanie ze ścieżek testów zamkniętych, aby udostępniać aplikację ograniczonej liczbie użytkowników i zapewnić jej wysoką jakość.

Podobnie jak w przypadku wdrażania dużej aktualizacji, przed opublikowaniem aplikacji dla większej grupy odbiorców dokładnie przetestuj ją na urządzeniach 64-bitowych.