Эта страница переведена с помощью Cloud Translation API.

Поддержка нескольких APK

Если вы публикуете свое приложение в Google Play, вам необходимо создать и загрузить пакет Android App Bundle . Когда вы это сделаете, Google Play автоматически создаст и предоставит оптимизированные APK-файлы для конфигурации устройства каждого пользователя, поэтому они загружают только тот код и ресурсы, которые им необходимы для запуска вашего приложения. Публикация нескольких APK-файлов полезна, если вы не публикуете их в Google Play, но вам необходимо самостоятельно создавать, подписывать и управлять каждым APK-файлом.

Поддержка нескольких APK — это функция Google Play, которая позволяет публиковать разные APK для вашего приложения, каждый из которых предназначен для разных конфигураций устройств. Каждый APK представляет собой полную и независимую версию вашего приложения, но они имеют один и тот же список приложений в Google Play, должны иметь одно и то же имя пакета и быть подписаны одним и тем же ключом выпуска. Эта функция полезна в тех случаях, когда ваше приложение не может охватить все нужные устройства с помощью одного APK.

Устройства под управлением Android могут отличаться по нескольким параметрам, и для успеха вашего приложения важно сделать его доступным для как можно большего числа устройств. Приложения Android обычно запускаются на большинстве совместимых устройств с одним APK-файлом, предоставляя альтернативные ресурсы для разных конфигураций (например, разные макеты для разных размеров экрана), а система Android выбирает подходящие ресурсы для устройства во время выполнения. Однако в некоторых случаях один APK не может поддерживать все конфигурации устройств, поскольку альтернативные ресурсы делают файл APK слишком большим или другие технические проблемы не позволяют одному APK работать на всех устройствах.

Чтобы помочь вам опубликовать свое приложение для как можно большего числа устройств, Google Play позволяет публиковать несколько APK-файлов в одном списке приложений. Затем Google Play передает каждый APK на соответствующие устройства на основе поддержки конфигурации, заявленной вами в файле манифеста каждого APK.

Опубликовав свое приложение с несколькими APK-файлами, вы сможете:

Поддержка различных форматов сжатия текстур OpenGL в каждом APK.
Поддержка разных размеров и плотности экрана в каждом APK.
Поддержка различных наборов функций устройства в каждом APK.
Поддержка различных версий платформы с каждым APK.
Поддерживайте различные архитектуры ЦП в каждом APK (например, для ARM или x86, если ваше приложение использует Android NDK ).
Оптимизируйте для устройств начального уровня, например для устройств под управлением Android (версия Go).

В настоящее время это единственные характеристики устройства, которые Google Play поддерживает для публикации нескольких APK в одном приложении.

Примечание. Чтобы узнать о подготовке и публикации APK-файлов в Google Play, прочтите статью поддержки подготовки и внедрения выпусков .

Как работают несколько APK

Концепция использования нескольких APK-файлов в Google Play заключается в том, что у вас есть только одна запись в Google Play для вашего приложения, но разные устройства могут загрузить разные APK. Это означает, что:

Вы сохраняете только один набор сведений о продукте (описание приложения, значки, снимки экрана и т. д.). Это также означает, что вы не можете взимать разную цену за разные APK.
Все пользователи видят в Google Play только одну версию вашего приложения, поэтому их не смущают разные опубликованные вами версии — «для планшетов» или «для телефонов».
Все отзывы пользователей применяются к одному и тому же списку приложений, даже если у пользователей на разных устройствах могут быть разные APK-файлы.
Если вы публикуете разные APK-файлы для разных версий Android (для разных уровней API), то, когда устройство пользователя получает обновление системы, которое позволяет ему использовать другой опубликованный вами APK, Google Play обновляет приложение пользователя до APK, предназначенного для более поздняя версия Android. Любые системные данные, связанные с приложением, сохраняются (так же, как и при обычных обновлениях приложения при использовании одного APK).

Поддерживаемые фильтры

Какие устройства получают каждый APK, определяется фильтрами Google Play , указанными элементами в файле манифеста каждого APK. Однако Google Play позволяет публиковать несколько APK только в том случае, если каждый APK использует фильтры для поддержки изменений следующих характеристик устройства:

