Поддержка 64-битных архитектур

Приложения, публикуемые в Google Play, должны поддерживать 64-битную архитектуру . Добавление 64-битной версии вашего приложения обеспечивает повышение производительности и позволяет использовать его на устройствах с 64-битной архитектурой.

Следующие шаги гарантируют, что ваше 32-битное приложение будет поддерживать 64-битные устройства.

Оцените ваше приложение

Если ваше приложение использует только код, написанный на языке программирования Java или Kotlin, включая все библиотеки или SDK, то ваше приложение поддерживает 64-битные устройства. Если ваше приложение использует какой-либо нативный код, или вы не уверены в этом, оцените его работоспособность.

Быстрая проверка состояния

Зайдите в Play Console и проверьте существующие версии, чтобы убедиться в их совместимости.

В Play Console также отображаются предупреждения, относящиеся к вашим черновым версиям, если есть какие-либо проблемы, связанные с требованием 64-битной архитектуры. На следующем изображении приведен пример.

Если появится предупреждение, выполните следующие действия, чтобы обеспечить совместимость вашего приложения с 64-битными устройствами.

Ваше приложение использует нативный код?

Ваше приложение использует нативный код, если оно:

• Использует любой код C/C++ (нативный) из вашего приложения.
• Связи с любыми сторонними нативными библиотеками.
• Создан сторонним конструктором приложений, использующим нативные библиотеки.

Включает ли ваше приложение 64-битные библиотеки?

Изучите структуру вашего APK-файла. При сборке APK-файл упаковывается вместе со всеми необходимыми приложению нативными библиотеками. Нативные библиотеки хранятся в различных папках в зависимости от ABI . Поддержка каждой 64-битной архитектуры не обязательна, но для каждой поддерживаемой 32-битной архитектуры необходимо включить соответствующую 64-битную архитектуру.

Для архитектуры ARM 32-битные библиотеки находятся в папке armeabi-v7a . 64-битный эквивалент — arm64-v8a .

Для архитектуры x86 ищите x86 для 32-битной архитектуры и x86_64 для 64-битной.

Убедитесь, что в обеих этих папках находятся нативные библиотеки. Подведем итог:

Обратите внимание, что в зависимости от вашего приложения, набор библиотек в каждой папке может быть разным. Цель состоит в том, чтобы обеспечить корректную работу вашего приложения в среде, поддерживающей только 64-битные системы.

В типичном случае APK-файл или пакет, созданный для 32-битной и 64-битной архитектур, содержит папки для обоих ABI, каждая с соответствующим набором нативных библиотек. Если поддержка 64-битной архитектуры отсутствует, вы можете увидеть папку с 32-битным ABI, но не папку с 64-битным ABI.

Найдите нативные библиотеки с помощью APK Analyzer.

APK Analyzer — это инструмент, позволяющий оценить различные аспекты собранного APK-файла. Используйте его для поиска любых нативных библиотек и убедитесь в наличии 64-битных библиотек.

1. Откройте Android Studio и откройте любой проект .

2. В меню выберите Сборка > Анализ APK …

   

3. Выберите APK-файл, который хотите оценить.

4. Проверьте папку lib , в которой находятся файлы с расширением '.so', если таковые имеются. Если их нет, значит, ваше приложение поддерживает 64-битные устройства, и никаких дальнейших действий не требуется. Если вы видите armeabi-v7a или x86 , значит, у вас установлены 32-битные библиотеки.

5. Проверьте, есть ли у вас похожие файлы с расширением '.so' в папке arm64-v8a или x86_64 .

   

6. Если у вас отсутствуют библиотеки arm64-v8a или x86_64 , обновите процесс сборки, чтобы начать сборку и упаковку этих артефактов в ваш APK-файл.

7. Если вы уже видите, что обе библиотеки упакованы, можете сразу перейти к тестированию приложения на 64-битном оборудовании .

Найдите нативные библиотеки, распаковав APK-файлы.

APK-файлы имеют структуру, аналогичную ZIP-архивам. С помощью командной строки или любого другого инструмента для распаковки извлеките APK-файл. В зависимости от используемого инструмента, возможно, потребуется переименовать файл в .zip.

