Поддержка 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-битной.

Найдите собственные библиотеки с помощью 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 в качестве бэкэнда Scripting. Чтобы настроить проект Unity для сборки 64-битной архитектуры, выполните следующие действия:

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

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

   

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

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

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

   

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

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

Совместимость с Multi-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-битной версии

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

  • Пиксель 4а (5G)
  • Пиксель 5
  • Пиксель 6
  • Пиксель 6 Про

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

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

  • Пиксель 4а (5G)
  • Пиксель 5
  • Пиксель 6
  • Пиксель 6 Про

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

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

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

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

Заводские образы только для 64-битной версии Android 14 (Beta 5.3)

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

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

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

Вернуться к публичной сборке

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

Эмулятор Android

Начиная с Android 12 (уровень API 31) образы системы Android Emulator поддерживают только 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 v0.9.0 и ниже предполагает, что системные библиотеки присутствуют в /vendor/lib:/system/lib . Эта ошибка не наблюдается в таких устройствах, как Pixel 7, где этот путь существует, но это предположение вызывает сбои в устройствах, которые имеют только системные библиотеки в /vendor/lib64:/system/lib64 .

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

OpenSSL

Если вы используете библиотеку 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-битной архитектуры, прежде чем публиковать для более широкой аудитории.