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

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

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

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

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

  • Pixel 4a (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-разрядных устройствах перед публикацией для более крупной аудитории.

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

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

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

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

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

Зайдите в пьесу и посмотрите на существующие релизы, чтобы увидеть, соответствуют ли они.

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. В меню выберите Build> Проанализировать 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-битный ABIS, изменяя свой файл '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

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

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

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

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

Разработчики единства

Обновить до способных версий

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

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

Вот диаграмма, в которой изложены различные версии единства и то, что вы должны делать:

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

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

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

2. Нажмите настройки игрока.

   

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

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

5. Выберите «Целевая архитектура»> «Флажок ARM64» .

   

6. Построить как обычно!

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

Соответствие с несколькими APK и 64-битным

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

Если один из ваших 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-битные системы систем

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

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

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

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

  • Pixel 4a (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-разрядных устройствах перед публикацией для более крупной аудитории.