Просмотрите извлеченные файлы, следуя приведенным выше инструкциям, чтобы определить, поддерживает ли ваше приложение 64-битные устройства. Вы можете запустить следующий пример команды из командной строки:

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

Обратите внимание, что в этом примере присутствуют библиотеки armeabi-v7a и arm64-v8a , что означает, что приложение поддерживает 64-битные архитектуры.

Создавайте свои приложения с использованием 64-битных библиотек.

В следующих инструкциях описано, как собрать 64-битные библиотеки. Обратите внимание, что эти шаги охватывают только сборку кода и библиотек, которые вы можете собрать из исходного кода.

Сборка выполняется с помощью Android Studio или Gradle.

В большинстве проектов Android Studio в качестве базовой системы сборки используется Gradle, поэтому этот раздел применим к обоим случаям. Чтобы включить сборку для вашего нативного кода, добавьте arm64-v8a и/или x86_64 , в зависимости от архитектур, которые вы хотите поддерживать, в параметр ndk.abiFilters в файле 'build.gradle' вашего приложения:

// 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")
        }
// ...

Сборка с использованием CMake

Если ваше приложение собрано с помощью CMake , вы можете выполнить сборку для 64-битных ABI, передав arm64-v8a в параметр '-DANDROID_ABI':

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

Сборка с помощью ndk-build

Если ваше приложение собрано с помощью ndk-build , вы можете выполнить сборку для 64-битных ABI, изменив файл 'Application.mk' с помощью переменной APP_ABI :

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Перенос 32-битного кода на 64-битный

Если ваш код уже работает на настольных компьютерах или iOS, вам не потребуется выполнять дополнительную работу для Android. Если же ваш код впервые скомпилирован для 64-битной системы, основная проблема, которую вам необходимо решить, заключается в том, что указатели больше не помещаются в 32-битные целочисленные типы, такие как int .

Обновите код, который хранит указатели в таких типах, как int , unsigned или uint32_t . В системах Unix long соответствует размеру указателя, но в Windows это не так. Вместо этого используйте типы uintptr_t или intptr_t , которые позволяют определить назначение указателя. Для хранения разницы между двумя указателями используйте тип ptrdiff_t .

Даже для не-указателей следует всегда отдавать предпочтение конкретным целочисленным типам фиксированной ширины, определенным в файле <stdint.h> а не типам нефиксированной ширины, таким как int или long .

Используйте следующие флаги компилятора, чтобы выявлять случаи некорректного преобразования указателей в целые числа в вашем коде:

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

В Java-классах с полями int , содержащими указатели на объекты C/C++, наблюдается та же проблема. Найдите jint в исходном коде JNI и убедитесь, что вы переключились на long на стороне Java и jlong ​​на стороне C++.

Неявные объявления функций гораздо опаснее для 64-битного кода. В C/C++ предполагается, что тип возвращаемого значения неявно объявленной функции (то есть функции, для которой компилятор не видел объявления) — int . Если фактический тип возвращаемого значения вашей функции — указатель, это прекрасно работает в 32-битной системе, где ваш указатель помещается в тип int. Однако в 64-битной системе компилятор отбрасывает верхнюю половину вашего указателя. Например:

// 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`.

Следующий флаг компилятора преобразует предупреждения о неявном объявлении функции в ошибки, чтобы вы могли легче найти и исправить эту проблему:

-Werror=implicit-function-declaration

Если у вас есть встроенный ассемблер, перепишите его или используйте реализацию на чистом C/C++.

Если размеры типов заданы жестко (например, 8 или 16 байт), замените их эквивалентным выражением sizeof(T) , например, sizeof(void*) .

Если вам необходимо компилировать разный код для 32-битных и 64-битных систем, вы можете использовать директиву #if defined(__LP64__) для общих различий между 32- и 64-битными системами, или __arm__ , __aarch64__ (arm64), __i386__ (x86) и __x86_64__ для конкретных архитектур, поддерживаемых Android.

