Obsługa architektury 64-bitowej

Aplikacje opublikowane w Google Play muszą obsługiwać Architektura 64-bitowa. Dodawanie 64-bitowej wersji aplikacji poprawia wydajność i konfiguruje dla urządzeń z wersją 64-bitową, sprzęt.

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 używa tylko kodu napisanego w języku Java lub Kotlin, w tym wszystkie biblioteki i pakiety SDK, Twoja aplikacja obsługuje urządzenia 64-bitowe. Jeśli aplikacja korzysta z kodu natywnego lub nie masz pewności, czy tak, oceń .

Szybkie sprawdzanie stanu

Otwórz Konsolę Play i przejrzyj dotychczasowe wersje, by sprawdzić, czy są dostępne są zgodne z przepisami.

W Konsoli Play wyświetlane są też ostrzeżenia dotyczące wersji roboczych, jeśli: wszelkie problemy związane z wymaganiem formatu 64-bitowego. Ilustracja poniżej to przykład.

Jeśli pojawi się alert, wykonaj te czynności, aby zapewnić zgodność aplikacji Urządzenia 64-bitowe.

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 w pakiecie ze wszystkimi bibliotek natywnych wymaganych przez aplikację. Biblioteki natywne są przechowywane w różnych w oparciu o interfejs ABI. Nie jest wymagana obsługa każdego Architektura 64-bitowa, ale dla każdej natywnej architektury 32-bitowej musi obejmować 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 architektury 32-bitowej i x86_64 w przypadku 64-bitowy.

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

Pamiętaj, że w zależności od aplikacji może on być taki sam, ale nie taki sam w każdym z tych folderów. Zależy nam na tym, aby aplikacja działała prawidłowo w środowisku 64-bitowym.

Zwykle jest to plik APK lub pakiet przeznaczony zarówno do wersji 32-bitowej, jak i 64-bitowej. ma foldery dla obu interfejsów ABI, z których każdy zawiera odpowiedni zestaw biblioteki. Jeśli wersja 64-bitowa nie jest obsługiwana, zobaczysz folder z 32-bitowym interfejsem ABI ale nie w folderze 64-bitowym.

Wyszukaj biblioteki natywne za pomocą Analizatora plików APK

Analizator plików APK to narzędzie umożliwiające ocenę różnych aspektu utworzonego pliku APK. Za ich pomocą możesz znaleźć wszystkie biblioteki natywne i zapewnić obsługę wersji 64-bitowej. dostępne są biblioteki.

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

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

   

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

4. Przejdź do folderu lib zawierającego plik „.so”. . Jeśli brak, aplikacja obsługuje urządzenia 64-bitowe i nie trzeba robić nic więcej Jeśli masz wersję armeabi-v7a lub x86, masz kod 32-bitowy biblioteki.

5. Sprawdź, czy masz podobny fragment „.so” pliki w pakiecie arm64-v8a lub x86_64.

   

6. Jeśli nie masz żadnych bibliotek arm64-v8a ani x86_64, zaktualizuj i rozpocząć tworzenie tych artefaktów w pakiecie APK.

7. Jeśli widzisz, że obie biblioteki są już pakowane, 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. za pomocą wiersza poleceń lub innego wyodrębnij plik APK. W zależności od narzędzia do wyodrębniania może być konieczna zmiana nazwy pliku na .zip.

Przejrzyj rozpakowane pliki, postępując zgodnie z powyższymi wskazówkami, aby określić jeśli aplikacja obsługuje urządzenia 64-bitowe. Możesz uruchomić to przykładowe polecenie w wierszu 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ść tagów armeabi-v7a i arm64-v8a w tym przykładzie biblioteki, 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 budynków i biblioteki, które możesz utworzyć ze źródła.

Kompilowanie w Android Studio lub Gradle

Większość projektów Android Studio korzysta z Gradle jako bazowego systemu kompilacji, ma zastosowanie w obu przypadkach. Aby włączyć kompilacje dla kodu natywnego, dodaj arm64-v8a lub x86_64 w zależności od architektur, które chcesz zastosować do ustawienia ndk.abiFilters w „build.gradle” plik:

