Obsługa architektury 64-bitowej

Aplikacje publikowane w Google Play muszą obsługiwać architektury 64-bitowe. Dodanie 64-bitowej wersji aplikacji zwiększa jej wydajność i przygotowuje ją do działania na urządzeniach 64-bitowych.

Wykonaj te czynności, aby upewnić się, że Twoja aplikacja 32-bitowa obsługuje urządzenia 64-bitowe.

Ocena aplikacji

Jeśli aplikacja używa tylko kodu napisanego w języku programowania Java lub Kotlin, w tym 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, oceń ją.

Szybkie sprawdzanie stanu

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

Konsola Play wyświetla też ostrzeżenia dotyczące wersji roboczych, jeśli występują problemy związane z wymaganiem dotyczącym 64 bitów. Poniższy obraz jest przykładem.

Jeśli pojawi się alert, wykonaj te czynności, aby aplikacja była zgodna z urządzeniami 64-bitowymi.

Czy Twoja aplikacja używa kodu natywnego?

Aplikacja używa kodu natywnego, jeśli:

• używa w aplikacji kodu C/C++ (natywnego);
• łączy się z zewnętrznymi bibliotekami natywnymi;
• została utworzona za pomocą kreatora aplikacji innej firmy, który korzysta z bibliotek natywnych;

Czy aplikacja zawiera biblioteki 64-bitowe?

Sprawdź strukturę pliku APK. Podczas kompilacji plik APK jest pakowany ze wszystkimi bibliotekami natywnymi wymaganymi przez aplikację. Biblioteki natywne są przechowywane w różnych folderach w zależności od ABI. Nie musisz obsługiwać każdej architektury 64-bitowej, ale w przypadku każdej obsługiwanej natywnej architektury 32-bitowej musisz uwzględnić odpowiadającą jej architekturę 64-bitową.

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

W przypadku architektury x86 poszukaj x86 w przypadku wersji 32-bitowej i x86_64 w przypadku 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ę dokładnie ten sam zestaw bibliotek lub nie. Chodzi o to, aby aplikacja działała prawidłowo w środowisku wyłącznie 64-bitowym.

W typowym przypadku plik APK lub pakiet utworzony dla architektur 32- i 64-bitowych zawiera foldery dla obu interfejsów ABI, z których każdy ma odpowiedni zestaw bibliotek natywnych. Jeśli nie ma obsługi architektury 64-bitowej, możesz zobaczyć folder 32-bitowego interfejsu ABI, ale nie folder 64-bitowy.

Szukanie bibliotek natywnych za pomocą narzędzia APK Analyzer

APK Analyzer to narzędzie, które pozwala ocenić różne aspekty skompilowanego pliku APK. Użyj go, aby znaleźć biblioteki natywne i upewnić się, że są wśród nich biblioteki 64-bitowe.

1. Otwórz Android Studio i dowolny projekt.

2. Z menu wybierz Build > Analyze APK (Utwórz > Analizuj plik APK).

   

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

4. Zajrzyj do folderu lib, który zawiera pliki „.so” (jeśli są dostępne). Jeśli nie ma żadnych, oznacza to, że aplikacja obsługuje urządzenia 64-bitowe i nie musisz nic więcej robić. Jeśli widzisz armeabi-v7a lub x86, masz biblioteki 32-bitowe.

5. Sprawdź, czy w folderze arm64-v8a lub x86_64 masz podobne pliki „.so”.

   

6. Jeśli nie masz bibliotek arm64-v8a ani x86_64, zaktualizuj proces kompilacji, aby zacząć kompilować i pakować te artefakty w pliku APK.

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

Szukanie bibliotek natywnych przez rozpakowanie plików APK

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

Przejrzyj wyodrębnione pliki, postępując zgodnie z powyższymi wskazówkami, aby określić, czy aplikacja obsługuje urządzenia 64-bitowe. Możesz uruchomić ten przykładowy skrypt z poziomu wiersza poleceń:

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

Tworzenie aplikacji z bibliotekami 64-bitowymi

Poniżej znajdziesz instrukcje tworzenia bibliotek 64-bitowych. Pamiętaj, że te instrukcje dotyczą tylko kompilowania kodu i bibliotek, które można skompilować z kodu źródłowego.

Kompilowanie za pomocą Android Studio lub Gradle

Większość projektów Android Studio używa 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 architektury, którą 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 aplikacja została utworzona za pomocą CMake, możesz utworzyć 64-bitowe interfejsy ABI, przekazując arm64-v8a do parametru „-DANDROID_ABI”:

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

Kompilowanie za pomocą ndk-build

Jeśli aplikacja została utworzona za pomocą ndk-build, możesz ją skompilować pod kątem 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 na 64-bitowy