Необходимо корректно настроить строки форматирования для функций типа printf или scanf , поскольку традиционные спецификаторы формата не позволяют корректно указывать 64-битные типы как для 32-битных, так и для 64-битных устройств. Макросы PRI и SCN в файле <inttypes.h> решают эту проблему: PRIxPTR и SCNxPTR используются для записи и чтения шестнадцатеричных указателей, а PRId64 и SCNd64 для переносимой записи и чтения 64-битных значений.

При сдвиге может потребоваться использовать 1ULL , чтобы получить 64-битную константу для сдвига, вместо использования 1 , которая имеет размер всего 32 бита.

Снижайте размер приложения с помощью Android App Bundle.

Добавление поддержки 64-битной архитектуры в ваше приложение может привести к увеличению размера APK-файла. Мы настоятельно рекомендуем использовать функцию Android App Bundle , чтобы минимизировать влияние на размер приложения включения как 32-битного, так и 64-битного нативного кода в один и тот же APK-файл.

Разработчики игр

Три наиболее часто используемых движка поддерживают 64-битную архитектуру:

• Нереально с 2015 года
• Cocos2d с 2015 года
• Единство с 2018 года

Разработчики Unity

Обновите до совместимых версий.

Unity обеспечивает поддержку 64-битных систем в версиях 2018.2 и 2017.4.16 .

Если вы используете версию Unity, не поддерживающую 64-битную архитектуру, определите версию, до которой хотите обновиться, и следуйте инструкциям Unity по миграции среды, убедившись, что ваше приложение обновлено до версии, способной собирать 64-битные библиотеки. Unity рекомендует получить доступ к последним функциям и обновлениям, обновив редактор до последней LTS- версии.

Вот таблица, в которой описаны различные версии Unity и что вам следует сделать:

Измените параметры сборки, чтобы создавать 64-битные библиотеки.

Если вы используете версию Unity, поддерживающую 64-битные библиотеки Android, вы можете сгенерировать 64-битную версию своего приложения, изменив параметры сборки. Используйте бэкенд IL2CPP в качестве бэкенда для скриптов. Чтобы настроить сборку проекта Unity для 64-битной архитектуры, выполните следующие действия:

1. Перейдите в «Настройки сборки» и убедитесь, что сборка выполняется для Android, проверив, что рядом с Android в разделе «Платформа» находится значок Unity. 1. Если рядом с платформой Android нет значка Unity, выберите Android и нажмите «Переключить платформу».

2. Нажмите «Настройки проигрывателя».

   

3. Перейдите в Панель настроек плеера > Настройки для Android > Другие настройки > Конфигурация

4. Установите в качестве бэкенда для написания скриптов IL2CPP.

5. Установите флажок «Целевая архитектура > ARM64» .

   

6. Стройте как обычно!

Обратите внимание, что для сборки под ARM64 все ваши ресурсы должны быть скомпилированы специально для этой платформы. Следуйте рекомендациям Unity по уменьшению размера APK-файлов и рассмотрите возможность использования функции Android App Bundle , чтобы компенсировать это увеличение размера.

Поддержка нескольких APK-файлов и 64-битная архитектура.

Если вы используете поддержку нескольких APK-файлов в Google Play для публикации своего приложения, обратите внимание, что соответствие требованиям 64-битной архитектуры проверяется на уровне выпуска. Однако требование 64-битной архитектуры не распространяется на APK-файлы или пакеты приложений, не распространяемые на устройства под управлением Android 9 Pie или более поздней версии.

Если один из ваших APK-файлов помечен как не соответствующий требованиям, но это более ранняя версия, и привести его в соответствие невозможно, одним из способов является добавление атрибута maxSdkVersion="27" в элемент uses-sdk в манифесте этого APK-файла. Такой APK-файл не будет поставляться на устройства под управлением Android 9 Pie или более поздних версий и больше не будет препятствовать соответствию требованиям.

RenderScript и совместимость с 64-битными системами

Если ваше приложение использует RenderScript и было собрано с помощью более ранней версии инструментов Android, вы можете столкнуться с проблемами совместимости с 64-битными системами. При использовании инструментов сборки версий ниже 21.0.0 компилятор может генерировать битовый код во внешний файл .bc . Эти устаревшие файлы .bc больше не поддерживаются для 64-битных архитектур, поэтому наличие этого файла в вашем APK-файле вызывает проблему совместимости.

