Obsługa architektury 64-bitowej

Aplikacje opublikowane w Google Play muszą obsługiwać architekturę 64-bitową. Dodanie 64-bitowej wersji aplikacji zwiększa wydajność i umożliwia korzystanie z urządzenia ze sprzętem 64-bitowym.

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

Ocena aplikacji

Jeśli Twoja aplikacja korzysta tylko z kodu napisanego w języku Java lub w Kotlin (w tym wszystkich bibliotek i pakietów SDK), obsługuje urządzenia 64-bitowe. Jeśli Twoja aplikacja korzysta z kodu natywnego lub nie masz pewności, czy tak jest, oceń ją.

Szybkie sprawdzanie stanu

Otwórz Konsolę Play i przejrzyj istniejące wersje, by sprawdzić, czy są z nimi zgodne.

Jeśli wystąpią problemy związane z wymaganiami wersji 64-bitowej, w Konsoli Play pojawią się ostrzeżenia dotyczące wersji roboczej. Ilustracja poniżej to przykład.

Jeśli pojawi się alert, wykonaj poniższe czynności, aby zapewnić zgodność aplikacji na urządzeniach 64-bitowych.

Czy Twoja aplikacja używa kodu natywnego?

Aplikacja używa kodu natywnego, jeśli:

• Użycie dowolnego natywnego kodu C/C++ w aplikacji.
• linki do wszelkich zewnętrznych bibliotek natywnych.
• zostało utworzone w zewnętrznym kreatorze aplikacji, który korzysta z bibliotek natywnych;

Czy Twoja aplikacja zawiera biblioteki 64-bitowe?

Sprawdź strukturę pliku APK. Po utworzeniu plik APK jest umieszczany w pakiecie ze wszystkimi bibliotekami natywnymi wymaganymi przez aplikację. Biblioteki natywne są przechowywane w różnych folderach w zależności od interfejsu ABI. Nie jest wymagana obsługa każdej architektury 64-bitowej, ale w przypadku każdej obsługiwanej architektury 32-bitowej musisz uwzględnić odpowiednią architekturę 64-bitową.

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

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

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

Pamiętaj, że w zależności od aplikacji każdy folder może zawierać dokładnie ten sam zestaw bibliotek. Chodzi o to, aby aplikacja działała prawidłowo w środowisku 64-bitowym.

Zwykle plik APK lub pakiet utworzony dla architektur 32- i 64-bitowych zawiera foldery dla obu interfejsów ABI, każdy z odpowiednim zestawem bibliotek natywnych. Jeśli wersja 64-bitowa nie jest obsługiwana, możesz zobaczyć folder 32-bitowy ABI, ale nie 64-bitowy.

Wyszukaj biblioteki natywne za pomocą Analizatora plików APK

Analizator plików APK to narzędzie umożliwiające ocenę różnych aspektów skompilowanego pliku APK. Za jego pomocą możesz znaleźć wszystkie biblioteki natywne i sprawdzić, czy są dostępne biblioteki 64-bitowe.

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

2. Z menu wybierz Kompilacja > Analizuj plik APK...

   

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

4. Przejdź do folderu lib, który zawiera ewentualne pliki „.so”. Jeśli ich nie ma, oznacza to, że aplikacja obsługuje urządzenia 64-bitowe i nie trzeba podejmować żadnych działań. Jeśli widzisz wersję 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 żadnych bibliotek arm64-v8a ani x86_64, zaktualizuj proces kompilacji, aby zacząć tworzyć i pakować te artefakty w pliku APK.

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

Wyszukaj biblioteki natywne, rozpakowując pliki APK

Pliki APK mają strukturę podobną do plików ZIP. Rozpakuj 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 sprawdzić, czy aplikacja obsługuje urządzenia 64-bitowe. Możesz uruchomić to przykładowe polecenie 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ę na obecność bibliotek armeabi-v7a i arm64-v8a, co oznacza, że aplikacja obsługuje architektury 64-bitowe.

Tworzenie aplikacji przy użyciu 64-bitowych bibliotek

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

Kompilowanie w Android Studio lub Gradle

Większość projektów Android Studio używa Gradle jako bazowego systemu kompilacji, więc ta sekcja dotyczy obu przypadków. Aby włączyć kompilacje dla 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")
        }
// ...

Build with CMake

Jeśli Twoja aplikacja została utworzona przy użyciu CMake, możesz ją utworzyć na potrzeby 64-bitowego kodu ABI, przesyłając parametr arm64-v8a do parametru „-DANDROID_ABI”:

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

Tworzenie z użyciem narzędzia ndk-build