// 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 aplikacja została utworzona przy użyciu CMake, możesz ją kompilować w wersji 64-bitowej za pomocą interfejsu ABI arm64-v8a do ciągu „-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 aplikacja została utworzona za pomocą polecenia ndk-build, 64-bitowe interfejsy ABI przez zmodyfikowanie pliku „Application.mk” za pomocą zmienną 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 systemie iOS, nie musisz w Androidzie. Jeśli po raz pierwszy tworzysz kod na potrzeby W systemie 64-bitowym 32-bitowe liczby całkowite, np. 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 to nie jest true (prawda) w systemie Windows. Zamiast tego użyj typów określających zamiary: uintptr_t lub intptr_t Aby zapisać różnicę między dwoma wskaźnikami, użyj funkcji ptrdiff_t typu.

Zawsze należy wybierać konkretne typy liczb całkowitych o stałej szerokości zdefiniowane w <stdint.h>, a nie o stałej szerokości, takich jak int lub long, nawet w przypadku braku wskaźników.

Użyj tych flag kompilatora, aby wychwytywać przypadki, w których Twój kod jest nieprawidłowy przeliczanie wskaźników na liczby całkowite:

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

Klasy Java z polami int, które zawierają wskaźniki do obiektów C/C++, mają takie same . Wyszukaj jint w źródle JNI i upewnij się, że używasz long po stronie Java i jlong po stronie C++.