Форматы сжатия текстур OpenGL
Это основано на элементах <supports-gl-texture> вашего файла манифеста.
Например, при разработке игры, использующей OpenGL ES, вы можете предоставить один APK для устройств, поддерживающих сжатие текстур ATI, и отдельный APK для устройств, поддерживающих сжатие PowerVR (среди многих других).
Размер экрана (и, опционально, плотность экрана)
Это основано на элементе <supports-screens> или <compatible-screens> вашего файла манифеста. Никогда не следует использовать оба элемента, а по возможности следует использовать только <supports-screens> .
Например, вы можете предоставить один APK, поддерживающий экраны маленького и нормального размера, и другой APK, поддерживающий большие и большие экраны. Чтобы узнать больше о создании отдельных APK-файлов в зависимости от размера или плотности экрана, перейдите в раздел «Создание нескольких APK-файлов» .
Рассмотрите следующие рекомендации для поддержки всех размеров экрана:
- Система Android обеспечивает надежную поддержку приложений для всех конфигураций экрана с помощью одного APK. Вам следует избегать создания нескольких APK для поддержки разных экранов без крайней необходимости и вместо этого следовать руководству «Поддержка нескольких экранов» , чтобы ваше приложение было гибким и могло адаптироваться ко всем конфигурациям экрана с помощью одного APK.
- По умолчанию все атрибуты размера экрана в элементе <supports-screens> имеют значение true, если вы не указали для них иное. Однако, поскольку атрибут android:xlargeScreens был добавлен в Android 2.3 (уровень API 9), Google Play будет считать его «ложным», если ваше приложение не устанавливает для android:minSdkVersion или android:targetSdkVersion значение «9» или выше.
- Не следует объединять элементы <supports-screens> и <compatible-screens> в файле манифеста. Использование обоих увеличивает вероятность возникновения ошибки из-за конфликтов между ними. Чтобы узнать, какой вариант использовать, прочтите «Распределение по конкретным экранам» . Если вы не можете избежать использования обоих, имейте в виду, что при любых конфликтах согласия между заданным размером победит «false».
Наборы функций устройства
Это основано на элементах <uses-feature> вашего файла манифеста.
Например, вы можете предоставить один APK для устройств, поддерживающих мультитач, и другой APK для устройств, которые не поддерживают мультитач. См . «Справочник функций» , где приведен список функций, поддерживаемых платформой.
Android (версия Go)
Чтобы настроить таргетинг на устройства под управлением Android (версия Go), в вашем APK необходимо объявить <uses-feature android:name="android.hardware.ram.low" android:required="true"> , настроить как минимум уровень API 26 и иметь более высокий код версии, чем у APK версии, отличной от Go.
уровень API
Это основано на элементе <uses-sdk> вашего файла манифеста. Вы можете использовать атрибуты android:minSdkVersion и android:maxSdkVersion чтобы указать поддержку различных уровней API.
Например, вы можете опубликовать свое приложение с помощью одного APK, поддерживающего уровни API 16–19 (Android 4.1.x–4.4.4), используя только API, доступные начиная с уровня API 16 или ниже, и другого APK, поддерживающего уровни API 21 и выше. (Android 5.0+) — использование API, доступных начиная с уровня API 21 или ниже. Чтобы узнать, как создавать отдельные APK-файлы, каждый из которых предназначен для определенного диапазона API, перейдите в раздел «Настройка вариантов продукта» .
Если вы используете эту характеристику в качестве фактора для различения нескольких APK, то APK с более высоким значением android:minSdkVersion должен иметь более высокое значение android:versionCode . Это также верно, если два APK перекрывают поддержку своих устройств на основе другого поддерживаемого фильтра. Это гарантирует, что при получении устройством обновления системы Google Play сможет предложить пользователю обновление вашего приложения (поскольку обновления основаны на увеличении кода версии приложения). Это требование описано далее в разделе «Правила для нескольких APK» ниже.
Вам следует вообще избегать использования android:maxSdkVersion , поскольку, если вы правильно разработали свое приложение с общедоступными API, оно всегда совместимо с будущими версиями Android. Если вы хотите опубликовать другой APK для более высоких уровней API, вам все равно не нужно указывать максимальную версию, потому что если android:minSdkVersion имеет значение "16" в одном APK и "21" в другом, устройства, поддерживающие уровень API 21 или выше всегда будет получать второй APK (поскольку его код версии выше, как указано в предыдущем примечании).

