Obsługa architektury 64-bitowej

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

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 bibliotekach i pakietach SDK), obsługuje urządzenia 64-bitowe. Jeśli Twoja aplikacja używa kodu natywnego lub nie masz pewności, czy tak jest, sprawdź aplikację.

Szybkie sprawdzenie stanu

Otwórz Konsolę Play i przejrzyj istniejące wersje, by sprawdzić, czy są z nimi 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 poniższe czynności, aby zapewnić zgodność aplikacji na urządzeniach 64-bitowych.

Czy Twoja aplikacja korzysta z kodu natywnego?

Aplikacja korzysta z kodu natywnego, jeśli:

• Wykorzystuje dowolny (natywny) kod w C/C++ w aplikacji.
• 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 32-bitowej musisz uwzględnić odpowiadającą jej architekturę 64-bitową.

W przypadku architektury ARM biblioteki 32-bitowe znajdują się w interfejsie 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

Analizator plików APK to narzędzie umożliwiające ocenę różnych aspektów skompilowanego pliku 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 32-bitowe biblioteki.

5. Sprawdź, czy w folderze arm64-v8a lub x86_64 znajdują się 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 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, 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ę, że w tym przykładzie występują biblioteki 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 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 skompilować ją na potrzeby 64-bitowych ABI, przekazując wartość 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 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 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 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, które mają pola int zawierające 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++.

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. 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 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 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 32/64, lub kodu __arm__, __aarch64__ (arm64), __i386__ (x86) i __x86_64__ dla 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 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.

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

• 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 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, aby mieć dostęp do najnowszych funkcji i aktualizacji, uaktualniając edytor do najnowszej wersji LTS.

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 obok platformy Androida nie ma symbolu Unity, 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 kompilowanie pod kątem ARM64 wymaga utworzenia wszystkich zasobów specjalnie pod kątem 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ć wzrost rozmiaru.

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

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 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 Twoich plików APK jest oznaczony jako niezgodny, ale jest w wersji starszej i nie można zapewnić jej zgodności, jedną ze strategii jest dodanie atrybutu maxSdkVersion="27" do elementu 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 64-bitami

Jeśli Twoja aplikacja korzysta z języka RenderScript i została utworzona przy użyciu starszej 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ść 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ć tę samą jakość i taki sam zestaw funkcji co 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 fabrycznymi obrazami systemu dla wersji w wersji zapoznawczej Androida 13 i 14, ale nadal możesz ich używać podczas testowania aplikacji pod kątem zgodności z systemem 64-bitowym.

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. 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 przeprowadzi 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 tylko w wersji 64-bitowej w Androidzie 14 (Beta 5.2)

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

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

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

  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 z urządzenia i pobraniu odpowiedniego obrazu systemu możesz zainstalować 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);

Obrazy te zapewniają rygorystyczne, 64-bitowe środowisko do testowania zgodności aplikacji z architekturą 64-bitową. 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.

Wróć do publicznej kompilacji

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 systemowe emulatora 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ą być zainstalowane na urządzeniu. Spowoduje to zainstalowanie na urządzeniu aplikacji 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 mieć pewność, że jej jakość jest taka sama jak w wersji 32-bitowej.

Sprawdzanie znanych problemów 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 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 ł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. 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 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 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 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.

wskaźnik 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, stosuj sprawdzone metody wdrażania aplikacji. Zalecamy korzystanie ze ścieżek testów zamkniętych, aby udostępnić aplikację ograniczonej liczbie użytkowników i upewnić się, że jej jakość jest spójna.

Podobnie jak w przypadku wprowadzania istotnych aktualizacji, przed opublikowaniem aktualizacji dla większej liczby użytkowników sprawdź dokładnie, czy działa ona prawidłowo na urządzeniach z procesorami 64-bitowymi.