Поддержка 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-битной системе, где ваш указатель помещается в целое число. Однако в 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 года
• Кокос2д с 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, проверив, что символ Unity находится рядом с Android в разделе «Платформа» . 1. Если символ Unity не находится рядом с платформой Android, выберите 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, используя одну из следующих ссылок, и следуйте инструкциям на экране:

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

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

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

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

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

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

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

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

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

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

Только 64-битные заводские образы для Android 14 (бета-версия 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 являются только 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 (BTI) для защиты от атак JOP . Более ранние версии SDK для обфускации, которые разветвляются на случайные смещения библиотек, созданных с помощью BTI, могут привести к сбою приложений. Поскольку инструкции закодированы как HINT , эта ошибка не наблюдается на устройствах, не поддерживающих BTI.

Публиковать

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

Как и при выпуске крупного обновления, убедитесь, что вы тщательно протестировали его на 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-битной системе, где ваш указатель помещается в целое число. Однако в 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 года
• Кокос2д с 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, проверив, что символ Unity находится рядом с Android в разделе «Платформа» . 1. Если символ Unity не находится рядом с платформой Android, выберите 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 и загрузите, чтобы воспроизводить консоли.

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

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

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

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

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

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

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

Получите 64-битное изображение

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

Проверкайте ваше устройство, используя инструмент Android Flash

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

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

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

• Android 14 (бета 5.2) 64-битные системы систем

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

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

• Android 13 (QPR3 Beta 3.2) 64-битные системные изображения

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

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

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

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

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

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

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

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

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

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

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

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

Эмулятор Android

Начиная с Android 12 (API-уровне 31), изображения системы эмулятора Android являются только 64-битными. Создайте виртуальное устройство Android (AVD), используя системное изображение с Android 12 (уровень 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 Soloader Sdk Soloader Sdk, обновите до v0.10.4 или выше. Если ваше приложение использует SDK, которые зависят от SoloAder, обязательно обновитесь на последнюю стабильную версию затронутых SDK.

Soloader v0.9.0 и Lower Предположим, что системные библиотеки присутствуют в /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 и более высокое использование Целевых инструкций (BTI), чтобы помочь защитить от атак JOP . Более ранние версии запутывания SDK, которые разбиваются в случайные смещения библиотек, построенные с BTI, могут привести к сбою приложений. Поскольку инструкции кодируются как намеки , эта ошибка не наблюдается в устройствах, которые не поддерживают BTI.

Публиковать

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

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