Архитектура ЦП (ABI)
Некоторые собственные библиотеки предоставляют отдельные пакеты для конкретных архитектур ЦП или двоичных интерфейсов приложений (ABI) . Вместо того, чтобы упаковывать все доступные библиотеки в один APK, вы можете создать отдельный APK для каждого ABI и включить в него только те библиотеки, которые вам нужны для этого ABI. Чтобы узнать больше о создании отдельных APK-файлов на основе целевого ABI, перейдите в раздел Создание нескольких APK-файлов .

Другие элементы манифеста, которые включают фильтры Google Play , но не перечислены выше, по-прежнему применяются к каждому APK, как обычно. Однако Google Play не позволяет публиковать отдельные APK-файлы на основе изменений характеристик этих устройств. Таким образом, вы не можете опубликовать несколько APK, если перечисленные выше фильтры одинаковы для каждого APK (но APK различаются в зависимости от других характеристик в манифесте или APK). Например, вы не можете предоставлять разные APK-файлы, которые отличаются только характеристиками <uses-configuration> .

Правила для нескольких APK

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

Все APK-файлы, которые вы публикуете для одного и того же приложения, должны иметь одно и то же имя пакета и быть подписаны одним и тем же ключом сертификата .
Каждый APK должен иметь свой код версии , указанный атрибутом android:versionCode .
Каждый APK не должен точно соответствовать конфигурации другого APK .
То есть каждый APK должен декларировать немного различную поддержку хотя бы одного из поддерживаемых фильтров Google Play (перечисленных выше).
Обычно вы различаете APK-файлы по определенным характеристикам (например, поддерживаемым форматам сжатия текстур), поэтому в каждом APK-файле указывается поддержка различных устройств. Однако можно публиковать несколько APK-файлов, поддержка которых немного пересекается. Когда два APK-файла перекрываются (они поддерживают одни и те же конфигурации устройств), устройство, попадающее в этот диапазон перекрытия, получит APK с более высоким кодом версии (определяемым android:versionCode ).
Вы не можете активировать новый APK, код версии которого ниже, чем у APK, который он заменяет. Например, предположим, что у вас есть активный APK для экранов маленького — нормального размера с кодом версии 0400 , а затем попробуйте заменить его APK для тех же размеров экрана с кодом версии 0300 . Это вызывает ошибку, поскольку означает, что пользователи предыдущей версии APK не смогут обновить приложение.
APK, для которого требуется более высокий уровень API, должен иметь более высокий код версии .
Это верно только в том случае, если: APK-файлы различаются только на основе поддерживаемых уровней API (никакие другие поддерживаемые фильтры не отличают APK-файлы друг от друга) или когда APK-файлы используют другой поддерживаемый фильтр, но между APK-файлами в этом фильтре существует перекрытие. .
Это важно, поскольку устройство пользователя получает обновление приложения из Google Play только в том случае, если код версии APK в Google Play выше, чем код версии APK, который в данный момент находится на устройстве. Это гарантирует, что если устройство получит обновление системы, которое затем позволяет ему установить APK для более высоких уровней API, устройство получит обновление приложения, поскольку код версии увеличится.
Примечание. Размер увеличения кода версии не имеет значения; он просто должен быть больше в версии, поддерживающей более высокие уровни API.
Вот несколько примеров:
- Если загруженный вами APK для уровней API 16 и выше (Android 4.1.x+) имеет код версии 0400 , то APK для уровней API 21 и выше (Android 5.0+) должен иметь 0401 или выше. В этом случае уровень API является единственным поддерживаемым фильтром, поэтому коды версий должны увеличиваться в соответствии с поддержкой уровня API для каждого APK, чтобы пользователи получали обновление при получении обновления системы.
- Если у вас есть один APK для уровня API 16 (и выше) и малых и больших экранов, а другой APK для уровня API 21 (и выше) и больших экранов (xlarge), то коды версий должны увеличиваться в соответствии с уровнями API. В этом случае для распознавания каждого APK используется фильтр уровня API, а также размер экрана. Поскольку размеры экранов совпадают (оба APK-файла поддерживают большие экраны), коды версий должны быть в порядке. Это гарантирует, что устройство с большим экраном, которое получает обновление системы до уровня API 21, получит обновление для второго APK.
- Если у вас есть один APK для уровня API 16 (и выше) и маленьких — нормальные экраны, а другой APK для уровня API 21 (и выше) и больших — xlarge экранов, то коды версий не должны увеличиваться в корреляции с Уровни API. Поскольку в фильтре размера экрана нет перекрытия, нет устройств, которые потенциально могли бы перемещаться между этими двумя APK, поэтому нет необходимости увеличивать коды версий с более низкого уровня API до более высокого уровня API.
- Если у вас есть один APK для уровня API 16 (и выше) и процессоров ARMv7, а другой APK для уровня API 21 (и выше) и процессоров ARMv5TE, то коды версий должны увеличиваться в соответствии с уровнями API. В этом случае для распознавания каждого APK используется фильтр уровня API, а также архитектура ЦП. Поскольку APK с библиотеками ARMv5TE совместим с устройствами с процессором ARMv7, эти характеристики APK совпадают. Таким образом, код версии APK, поддерживающего уровень API 21 и выше, должен быть выше. Это гарантирует, что устройство с процессором ARMv7, которое получает обновление системы до уровня API 21, получит обновление для второго APK, разработанного для уровня API 21. Однако, поскольку такое обновление приводит к тому, что устройство ARMv7 использует APK, который не полностью оптимизирован для ЦП этого устройства, вам следует предоставить APK для архитектуры ARMv5TE и ARMv7 на каждом уровне API, чтобы оптимизировать производительность приложения на каждом ЦП. Примечание. Это применимо только при сравнении APK-файлов с библиотеками ARMv5TE и ARMv7, а не при сравнении других собственных библиотек.