Чтобы исправить проблему, удалите все файлы .bc из вашего проекта, обновите среду разработки до build-tools-21.0.0 или более поздней версии и установите renderscriptTargetApi в Android Studio на версию 21+, чтобы указать компилятору не создавать файлы .bc . Затем пересоберите приложение, проверьте наличие файлов .bc и загрузите его в Play Console.

Протестируйте свое приложение на 64-битном оборудовании.

64-битная версия вашего приложения должна предлагать такое же качество и набор функций, как и 32-битная версия. Протестируйте приложение, чтобы убедиться, что пользователи новейших 64-битных устройств получают отличный опыт работы с ним.

64-битные устройства

По возможности мы рекомендуем тестировать ваше приложение в строго 64-битной среде, используя один из следующих вариантов:

• Google Pixel с 64-битным образом системы
• Эмулятор Android

Google Pixel с 64-битным образом системы

Для упрощения разработки и тестирования приложений мы предоставили специальные образы системы со строгой 64-битной средой для некоторых устройств Pixel. Эти 64-битные образы изначально предоставлялись одновременно со стандартными заводскими образами системы для предварительных версий Android 13 и 14, но вы можете продолжать использовать их при тестировании вашего приложения на совместимость с 64-битными системами.

Получите образ только для 64-битной архитектуры.

Аналогично заводским образам системы, вы можете прошить на свое устройство образ, работающий только в 64-битном режиме, с помощью инструмента Android Flash Tool или путем ручной прошивки устройства , как описано в следующих разделах.

Прошейте ваше устройство с помощью Android Flash Tool.

Android Flash Tool позволяет безопасно прошивать образ системы на поддерживаемое устройство Pixel. Android Flash Tool работает с любым веб-браузером, поддерживающим WebUSB, например Chrome или Edge 79+.

Программа Android Flash Tool шаг за шагом проведет вас через процесс прошивки вашего устройства — устанавливать какие-либо инструменты не требуется, но вам необходимо разблокировать устройство и включить отладку по USB в параметрах разработчика . Полные инструкции см. в документации к программе Android Flash Tool .

Подключите устройство через USB, затем, в зависимости от типа образа системы, который вы хотите прошить, перейдите в Android Flash Tool, используя одну из следующих ссылок, и следуйте инструкциям на экране:

• Образы системы Android 14 (Beta 5.2) только для 64-битных систем

  Выберите устройство, которое вы пытаетесь прошить:

  • Pixel 4a (5G)
  • Пиксель 5
  • Пиксель 6
  • Pixel 6 Pro

• Образы системы Android 13 (QPR3 Beta 3.2) только для 64-битных систем

  Выберите устройство, которое вы пытаетесь прошить:

  • Pixel 4a (5G)
  • Пиксель 5
  • Пиксель 6
  • Pixel 6 Pro

Прошейте ваше устройство вручную.

Вы также можете загрузить последнюю версию образа системы и вручную прошить его на ваше устройство. См. таблицу ниже, чтобы загрузить образ системы для вашего тестового устройства. Ручная прошивка устройства полезна, если вам необходим точный контроль над тестовой средой или если вам часто требуется переустановка, например, при выполнении автоматизированного тестирования.

После резервного копирования данных с устройства и загрузки соответствующего образа системы вы можете прошить этот образ на ваше устройство .

Вы можете в любой момент вернуться к последней общедоступной сборке .

Заводские образы Android 14 (Beta 5.3), доступные только для 64-битных систем.

Эти образы предоставляют среду, строго предназначенную только для 64-битных систем, для тестирования совместимости 64-битных приложений. Эти конфигурации, предназначенные только для 64-битных систем, предназначены исключительно для использования разработчиками.

Заводские образы Android 13 (QPR3 Beta 3.2) только для 64-битных систем

Эти образы предоставляют среду, строго предназначенную только для 64-битных систем, для тестирования совместимости 64-битных приложений. Эти конфигурации, предназначенные только для 64-битных систем, предназначены исключительно для использования разработчиками.

