Obsługa architektury 64-bitowej

Aplikacje opublikowane w Google Play muszą obsługiwać architektury 64-bitowe. Dodanie 64-bitowej wersji aplikacji zapewnia większą wydajność i umożliwia korzystanie z urządzeń z wyłącznie 64-bitowym sprzętem.

Wykonaj te czynności, aby aplikacja 32-bitowa obsługiwała 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, sprawdź ją.

Szybkie sprawdzenie stanu

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

Konsola Play wyświetla też ostrzeżenia dotyczące wersji roboczych, jeśli występują w nich problemy związane z wymogiem dotyczącym kodu 64-bitowego. Przykładem jest poniższy obraz.

Jeśli pojawi się alert, wykonaj te czynności, aby zapewnić zgodność aplikacji z urządzeniami 64-bitowymi.

Czy Twoja aplikacja korzysta z kodu natywnego?

Aplikacja korzysta z kodu natywnego, jeśli:

• zawiera w aplikacji kod C/C++ (natywny);
• linki do zewnętrznych bibliotek natywnych,
• została stworzona przez zewnętrznego twórcę aplikacji, który używa bibliotek natywnych;

Czy Twoja aplikacja zawiera biblioteki 64-bitowe?

Sprawdź strukturę pliku APK. Po skompilowaniu plik APK jest pakowany z bibliotekami natywne, których potrzebuje aplikacja. Biblioteki natywne są przechowywane w różnych folderach na podstawie ABI. Nie musisz obsługiwać wszystkich architektur 64-bitowych, ale w przypadku każdej obsługiwanej architektury natywnej 32-bitowej musisz uwzględnić odpowiadającą architekturę 64-bitową.

W przypadku architektury ARM biblioteki 32-bitowe znajdują się w pliku armeabi-v7a. Jego odpowiednikiem w wersji 64-bitowej jest arm64-v8a.

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

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

Pamiętaj, że w zależności od aplikacji w każdym folderze może się znajdować ten sam zestaw bibliotek lub nie. Celem jest zapewnienie prawidłowego działania aplikacji w środowisku tylko 64-bitowym.

W typowym przypadku plik APK lub pakiet utworzony na architektury 32- i 64-bitowe zawiera foldery dla obu ABI, z odpowiednim zestawem bibliotek natywnych. Jeśli nie ma obsługi 64-bitowej, możesz zobaczyć folder 32-bitowy ABI, ale nie 64-bitowy.

Wyszukiwanie bibliotek natywnych za pomocą narzędzia APK Analyzer

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

1. Otwórz Android Studio i otwórz dowolny projekt.

2. W menu wybierz Utwórz > Przeanalizuj plik APK…

   

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

4. Sprawdź folder lib, w którym znajdują się pliki „.so” (jeśli w ogóle są). Jeśli nie ma żadnych, oznacza to, że aplikacja obsługuje urządzenia 64-bitowe i nie musisz nic robić. Jeśli widzisz armeabi-v7a lub x86, 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ąć kompilowanie i pakowanie tych artefaktów w pliku APK.

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

Wyszukiwanie bibliotek natywnych przez rozpakowanie plików APK

Pliki APK są ustrukturyzowane jak pliki 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 przemianowanie pliku na .zip.

Przejrzyj wyodrębnione pliki, aby ustalić, czy Twoja aplikacja obsługuje urządzenia 64-bitowe. Z wiersza poleceń możesz uruchomić ten przykład polecenia:

:: 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 użyciem bibliotek 64-bitowych

W podanych niżej instrukcjach opisano, jak skompilować biblioteki 64-bitowe. Pamiętaj, że te kroki dotyczą tylko kompilowania kodu i bibliotek, które możesz skompilować na podstawie kodu źródłowego.

Kompilowanie w Android Studio lub Gradle