Несоблюдение вышеуказанных правил приведет к ошибке в консоли Google Play при активации APK — вы не сможете опубликовать свое приложение, пока не устраните ошибку.

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

Когда вы изменяете APK, чтобы «сжать» поддержку характеристик устройства, другие APK не поддерживают устройства, которые выходят за пределы поддерживаемого диапазона. Например, если APK в настоящее время поддерживает экраны маленького и нормального размера, и вы измените его на поддержку только маленьких экранов, вы сократили пул поддерживаемых устройств, и некоторые устройства больше не будут видеть ваше приложение в Google Play. Вы можете решить эту проблему, добавив еще один APK, который поддерживает экраны обычного размера, чтобы все ранее поддерживаемые устройства по-прежнему поддерживались.
Когда есть «перекрытия» между двумя или более APK-файлами. Например, если APK поддерживает маленькие, нормальные и большие размеры экрана, а другой APK поддерживает большие и большие размеры, происходит перекрытие, поскольку оба APK поддерживают большие экраны. Если вы не устраните эту проблему, то устройства, подходящие для обоих APK (в примере устройства с большим экраном), получат тот APK, который имеет самый высокий код версии.
Примечание. Если вы создаете отдельные APK для разных архитектур ЦП, имейте в виду, что APK для ARMv5TE будет дублировать APK для ARMv7. То есть APK, разработанный для ARMv5TE, совместим с устройством ARMv7, но обратное неверно (APK, содержащий только библиотеки ARMv7, несовместим с устройством ARMv5TE).

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

Создание нескольких APK

Если вы решите опубликовать несколько APK-файлов, вам, вероятно, придется создать отдельные проекты Android для каждого APK-файла, который вы собираетесь опубликовать, чтобы можно было соответствующим образом разрабатывать их отдельно. Вы можете сделать это, просто продублировав существующий проект и дав ему новое имя. (В качестве альтернативы вы можете использовать систему сборки, которая может выводить различные ресурсы, например текстуры, в зависимости от конфигурации сборки.)

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

При создании нескольких проектов для одного и того же приложения рекомендуется идентифицировать каждый из них по имени, указывающему ограничения на устройства, которые будут установлены в APK, чтобы вы могли легко их идентифицировать. Например, «HelloWorld_21» может быть подходящим именем для приложения, разработанного для уровня API 21 и выше.

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

Назначение кодов версий

Каждый APK для одного и того же приложения должен иметь уникальный код версии , указанный атрибутом android:versionCode . Вы должны быть осторожны при назначении кодов версий при публикации нескольких APK, поскольку каждый из них должен быть разным, но в некоторых случаях должен или должен быть определен в определенном порядке в зависимости от конфигураций, которые поддерживает каждый APK.