Jeśli Twoja aplikacja została skompilowana za pomocą polecenia ndk-build, możesz ją utworzyć na potrzeby 64-bitowych interfejsów ABI, modyfikując plik Application.mk za pomocą zmiennej APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Port 32-bitowy na kod 64-bitowy

Jeśli Twój kod działa już na komputerze lub w iOS, nie musisz robić nic więcej w przypadku Androida. Jeśli po raz pierwszy tworzysz kod pod kątem systemu 64-bitowego, musisz przede wszystkim rozwiązać ten problem, ponieważ wskaźniki nie pasują już do 32-bitowych liczb całkowitych, takich jak int.

Zaktualizuj kod, który przechowuje wskaźniki w typach takich jak int, unsigned lub uint32_t. W systemach typu Unix wartość long odpowiada rozmiarowi wskaźnika, ale w systemie Windows ta informacja nie jest prawidłowa. Zamiast tego użyj typów określających zamiary: uintptr_t lub intptr_t. Aby zapisać różnicę między 2 wskaźnikami, użyj typu ptrdiff_t.

Nawet w przypadku elementów, które nie są wskaźnikami, lepiej zawsze korzystać z określonych typów liczb całkowitych o stałej szerokości zdefiniowanych w <stdint.h> zamiast typów o niestałej szerokości, takich jak int lub long.

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

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

Ten sam problem występuje w klasach Java z polami int, które zawierają wskaźniki do obiektów C/C++. Wyszukaj jint w źródle JNI i upewnij się, że przełączono na long po stronie Java i jlong po stronie C++.