Jeśli kod działa już na komputerze lub iOS, nie musisz wykonywać żadnych dodatkowych czynności na Androidzie. Jeśli po raz pierwszy kompilujesz kod na system 64-bitowy, 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 long odpowiada rozmiarowi wskaźnika, ale nie dotyczy to systemu Windows. Zamiast tego użyj typów uintptr_t lub intptr_t, które wskazują intencję. Aby zapisać różnicę między 2 wskaźnikami, użyj typu ptrdiff_t.

Zawsze należy preferować określone typy liczb całkowitych o stałej szerokości zdefiniowane w <stdint.h>, a nie typy o niestałej szerokości, takie jak int lub long, nawet w przypadku typów innych niż wskaźniki.

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

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

Klasy Javy z polami int, które zawierają wskaźniki do obiektów C/C++, mają ten sam problem. Wyszukaj jint w kodzie źródłowym JNI i upewnij się, że przełączasz się na long po stronie Javy i na jlong po stronie C++.

Niejawne deklaracje funkcji są znacznie bardziej niebezpieczne w przypadku kodu 64-bitowego. C/C++ zakładają, że zwracany typ niejawnie zadeklarowanej funkcji (czyli funkcji, której deklaracji kompilator nie widział) to int. Jeśli rzeczywisty zwracany typ funkcji jest wskaźnikiem, działa to dobrze w systemie 32-bitowym, w którym wskaźnik mieści się w typie int. Jednak w systemie 64-bitowym kompilator odrzuca górną połowę wskaźnika. 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`.

Ta flaga kompilatora zmienia 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 zwykłej implementacji 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- i 64-bitowymi lub __arm__, __aarch64__ (arm64), __i386__ (x86) i __x86_64__ w przypadku konkretnych architektur obsługiwanych przez Androida.

Dostosuj ciągi formatujące dla funkcji takich jak printf lub scanf, ponieważ tradycyjne specyfikatory formatu nie pozwalają na określanie typów 64-bitowych w sposób prawidłowy zarówno dla urządzeń 32-bitowych, jak i 64-bitowych. Makra PRI i SCN w <inttypes.h> rozwiązują ten problem, PRIxPTR i SCNxPTR do zapisu i odczytu wskaźników szesnastkowych oraz PRId64 i SCNd64 do zapisu i odczytu wartości 64-bitowych w sposób przenośny.

Podczas przesunięcia może być konieczne użycie 1ULL, aby uzyskać 64-bitową stałą do przesunięcia, zamiast 1, która ma tylko 32 bity.

Ograniczanie wzrostu rozmiaru dzięki pakietowi Android App Bundle

Dodanie do aplikacji obsługi architektury 64-bitowej może spowodować zwiększenie rozmiaru pliku APK. Zdecydowanie zalecamy korzystanie z funkcji Android App Bundle, aby zminimalizować wpływ na rozmiar pliku APK, który zawiera zarówno 32-, jak i 64-bitowy kod natywny.

Deweloperzy gier

Trzy najczęściej używane silniki obsługują architekturę 64-bitową:

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

Deweloperzy Unity

Uaktualnij do wersji z odpowiednimi funkcjami

Unity zapewnia obsługę systemów 64-bitowych w wersjach 2018.2 i 2017.4.16.

Jeśli używasz wersji Unity, która nie obsługuje architektury 64-bitowej, określ wersję, do której chcesz przejść, i postępuj zgodnie z przewodnikami Unity, aby przenieść środowisko i uaktualnić aplikację do wersji, która umożliwia tworzenie bibliotek 64-bitowych. Unity zaleca uaktualnienie edytora do najnowszej wersji LTS, aby mieć dostęp do najnowszych funkcji i aktualizacji.

Oto tabela, która przedstawia różne wersje Unity i zalecane działania:

Zmień ustawienia kompilacji, aby generować biblioteki 64-bitowe.

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 na architekturę 64-bitową:

1. Otwórz Build Settings (Ustawienia kompilacji) i upewnij się, że kompilujesz na Androida, sprawdzając, czy symbol Unity znajduje się obok opcji Android w sekcji Platform (Platforma). 1. Jeśli obok platformy Android nie ma symbolu Unity, wybierz Android i kliknij Switch Platform (Przełącz platformę).

2. Kliknij Ustawienia odtwarzacza.

   

3. Kliknij Panel ustawień odtwarzacza > Ustawienia Androida > Inne ustawienia > Konfiguracja.

4. Ustaw Skryptowy backend na IL2CPP.

5. Zaznacz pole wyboru Target Architecture > ARM64 (Architektura docelowa > ARM64).

   

6. Buduj jak zwykle.

Pamiętaj, że kompilowanie na platformę ARM64 wymaga, aby wszystkie zasoby były skompilowane specjalnie na tę platformę. Postępuj zgodnie ze wskazówkami Unity dotyczącymi zmniejszania rozmiaru pliku APK i rozważ skorzystanie z funkcji pakietu Android App Bundle, aby ograniczyć wzrost rozmiaru.

Zgodność z wymaganiami dotyczącymi wielu plików APK i architektury 64-bitowej

Jeśli do publikowania aplikacji używasz obsługi wielu plików APK w Google Play, pamiętaj, że zgodność z wymaganiem dotyczącym 64 bitów jest oceniana na poziomie wersji. Wymóg dotyczący wersji 64-bitowej 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 to wcześniejsza wersja i nie można jej dostosować do zasad, możesz dodać atrybut maxSdkVersion="27" w elemencie uses-sdk w pliku manifestu tego pliku APK. Ten pakiet APK nie jest dostarczany na urządzenia z Androidem 9 Pie lub nowszym i nie blokuje już zgodności.

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

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

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

Testowanie aplikacji na sprzęcie 64-bitowym

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

Urządzenia obsługujące tylko architekturę 64-bitową

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

• Google Pixel z obrazem systemu tylko w wersji 64-bitowej
• Android Emulator

Google Pixel z obrazem systemu tylko w wersji 64-bitowej,

Aby ułatwić tworzenie i testowanie aplikacji, udostępniliśmy specjalne obrazy systemowe ze środowiskiem wyłącznie 64-bitowym dla niektórych urządzeń Pixel. Te obrazy tylko w wersji 64-bitowej były pierwotnie udostępniane równolegle ze standardowymi fabrycznymi obrazami systemu w przypadku wersji testowych Androida 13 i 14, ale możesz nadal ich używać podczas testowania aplikacji pod kątem zgodności z architekturą 64-bitową.

Pobieranie obrazu tylko w wersji 64-bitowej

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

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

Android Flash Tool umożliwia bezpieczne wgranie obrazu systemu na obsługiwane urządzenie Pixel. Narzędzie Android Flash Tool działa w każdej przeglądarce 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 trzeba 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 zainstalować, otwórz narzędzie Android Flash Tool, korzystając z jednego z poniższych 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ć system:

  • 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ć system:

  • 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 zainstalować go na urządzeniu. W tabeli poniżej znajdziesz obraz systemu do pobrania na urządzenie testowe. Ręczne flashowanie urządzenia jest przydatne, gdy potrzebujesz precyzyjnej kontroli nad środowiskiem testowym lub gdy musisz często przeprowadzać ponowną instalację, np. podczas testów automatycznych.

Po utworzeniu kopii zapasowej danych z urządzenia i pobraniu odpowiedniego obrazu systemu możesz zainstalować obraz na urządzeniu.

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

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

Te obrazy zapewniają środowisko wyłącznie 64-bitowe do testowania zgodności aplikacji 64-bitowych. Te konfiguracje tylko 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 wyłącznie 64-bitowe do testowania zgodności aplikacji 64-bitowych. Te konfiguracje tylko 64-bitowe są przeznaczone wyłącznie dla deweloperów.

Powrót 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 z obrazami fabrycznymi dla urządzeń Nexus i Pixel, a następnie ręcznie wgrać go na urządzenie.

Android Emulator

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

Inne opcje urządzenia

Jeśli nie masz żadnego z tych urządzeń lub nie możesz użyć emulatora Androida, najlepiej użyć urządzenia obsługującego architekturę 64-bitową, takiego jak Google Pixel lub inne flagowe urządzenie innego producenta.

Instalowanie i testowanie aplikacji

Najprostszym sposobem na przetestowanie pakietu 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 aplikacji tylko z bibliotekami 64-bitowymi na urządzeniu.

:: 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ślnym zainstalowaniu 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 wpływają na działanie aplikacji na urządzeniach 64-bitowych. Nawet jeśli aplikacja nie bazuje bezpośrednio na bibliotekach, których dotyczy problem, mogą na nich polegać biblioteki i pakiety SDK innych firm, od których zależy aplikacja.

SoLoader

Jeśli używasz pakietu SDK do wczytywania kodu natywnego SoLoader, zaktualizuj go do wersji 0.10.4 lub nowszej. Jeśli aplikacja używa pakietów SDK, które zależą od pakietu SoLoader, zaktualizuj też te pakiety do najnowszej stabilnej wersji.

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

Więcej informacji o rozwiązywaniu tego i innych problemów powodowanych 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 używa pakietów SDK, które zapewniają komunikację przez protokół HTTPS, lub innych pakietów SDK, które bazują na OpenSSL, zaktualizuj je do najnowszej wersji, która używa nowszej wersji OpenSSL. Jeśli nie jest dostępna, 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 lub nowszej.

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

BTI

ARMv8.5 i nowsze wersje używają instrukcji Branch Target Instructions (BTI), aby chronić przed atakami JOP. Wcześniejsze wersje pakietów SDK do zaciemniania kodu, które rozgałęziają się na losowe przesunięcia bibliotek utworzonych za pomocą BTI, mogą powodować awarie aplikacji. Instrukcje są kodowane jako HINT, więc ten błąd nie jest widoczny na urządzeniach, które nie obsługują BTI.

Opublikuj

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

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