Większość projektów w Android Studio korzysta z Gradle jako podstawowego systemu kompilacji, więc ten rozdział dotyczy obu tych przypadków. Aby włączyć kompilacje dla 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 skompilowana za pomocą CMake, możesz ją skompilować na potrzeby 64-bitowych ABI, przekazując parametr 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 skompilowana za pomocą narzędzia ndk-build, możesz ją skompilować na potrzeby 64-bitowych 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 komputerach lub urządzeniach z iOS, nie musisz nic robić, aby działał na Androidzie. Jeśli Twój kod jest kompilowany po raz pierwszy na system 64-bitowy, musisz rozwiązać główny problem, jakim jest to, że wskaźniki nie mieszczą się już w typach całkowitych 32-bitowych, 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 nie jest tak w systemie Windows. Zamiast tego użyj typów uintptr_t lub intptr_t, które ujawniają intencję. Aby przechowywać różnicę między 2 wskaźnikami, użyj typu ptrdiff_t.

Zawsze wybieraj konkretne typy liczb całkowitych o stałyej szerokości zdefiniowane w <stdint.h>, a nie typy o niestałej szerokości, takie jak int czy long, nawet w przypadku typów niewskaźnikowych.

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 klasach Java, które mają pola int zawierające wskaźniki do obiektów C/C++. W źródle JNI wyszukaj jint i upewnij się, że przełączysz się na long po stronie Javy i jlong po stronie C++.