Deklaracje funkcji niejawnych są znacznie bardziej niebezpieczne w przypadku 64-bitowego kodu. Kod C/C++ zakłada się, że zwracany typ niejawnie zadeklarowana funkcja (czyli dla których kompilator nie widział deklaracji) to int. Jeśli rzeczywisty zwracany typ funkcji jest wskaźnikiem. Sprawdza się to w przypadku 32-bitowego w którym wskaźnik mieści się w formie liczby całkowitej. W systemie 64-bitowym kompilator usuwa 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`.

Poniższa flaga kompilatora zmienia ostrzeżenia dotyczące niejawnej deklaracji funkcji w aby można było łatwiej znaleźć i naprawić ten problem:

-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 z równoważnym wyrażeniem sizeof(T), takim jak sizeof(void*).

Jeśli musisz warunkowo skompilować inny kod w przypadku wersji 32-bitowej niż 64-bitowej, można użyć funkcji #if defined(__LP64__), aby wyświetlić ogólne różnice 32/64, lub __arm__, __aarch64__ (arm64), __i386__ (x86) i __x86_64__ dla konkretnego na architekturze obsługiwanych przez Androida.

Dostosuj ciągi formatu dla funkcji printf i scanf (w standardowy sposób) specyfikatory formatu nie pozwalają na określenie typów 64-bitowych w sposób, zarówno dla urządzeń 32-bitowych, jak i 64-bitowych. Makra PRI i SCN w <inttypes.h> rozwiąż ten problem, PRIxPTR i SCNxPTR do pisania i odczytywania wskaźników szesnastkowych; i PRId64 i SCNd64 za pisanie i do przenośnego odczytu wartości 64-bitowych.

Przy zmianie może być konieczne użycie funkcji 1ULL do uzyskania 64-bitowej stałej do zmiany zamiast używać dyrektywy 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 skorzystanie z pakietu Android App Bundle, który pozwala zminimalizować wpływ uwzględniając 32- i 64-bitowy kod natywny 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 oraz 16.04.2017.

Jeśli używasz Unity w wersji, która nie obsługuje wersji 64-bitowej, którą wersję chcesz uaktualnić, i postępuj zgodnie z instrukcjami, które Unity zapewnia migrację środowiska, dzięki czemu aplikacja jest uaktualniana do która może tworzyć biblioteki 64-bitowe. Unity zaleca dostęp do najnowsze funkcje i aktualizacje przez uaktualnienie do najnowszej wersji kanału LTS. wersji edytora.

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że wygenerować 64-bitową wersję Twojej aplikacji, dostosowując ustawienia kompilacji. Używaj a backend IL2CPP będzie Twoim backendem do obsługi skryptów. Aby skonfigurować w projekcie Unity, aby utworzyć architekturę 64-bitową, wykonaj te czynności:

1. Otwórz Ustawienia kompilacji i upewnij się, że kompilujesz aplikację na Androida przez Sprawdź, czy w sekcji Platforma obok pozycji Android 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. Wybierz Panel ustawień gracza > Ustawienia dla Androida > Inny powód Ustawienia > Konfiguracja

4. Ustaw Backend dla skryptów na IL2CPP.

5. Wybierz architekturę docelową > ARM64.

   

6. Buduj jak zwykle!

Pamiętaj, że kompilowanie pod kątem ARM64 wymaga, aby wszystkie zasoby były tworzone specjalnie na tej platformie. Postępuj zgodnie z wytycznymi Unity dotyczącymi ograniczania liczby pakietów APK i zastanów się nad skorzystaniem z funkcję Android App Bundle, która pomoże zniwelować ten wzrost i rozmiaru.

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

Jeśli korzystasz z obsługi wielu plików APK w Google Play, pamiętaj, że zgodność z wymaganiami wersji 64-bitowej jest oceniana. na poziomie wydania. Wymagania dotyczące wersji 64-bitowej nie mają jednak zastosowania do plików APK ani pakiety aplikacji, które nie są rozpowszechniane na urządzenia z Androidem 9 Pie lub nowszym;

Jeśli jeden z plików APK jest oznaczony jako niezgodny, ale jest w wersji starszej niż i nie da się zapewnić jej zgodności z przepisami, jedną ze strategii jest dodanie Atrybut maxSdkVersion="27" w elemencie uses-sdk w z pliku manifestu pakietu APK. Ten plik APK nie jest dostarczany na urządzenia z Androidem 9 Pie lub później i nie blokuje już zgodności.

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

Jeśli aplikacja korzysta z języka RenderScript i została utworzona przy użyciu wcześniejszej wersji biblioteki W narzędziach na Androida mogą wystąpić problemy ze zgodnością aplikacji z technologią 64-bitową. Z kompilacją starszych niż 21.0.0, kompilator może wygenerować kod bitowy w pliku .bc. Te starsze pliki .bc nie są już obsługiwane w wersji 64-bitowej architektury, więc obecność tego pliku w pakiecie APK powoduje Google Cloud.

Aby rozwiązać ten problem, usuń wszystkie pliki.bc z projektu, przejdź na wyższą wersję na build-tools-21.0.0 lub nowszą wersję i ustaw wartość renderscriptTargetApi w Android Studio dla 21+, aby powiedzieć kompilator tak, aby nie wysyłał plików .bc. Następnie ponownie skompiluj aplikację i sprawdź, czy .bc i prześlij je do Konsoli Play.

Testowanie aplikacji na sprzęcie 64-bitowym

64-bitowa wersja aplikacji powinna oferować taki sam zestaw funkcji i jakości wersji 32-bitowej. Przetestuj aplikację, aby upewnić się, że użytkownicy korzystają z najnowszej wersji 64-bitowej. zapewnia wygodę korzystania z aplikacji na urządzeniach.

Urządzenia 64-bitowe

Jeśli to możliwe, zalecamy przetestowanie aplikacji w trybie rygorystycznym (tylko 64-bitowym) używając 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, udostępniliśmy specjalne obrazy systemu w ściśle 64-bitowym środowisku tylko w przypadku niektórych urządzeń Pixel. Tylko tagi 64-bitowe obrazy były pierwotnie przesyłane równolegle ze standardowymi obrazami systemu fabrycznego. wersji przedpremierowej na Androida 13 i 14, ale możesz ich nadal używać jako podczas testowania aplikacji pod kątem zgodności z architekturą 64-bitową.

Pobierz obraz 64-bitowy

Podobnie jak w przypadku obrazów systemu operacyjnego, do przy użyciu narzędzia Android Flash lub flashując ręcznie, jak opisano w kolejnych sekcjach.

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

Narzędzie Android Flash pozwala bezpiecznie doświetlać obraz systemu z obsługiwanym urządzeniem Pixel. Narzędzie Android Flash Tool działa z każdą przeglądarką obsługujące WebUSB, np. Chrome lub Edge 79 lub nowszej.

Narzędzie Android Flash przeprowadzi Cię krok po kroku przez proces na urządzeniu – nie trzeba instalować żadnych narzędzi, ale trzeba odblokować urządzenia i włącz debugowanie USB w opcjach programisty. Dla: instrukcje znajdziesz w narzędziu Android Flash Tool dokumentacji.

Podłącz urządzenie przez USB, a następnie, w zależności od typu obrazu systemu, chcesz flashować, 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ądzenia. W tabeli poniżej znajdziesz informacje, jak pobrać obraz systemu do testu urządzenia. Ręczne flashowanie urządzenia przydaje się, gdy chcesz precyzyjnie kontrolować w środowisku testowym lub w przypadku częstej ponownej instalacji, np. przeprowadzanie automatycznych testów.

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

W każdej chwili możesz wrócić do najnowszej kompilacji publicznej obecnie się znajdujesz.

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

Te obrazy zapewniają rygorystyczne, 64-bitowe środowisko do testowania aplikacji 64-bitowych zgodność. Te konfiguracje 64-bitowe są przeznaczone tylko dla programistów.

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

Te obrazy zapewniają rygorystyczne, 64-bitowe środowisko do testowania aplikacji 64-bitowych zgodność. Te konfiguracje 64-bitowe są przeznaczone tylko dla programistów.

Wróć do publicznej kompilacji

Możesz użyć narzędzia Android Flash, aby przywróć obraz fabryczny lub pobierz system specyfikacji fabrycznej. obraz z fabrycznych obrazów dla urządzeń Nexus i Pixel stronę, a następnie ręcznie wgrać ją na urządzeniu.

Emulator Androida

Od Androida 12 (poziom interfejsu API 31) obrazy systemowe emulatora Androida są 64-bitowe Utwórz urządzenie wirtualne z Androidem (AVD) przy użyciu systemu obraz z Androidem 12 (poziom interfejsu API 31) lub nowszym, aby uzyskać tryb rygorystyczny tylko w wersji 64-bitowej do testowania aplikacji.

Inne opcje urządzenia

Jeśli nie masz jednego z tych urządzeń lub nie możesz użyć emulatora Androida, Następnym najlepszym rozwiązaniem jest użycie urządzenia obsługującego 64-bitową technologię, np. Pixel lub inne flagowe urządzenia innych producentów.

Instalowanie i testowanie aplikacji

Najłatwiejszym sposobem przetestowania pliku APK jest zainstalowanie aplikacji przy użyciu debugowania Androida Most (adb). W większości przypadków możesz podać --abi jako parametr, by wskazać, które biblioteki należy zainstalować na urządzeniu. Instaluje to aplikację, używając tylko 64-bitowe biblioteki 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 zainstalowaniu przetestuj aplikację w zwykły sposób Upewnij się, że jakość jest taka sama jak wersji 32-bitowej.

Sprawdzanie znanych problemów ze zgodnością

Podczas testowania aplikacji sprawdź, czy nie występują w niej te problemy, które wpływają na jej działanie który działa na urządzeniach 64-bitowych. Nawet jeśli aplikacja nie jest zależna od problemu, bezpośrednio biblioteki, biblioteki innych firm i pakiety SDK w zależnościach aplikacji. być może.

Komponent SoLoader

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

SoLoader w wersji 0.9.0 lub starszej zakłada, że biblioteki systemowe są dostępne /vendor/lib:/system/lib Tego błędu nie widać na urządzeniach takich jak Pixel. 7 dla określonych ścieżek, ale to założenie powoduje awarie tylko na urządzeniach, mają biblioteki systemowe w środowisku /vendor/lib64:/system/lib64.

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

OpenSSL

Jeśli używasz biblioteki OpenSSL, przejdź na OpenSSL w wersji 1.1.1i lub nowszej. Jeśli aplikacja korzysta z pakietów SDK, które zapewniają komunikację przy użyciu protokołu HTTPS lub innych pakietów SDK, zależą od OpenSSL, pamiętaj też o zaktualizowaniu pakietu SDK do najnowszej wersji który korzysta z nowszej wersji OpenSSL. Jeśli nie, skontaktuj się z dostawcą pakietu SDK i dostępności informacji.

ARMv8.3 PAC umożliwia sterowanie sprzętowe integralność przepływu przez uwierzytelnianie wskaźników w czasie działania. Wcześniejsze wersje OpenSSL używa tych funkcji nieprawidłowo, co powoduje awarie w czasie działania z procesorami ARM 8.3a i nowszymi.

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

wskaźnik BTI

ARM w wersji 8.5 lub nowszej używa instrukcji gałęzi BTI (BRN) w celu ochrony przed Ataki typu JOP. Wcześniejsze wersje zaciemniania kodu Pakiety SDK, które rozgałęziają się na losowe przesunięcia bibliotek utworzonych za pomocą BTI, mogą powodować ulegać awarii. Ponieważ instrukcje są zakodowane jako WSKAZÓWKI, tego błędu nie widać na urządzeniach które nie obsługują BTI.

Opublikuj

Gdy uznasz, że aplikacja jest gotowa, opublikuj ją tak jak zwykle. Jak zawsze, przejdź do postępuj zgodnie ze sprawdzonymi metodami wdrażania aplikacji. Zalecamy skorzystanie ścieżek testów zamkniętych do wdrożenia na ograniczonej liczbie użytkowników, aby zapewnić stałą jakość aplikacji.

Tak jak przy wprowadzaniu dużej aktualizacji, dokładnie przetestuj urządzeń z obsługą wersji 64-bitowej, zanim opublikujesz je dla większej liczby odbiorców;