Коды версий для заказа

APK, для которого требуется более высокий уровень API, обычно должен иметь более высокий код версии. Например, если вы создаете два APK для поддержки разных уровней API, APK для более высоких уровней API должен иметь более высокий код версии. Это гарантирует, что если устройство получит обновление системы, которое затем позволяет ему установить APK для более высоких уровней API, пользователь получит уведомление о необходимости обновления приложения. Дополнительную информацию о том, как применяется это требование, см. в разделе «Правила для нескольких APK» выше.

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

Например, если у вас есть разные APK-файлы в зависимости от размера экрана, например один для маленького — нормальный и один для большого — xlarge, но предвидите время, когда вы измените APK-файлы на один для маленького и один для обычного — xlarge, тогда вам следует сделать код версии для большого APK-файла xlarge выше. Таким образом, устройство нормального размера получит соответствующее обновление при внесении изменений, поскольку код версии увеличивается с существующего APK до нового APK, который теперь поддерживает это устройство.

Кроме того, при создании нескольких APK-файлов, которые различаются поддержкой различных форматов сжатия текстур OpenGL, имейте в виду, что многие устройства поддерживают несколько форматов. Поскольку устройство получает APK с самым высоким кодом версии, когда покрытие двух APK перекрывается, вам следует упорядочить коды версий среди ваших APK, чтобы APK с предпочтительным форматом сжатия имел самый высокий код версии. Например, вы можете выполнить отдельные сборки для своего приложения, используя форматы сжатия PVRTC, ATITC и ETC1. Если вы предпочитаете эти форматы именно в таком порядке, то APK, использующий PVRTC, должен иметь самый высокий код версии, APK, использующий ATITC, — более низкий код версии, а версия с ETC1 — самый низкий. Таким образом, если устройство поддерживает как PVRTC, так и ETC1, оно получает APK с PVRTC, поскольку оно имеет самый высокий код версии.

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

Использование схемы кода версии

Чтобы позволить различным APK обновлять свои коды версий независимо от других (например, когда вы исправляете ошибку только в одном APK, поэтому не нужно обновлять все APK), вам следует использовать схему для ваших кодов версий, которая обеспечивает достаточно места между каждым APK, чтобы вы могли увеличить код в одном, не требуя увеличения других. Вам также следует включить в код фактическое имя версии (то есть видимую пользователю версию, назначенную android:versionName ), чтобы вам было легко связать код версии и имя версии.

Примечание. При увеличении кода версии APK Google Play предложит пользователям предыдущей версии обновить приложение. Таким образом, чтобы избежать ненужных обновлений, не следует увеличивать код версии для APK, которые фактически не содержат изменений.

Мы предлагаем использовать код версии, состоящий как минимум из 7 цифр: целые числа, представляющие поддерживаемые конфигурации, находятся в старших битах, а имя версии (из android:versionName ) — в младших битах. Например, если имя версии приложения — 3.1.0, коды версий для APK уровня API 4 и APK уровня API 11 будут выглядеть примерно так: 0400310 и 1100310 соответственно. Первые две цифры зарезервированы для уровня API (4 и 11 соответственно), средние две цифры — для размеров экрана или форматов текстур GL (не используются в этих примерах), а последние три цифры — для названия версии приложения. (3.1.0). На рис. 1 показаны два примера, которые разделены по версии платформы (уровень API) и размеру экрана.

Рисунок 1. Предлагаемая схема кодов версий, в которой первые две цифры обозначают уровень API, вторая и третья цифры обозначают минимальный и максимальный размер экрана (1–4, обозначающие каждый из четырех размеров) или форматы текстур. и последние три цифры версии приложения.

Эта схема кодов версий — это всего лишь предложение того, как вам следует создать шаблон, который можно масштабировать по мере развития вашего приложения. В частности, эта схема не демонстрирует решения для идентификации различных форматов сжатия текстур. Одним из вариантов может быть определение собственной таблицы, в которой будет указано разное целое число для каждого из различных форматов сжатия, поддерживаемых вашим приложением (например, 1 может соответствовать ETC1, а 2 — ATITC и т. д.).

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