Domyślne deklaracje funkcji są znacznie bardziej niebezpieczne w przypadku kodu 64-bitowego. W C/C++ zakłada się, że typ zwracany przez funkcję zadeklarowaną domyślnie (czyli funkcję, której kompilator nie widział w deklaracji) to int. Jeśli rzeczywisty typ zwracany przez funkcję to wskaźnik, to na systemie 32-bitowym działa to dobrze, ponieważ wskaźnik mieści się w typie int. Jednak na 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`.

Ten parametr kompilatora zmienia ostrzeżenia o ukrytej deklaracji funkcji w błędy, dzięki czemu łatwiej znajdziesz i naprawisz ten problem:

-Werror=implicit-function-declaration

Jeśli masz kod asemblera w wierszu, 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 chcesz warunkowo kompilować inny kod na architekturze 32-bitowej niż 64-bitowej, możesz użyć #if defined(__LP64__) w przypadku ogólnych różnic między 32-bitową a 64-bitową lub __arm__, __aarch64__ (arm64), __i386__ (x86) i __x86_64__ w przypadku konkretnych architektur obsługiwanych przez Androida.

Dostosuj ciągi formatu w przypadku funkcji printf lub podobnych do funkcji scanf, ponieważ tradycyjne specyfikatory formatu nie umożliwiają określania typów 64-bitowych w sposób odpowiedni zarówno w przypadku urządzeń 32-bitowych, jak i 64-bitowych. Ten problem rozwiązują makro PRI i SCN w <inttypes.h>, PRIxPTR i SCNxPTR do zapisywania i odczytywania wskaźników szesnastkowych oraz PRId64 i SCNd64 do zapisywania i odczytywania wartości 64-bitowych.

Podczas przesunięcia może być konieczne użycie wartości 1ULL, aby uzyskać 64-bitową stałą, zamiast wartości 1, która jest tylko 32-bitowa.

Minimalizowanie zwiększania rozmiaru dzięki pakietom aplikacji na Androida

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 rozmiaru na kod natywny 32- i 64-bitowy w tym samym pliku APK.

Deweloperzy gier

3 najczęściej używane mechanizmy obsługują 64-bitowe:

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

Deweloperzy Unity

Przejście na wersje obsługujące tę funkcję

Unity obsługuje systemy 64-bitowe 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 przewodnikiem Unity dotyczącym migracji środowiska, aby mieć pewność, że aplikacja zostanie zaktualizowana do wersji, która umożliwia tworzenie bibliotek 64-bitowych. Unity zaleca zaktualizowanie edytora do najnowszej wersji LTS, aby mieć dostęp do najnowszych funkcji i aktualizacji.

Oto tabela z informacjami o różnych wersjach Unity i zalecanych działaniach:

Zmień ustawienia kompilacji, aby wygenerować 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 skryptowego. Aby skonfigurować projekt Unity do kompilacji architektury 64-bitowej, wykonaj te czynności:

1. Otwórz Ustawienia kompilacji i upewnij się, że kompilujesz na Androida. Aby to sprawdzić, obok pozycji Android w sekcji Platforma powinien znajdować się symbol Unity. 1. Jeśli symbol Unity nie znajduje się obok platformy Android, wybierz Android i kliknij Przełącz platformę.

2. Kliknij Ustawienia odtwarzacza.

   

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

4. Ustaw Backend skryptu na IL2CPP.

5. Zaznacz pole wyboru Architektura docelowa > ARM64.

   

6. Buduj jak zwykle.

Pamiętaj, że kompilacja na ARM64 wymaga skompilowania wszystkich zasobów specjalnie na tę platformę. Postępuj zgodnie z wytycznymi Unity dotyczącymi zmniejszania rozmiaru pliku APK i rozważ skorzystanie z funkcji pakietu aplikacji na Androida, aby ograniczyć wzrost rozmiaru.

Zgodność z wymaganiami dotyczącymi wielu plików APK i obsługi 64-bitów

Jeśli korzystasz z obsługi wielu plików APK w Google Play, aby opublikować aplikację, pamiętaj, że zgodność z wymogiem obsługi kodu 64-bitowego jest oceniana na poziomie wersji. Wymagania dotyczące kodu 64-bitowego nie dotyczą 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 plików APK jest oznaczony jako niezgodny z zasadami, ale jest to starsza wersja i nie można jej dostosować do wymagań, jedną z możliwości jest dodanie atrybutu maxSdkVersion="27" w elemencie uses-sdk w pliku manifestu tego pliku APK. Plik APK nie jest dostarczany na urządzenia z Androidem 9 Pie lub nowszym i nie blokuje już zgodności.

Renderowanie i zgodność z kodem 64-bitowym

Jeśli Twoja aplikacja korzysta z RenderScript i została skompilowana za pomocą starszej wersji narzędzi Android, możesz napotkać problemy z zgodnością z urządzeniami 64-bitowymi. W przypadku narzędzi do kompilacji starszych niż 21.0.0 kompilator może wygenerować kod bitowy w zewnętrznym pliku .bc. Te starsze pliki .bc nie są już obsługiwane w architekturach 64-bitowych, więc obecność takiego pliku w pliku APK powoduje problemy 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 lub nowszą, aby powiedzieć kompilatorowi, że nie ma emitować plików .bc. Następnie ponownie skompiluj aplikację, sprawdź, czy nie zawiera plików .bc, i prześlij ją do Konsoli Play.

Testowanie aplikacji na sprzęcie 64-bitowym

64-bitowa wersja aplikacji powinna zapewniać taką samą jakość i taki sam zestaw funkcji jak wersja 32-bitowa. Przetestuj aplikację, aby mieć pewność, że użytkownicy korzystający z najnowszych urządzeń 64-bitowych będą zadowoleni z jej działania.

Urządzenia tylko 64-bitowe

Jeśli to możliwe, zalecamy przetestowanie aplikacji w ściśle 64-bitowym środowisku, korzystając z jednego z tych rozwiązań:

• Google Pixel z obrazem systemu tylko 64-bitowym
• Emulator Androida

Google Pixel z obrazem systemu tylko 64-bitowym

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

Pobieranie obrazu w wersji 64-bitowej

Podobnie jak w przypadku obrazów fabrycznych, możesz zainstalować obraz tylko 64-bitowy na urządzeniu za pomocą narzędzia do flashowania Androida lub ręcznie, jak opisano w następnych sekcjach.

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

Narzędzia do flashowania Androida umożliwiają bezpieczne flashowanie obrazu systemu na obsługiwanym urządzeniu Pixel. Narzędzie Android Flash Tool działa z dowolną przeglądarką internetową obsługującą WebUSB, np. Chrome lub Edge w wersji 79 lub nowszej.

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

Połącz urządzenie przez USB, a potem, w zależności od typu obrazu systemu, który chcesz zastosować, otwórz narzędzie do flashowania Androida, korzystając z jednego z tych linków:

• Obrazy systemowe Androida 14 (wersja 5.2, tylko 64-bitowe)

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

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

• Obrazy systemowe Androida 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 chcesz mieć większą kontrolę nad środowiskiem testowym lub często musisz ponownie instalować oprogramowanie, np. podczas testowania automatycznego.

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

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

obrazy fabryczne w wersji 64-bitowej dla Androida 14 (wersja beta 5.3);

Te obrazy zapewniają ściśle 64-bitowe środowisko do testowania zgodności aplikacji 64-bitowych. Te konfiguracje tylko dla wersji 64-bitowej są przeznaczone tylko dla deweloperów.

obrazy fabryczne w wersji 64-bitowej dla Androida 13 (QPR3 Beta 3.2);

Te obrazy zapewniają ściśle 64-bitowe środowisko do testowania zgodności aplikacji 64-bitowych. Te konfiguracje tylko dla wersji 64-bitowej są przeznaczone tylko dla deweloperów.

Powrót do wersji publicznej

Możesz użyć narzędzia do flashowania Androida, aby wgrać obraz fabryczny, lub pobrać obraz systemu z specyfikacją fabryczną ze strony Obrazy fabryczne dla urządzeń Nexus i Pixel, a następnie ręcznie wgrać go na urządzenie.

Emulator Androida

Od Androida 12 (poziom interfejsu API 31) obrazy systemów w Emulatorze Androida są tylko 64-bitowe. Utwórz urządzenie wirtualne Androida (AVD), używając obrazu systemu z Androidem 12 (poziom interfejsu API 31) lub nowszym, aby uzyskać ściśle 64-bitowe środowisko do testowania aplikacji.

Inne opcje urządzenia

Jeśli nie masz żadnego z tych urządzeń lub nie możesz korzystać z 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ć parametr --abi, aby wskazać, które biblioteki mają zostać zainstalowane na urządzeniu. W ten sposób zainstalujesz na urządzeniu aplikację z tylko 64-bitowymi bibliotekami.

:: 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 zakończeniu instalacji przetestuj aplikację w zwykły sposób, aby upewnić się, że jej jakość jest taka sama jak w wersji 32-bitowej.

Sprawdzanie, czy występują znane problemy ze zgodnością

Podczas testowania sprawdź, czy aplikacja nie ma niżej wymienionych problemów, które wpływają na aplikacje działające na urządzeniach 64-bitowych. Nawet jeśli aplikacja nie bazuje bezpośrednio na dotkniętych bibliotekach, zewnętrzne biblioteki i pakiety SDK, na których polega aplikacja, mogą na nich bazować.

SoLoader

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

W wersjach SoLoader w wersji 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 powoduje on 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 odpowiedniej odpowiedzi 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, zaktualizuj też pakiet SDK do najnowszej wersji, która korzysta z nowszej wersji OpenSSL. Jeśli pakiet SDK jest niedostępny, skontaktuj się z dostawcą.

ARMv8.3 PAC umożliwia działanie wspomaganego sprzętowo mechanizmu integralności przepływu sterowania 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 ARMv8.3a lub nowszych.

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

BTI

ARMv8.5 i nowsze wersje używają instrukcji docelowych gałęzi (BTI), aby chronić przed atakami JOP. Starsze wersje zaciemnionego pakietu SDK, które odgałęziają się do losowych przesunięć bibliotek utworzonych za pomocą BTI, mogą powodować awarie aplikacji. Instrukcje są kodowane jako wskazówki, 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 zwykły sposób. Jak zawsze pamiętaj o przestrzeganiu sprawdzonych metod wdrażania aplikacji. Zalecamy korzystanie ze ścieżek testów zamkniętych, aby udostępnić aplikację ograniczonej liczbie użytkowników i zadbać o jej spójną jakość.

Podobnie jak w przypadku wprowadzania istotnych aktualizacji, przed opublikowaniem aktualizacji dla większej liczby użytkowników należy dokładnie przetestować ją na urządzeniach z procesorami 64-bitowymi.