Deklaracje funkcji niejawnych są znacznie bardziej niebezpieczne w przypadku 64-bitowego kodu. W C/C++ zakładamy, że zwracany niejawnie funkcja (czyli funkcja, dla której kompilator nie widział deklaracji) to int. Jeśli rzeczywisty zwrot Twojej funkcji jest wskaźnikiem, działa to dobrze w systemie 32-bitowym, w którym wskaźnik mieści się w systemie int. W systemie 64-bitowym kompilator usuwa jednak 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`.

Ta flaga kompilatora zamienia ostrzeżenia w deklaracji niejawnych funkcji w błędy, aby ułatwić Ci znalezienie i naprawienie tego problemu:

-Werror=implicit-function-declaration

Jeśli masz wbudowany program Assemb, przeredaguj go lub użyj zwykłej implementacji w języku C/C++.

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

Jeśli musisz warunkowo skompilować inny kod w przypadku architektur 32-bitowych niż 64-bitowych, możesz użyć polecenia #if defined(__LP64__), aby uzyskać informacje o różnicach w formacie 32/64, lub kodu __arm__, __aarch64__ (arm64), __i386__ (x86) i __x86_64__ dla architektur obsługiwanych przez Androida.

Dostosuj ciągi formatu dla funkcji printf i scanf, ponieważ tradycyjne specyfikatory formatów nie pozwalają na określanie typów 64-bitowych w sposób odpowiedni dla urządzeń 32-bitowych i 64-bitowych. Makra PRI i SCN w <inttypes.h> rozwiązują ten problem, PRIxPTR i SCNxPTR do zapisywania i odczytywania wskaźników szesnastkowych oraz PRId64 i SCNd64 do mobilnego zapisywania i odczytywania wartości 64-bitowych.

Podczas zmiany może być konieczne użycie 1ULL do uzyskania 64-bitowej stałej do zmiany, zamiast użycia metody 1, która ma tylko 32 bity.

Ograniczanie wzrostu rozmiaru za pomocą pakietu Android App Bundle

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

Deweloperzy gier

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

• Nierealistyczne od 2015 roku
• Cocos2d od 2015 r.
• Unity od 2018 roku

Programiści Unity

Uaktualnij do wersji, które obsługują tę funkcję

Unity zapewnia 64-bitową obsługę w wersjach 2018.2 i 2017.4.16.

Jeśli używasz wersji Unity, która nie obsługuje wersji 64-bitowej, wybierz wersję, na którą chcesz przejść, i postępuj zgodnie z instrukcjami Unity, aby przenieść środowisko, upewniając się, że Twoja aplikacja zostanie uaktualniona do wersji umożliwiającej kompilowanie 64-bitowych bibliotek. Unity zaleca dostęp do najnowszych funkcji i aktualizacji przez uaktualnienie edytora do najnowszej wersji LTS.

W tej tabeli opisujemy różne wersje Unity i informacje o tym, co należy zrobić:

Zmień ustawienia kompilacji, aby wyświetlać 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 obsługi skryptów. Aby skonfigurować w projekcie Unity kompilację architektury 64-bitowej, wykonaj te czynności:

1. Otwórz Ustawienia kompilacji i sprawdź, czy tworzysz aplikację na Androida, sprawdzając, czy w sekcji Platforma obok pozycji Android znajduje się symbol Unity. 1. Jeśli obok platformy Androida nie ma symbolu Unity, wybierz Android i kliknij Przełącz platformę.

2. Kliknij Ustawienia odtwarzacza.

   

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

4. Ustaw Backend dla skryptów na IL2CPP.

5. Zaznacz pole wyboru Architektura docelowa > ARM64.

   

6. Buduj jak zwykle!

Pamiętaj, że kompilowanie pod kątem ARM64 wymaga utworzenia wszystkich zasobów specjalnie pod kątem tej platformy. Postępuj zgodnie ze wskazówkami Unity dotyczącymi zmniejszania rozmiaru pliku APK i rozważ skorzystanie z funkcji Android App Bundle, która pomoże ograniczyć ten wzrost.

Zgodność z wieloma plikami APK i standardem 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 wersji 64-bitowej jest oceniana na poziomie wersji. Wymagania dotyczące wersji 64-bitowej nie mają jednak zastosowania do plików APK ani pakietów aplikacji, które nie są rozpowszechniane na urządzenia z Androidem 9 Pie lub nowszym.

Jeśli jeden z Twoich plików APK jest oznaczony jako niezgodny, ale jest we wcześniejszej wersji i nie można zapewnić zgodności, jedną ze strategii jest dodanie atrybutu 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.

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

Jeśli Twoja aplikacja korzysta z języka RenderScript i została skompilowana we wcześniejszej wersji narzędzi na Androida, mogą wystąpić problemy ze zgodnością aplikacji z wersjami 64-bitowymi. W przypadku narzędzi do kompilacji starszych niż 21.0.0 kompilator może wygenerować 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ń wszystkie pliki.bc z projektu, uaktualnij środowisko do wersji build-tools-21.0.0 lub nowszej i ustaw renderscriptTargetApi w Android Studio na wersję 21 lub nowszą, aby kompilator nie emitował plików .bc. Następnie ponownie skompiluj aplikację, sprawdź pliki .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 mogą korzystać z niej jak najlepiej.

Urządzenia 64-bitowe

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

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

Google Pixel z 64-bitowym tylko obrazem systemu

Aby ułatwić tworzenie i testowanie aplikacji, na niektórych urządzeniach Pixel udostępniliśmy specjalne obrazy systemu w środowisku 64-bitowym. Te 64-bitowe obrazy zostały pierwotnie dostarczone razem ze standardowymi obrazami systemu fabrycznego na potrzeby wersji przedpremierowych Androida 13 i 14, ale możesz ich nadal używać podczas testowania aplikacji pod kątem zgodności z wersją 64-bitową.

Pobierz obraz 64-bitowy

Podobnie jak w przypadku obrazów systemu fabrycznego, możesz przy użyciu narzędzia Android Flash lub ręcznie załadować urządzenie zgodnie z opisem w kolejnych sekcjach.

flashowanie urządzenia, korzystając z narzędzia Android Flash Tool

Narzędzie Android Flash pozwala w bezpieczny sposób zainstalować obraz systemowy na obsługiwanym urządzeniu Pixel. Android Flash Tool działa z każdą przeglądarką obsługującą WebUSB, np. Chrome czy Edge 79 lub nowszą.

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

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

• Tylko 64-bitowe obrazy systemowe Androida 14 (beta 5.2)

  Wybierz urządzenie, które chcesz zamigać:

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

• Tylko 64-bitowe obrazy systemowe Androida 13 (QPR3 Beta 3.2)

  Wybierz urządzenie, które chcesz zamigać:

  • 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. W tabeli poniżej znajdziesz obraz systemu urządzenia testowego. Ręczna aktualizacja urządzenia jest przydatna, gdy potrzebujesz dokładnej kontroli nad środowiskiem testowym lub jeśli musisz często instalować ponownie urządzenie, 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 wrócić do najnowszej publicznej kompilacji.

Tylko 64-bitowe obrazy fabryczne na Androida 14 (beta 5.3)

Obrazy te zapewniają rygorystyczne, 64-bitowe środowisko do testowania zgodności aplikacji z architekturą 64-bitową. Te konfiguracje 64-bitowe są przeznaczone tylko dla programistów.

Tylko 64-bitowe obrazy fabryczne na Androida 13 (QPR3 Beta 3.2)

Obrazy te zapewniają rygorystyczne, 64-bitowe środowisko do testowania zgodności aplikacji z architekturą 64-bitową. Te konfiguracje 64-bitowe są przeznaczone tylko dla programistów.

Wróć do publicznej kompilacji

Możesz użyć narzędzia Android Flash Tool, aby załadować obraz fabryczny, lub uzyskać obraz systemu operacyjnego zgodny ze specyfikacją fabryczną na stronie Obrazy fabryczne dla urządzeń Nexus i Pixel, a następnie ręcznie zainstalować go na urządzeniu.

Emulator Androida

Od Androida 12 (poziom interfejsu API 31) obrazy systemowe emulatora Androida są tylko 64-bitowe. Utwórz urządzenie wirtualne z Androidem (AVD) za pomocą obrazu systemowego z Androidem 12 (poziom interfejsu API 31) lub nowszym, aby uzyskać rygorystyczne, 64-bitowe środowisko do testowania aplikacji.

Inne opcje urządzenia

Jeśli nie masz jednego z tych urządzeń lub nie możesz użyć emulatora Androida, kolejnym najlepszym rozwiązaniem jest użycie urządzenia 64-bitowego, np. Google Pixela lub innego flagowego urządzenia innych producentów.

Instalowanie i testowanie aplikacji

Najłatwiejszym sposobem przetestowania pakietu APK jest zainstalowanie aplikacji za pomocą narzędzia Android DebugBridge (adb). W większości przypadków możesz podać --abi jako parametr, aby wskazać, które biblioteki należy zainstalować na urządzeniu. Spowoduje to zainstalowanie na urządzeniu tylko 64-bitowych bibliotek.

:: 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 zainstalowaniu przetestuj aplikację w zwykły sposób, by mieć pewność, że jej jakość będzie taka sama jak w wersji 32-bitowej.

Sprawdzanie znanych problemów ze zgodnością

Podczas testowania aplikacji na urządzeniach 64-bitowych sprawdź, czy nie występują w niej wymienione poniżej problemy. Nawet jeśli aplikacja nie bazuje bezpośrednio na bibliotekach, których dotyczy problem, w zależnościach od niej mogą występować biblioteki innych firm i pakiety SDK.

Komponent SoLoader

Jeśli używasz natywnego pakietu SDK SoLoader do wczytywania kodu, zaktualizuj go do wersji 0.10.4 lub nowszej. Jeśli Twoja aplikacja korzysta z pakietów SDK zależnych od SoLoader, pamiętaj też o zaktualizowaniu pakietów SDK, których dotyczy problem, do najnowszej stabilnej wersji.

SoLoader w wersji 0.9.0 lub starszej zakłada, że w /vendor/lib:/system/lib znajdują się biblioteki systemowe. Tego błędu nie można zaobserwować na urządzeniach takich jak Pixel 7 tam, gdzie ścieżka istnieje, ale założenie powoduje awarie na urządzeniach, które mają w /vendor/lib64:/system/lib64 tylko biblioteki systemowe.

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

OpenSSL

Jeśli używasz biblioteki OpenSSL, przejdź na OpenSSL w wersji 1.1.1i lub nowszej. Jeśli Twoja aplikacja korzysta z pakietów SDK obsługujących komunikację HTTPS lub innych pakietów zależnych od OpenSSL, zaktualizuj też pakiet do najnowszej wersji, który korzysta z nowszej wersji OpenSSL. Jeśli pakiet SDK nie jest dostępny, skontaktuj się z dostawcą.

ARMv8.3 PAC umożliwia wspomaganie sprzętowe sterowanie przepływem sterowania przez uwierzytelnianie wskaźników w czasie działania. Wcześniejsze wersje OpenSSL nieprawidłowo używają tych funkcji, co powoduje awarie podczas działania na wszystkich urządzeniach z procesorami opartymi na ARMv8.3a i nowszych.

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

wskaźnik BTI

ARM w wersji 8.5 lub nowszej używa instrukcji Branch Target Instrukcje (BTI), by chronić przed atakami typu JOP. Wcześniejsze wersje pakietów SDK do zaciemniania kodu, które rozgałęziają się na losowe przesunięcia bibliotek utworzonych przy użyciu BTI, mogą powodować awarie aplikacji. Instrukcje są zakodowane jako wskazówki, więc nie widać tego błędu na urządzeniach, które nie obsługują BTI.

Opublikuj

Gdy uznasz, że aplikacja jest gotowa, opublikuj ją tak jak zwykle. Tak jak zawsze, postępuj zgodnie ze sprawdzonymi metodami wdrażania aplikacji. Zalecamy wdrożenie ścieżek testów zamkniętych do wdrożenia dla ograniczonej liczby użytkowników i zapewnienie spójnej jakości aplikacji.

Tak jak w przypadku dużej aktualizacji, zanim opublikujesz ją dla większej grupy odbiorców, przeprowadź gruntowne testy na urządzeniach 64-bitowych.