Вернуться к общедоступной сборке

Вы можете либо использовать Android Flash Tool для прошивки заводского образа , либо получить системный образ заводских характеристик на странице «Заводские образы для устройств Nexus и Pixel», а затем вручную прошить его на устройство.

Эмулятор Android

Начиная с Android 12 (уровень API 31), образы системы эмулятора Android являются только 64-битными. Создайте виртуальное устройство Android (AVD), используя образ системы с Android 12 (уровень API 31) или выше, чтобы получить строго 64-битную среду для тестирования приложений.

Другие варианты устройств

Если у вас нет одного из этих устройств или вы не можете использовать эмулятор Android, лучшим вариантом будет использование устройства с поддержкой 64-битной архитектуры, например, Google Pixel или других флагманских устройств от других производителей.

Установите и протестируйте свое приложение.

Самый простой способ протестировать ваш APK-файл — установить приложение с помощью Android Debug Bridge (adb). В большинстве случаев вы можете указать параметр --abi , чтобы определить, какие библиотеки следует установить на устройство. Это установит приложение только с 64-битными библиотеками, имеющимися на устройстве.

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

После успешной установки протестируйте приложение обычным способом, чтобы убедиться, что его качество соответствует 32-битной версии.

Проверьте наличие известных проблем совместимости.

В процессе тестирования проверьте ваше приложение на наличие следующих проблем, которые возникают при работе на 64-битных устройствах. Даже если ваше приложение напрямую не зависит от затронутых библиотек, сторонние библиотеки и SDK в зависимостях вашего приложения могут от них зависеть.

SoLoader

Если вы используете SDK для загрузки нативного кода SoLoader , обновите его до версии 0.10.4 или выше. Если ваше приложение использует SDK, зависящие от SoLoader, убедитесь, что вы также обновили соответствующие SDK до последней стабильной версии.

SoLoader версии 0.9.0 и ниже предполагает, что системные библиотеки находятся в /vendor/lib:/system/lib . Эта ошибка не наблюдается на таких устройствах, как Pixel 7, где указанный путь существует, но это предположение приводит к сбоям на устройствах, у которых системные библиотеки находятся только в /vendor/lib64:/system/lib64 .

Для получения дополнительной информации об устранении этой и других проблем, вызванных SoLoader, см. соответствующий ответ в Справочном центре Google .

OpenSSL

Если вы используете библиотеку OpenSSL, обновите её до версии 1.1.1i или выше. Если ваше приложение использует SDK, обеспечивающие связь по протоколу HTTPS, или другие SDK, зависящие от OpenSSL, убедитесь, что вы также обновили SDK до последней версии, использующей более новую версию OpenSSL. Обратитесь к поставщику SDK, если он недоступен.

ARMv8.3 PAC обеспечивает аппаратную поддержку целостности потока управления путем аутентификации указателей во время выполнения. Более ранние версии OpenSSL некорректно использовали эти возможности, что приводило к сбоям во время выполнения на всех устройствах с процессорами на базе ARMv8.3a и выше.

Для получения дополнительной информации об устранении этой и других проблем, вызванных OpenSSL, см. соответствующий ответ в Справочном центре Google .

БТИ

В ARMv8.5 и более поздних версиях используются инструкции ветвления (Branch Target Instructions, BTI) для защиты от JOP-атак . Более ранние версии SDK для обфускации, использующие случайные смещения в библиотеках, собранных с помощью BTI, могут приводить к сбоям приложений. Поскольку инструкции закодированы как HINT , эта ошибка не наблюдается на устройствах, не поддерживающих BTI.

Публиковать

Когда вы почувствуете, что ваше приложение готово, опубликуйте его в обычном режиме. Как всегда, продолжайте следовать лучшим практикам развертывания приложения. Мы рекомендуем использовать закрытые тестовые каналы для развертывания приложения для ограниченного числа пользователей, чтобы обеспечить стабильное качество вашего приложения.

Как и при выпуске крупного обновления, перед публикацией для более широкой аудитории обязательно проведите тщательное тестирование на устройствах с поддержкой 64-битной архитектуры.