Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 11:03
Apps4all

Как публиковать приложения для Android-устройств на платформе x86 в Google Play, используя поддержку Multiple APK

​Google Play добавил поддержку множественных APK для x86 CPU-архитектуры. Эта опция позволит вам публиковать различные APK для вашего приложения, каждый из которых адаптирован под x86 CPU-архитектуру. APK – это полная и независимая версия вашего приложения, однако все CPU версии находятся в одном месте в Google Play, имеют одинаковое название и подписаны одним ключом. Опция оказывается полезной в тех случаях, когда ваше приложение не может подойти для всех желаемых устройств в виде одного APK, как, к примеру, приложение, разработанное с использованием Android NDK. Вы можете посетить страничку Google Multiple APK Support на сайте Android Developer для получения дополнительной информации.

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

Создание множественных APK

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

Подсказка:

Один из способов избежать дублирования больший крупных частей кода вашего приложения – это использовать библиотеку проекта. Она хранит общий код и ресурсы, которые вы можете включить в ваши актуальные приложения. Создавая различные проекты для одного и того же приложения, правильно давать им имена, в которых отражены ограничения устройств для использования в APK. Так вы сможете легко ориентироваться среди них. Например, "HelloWorld_8" будет отличным именем для приложения, созданного под API 8 уровня и выше.

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

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

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

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

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

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

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

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

Многие устройства также поддерживают множественные ABI, к примеру, и ARMv7 и ARMv5TE. Многие x86 ABI-устройства могут также исполнять ARMv7 и ARMv5TE. Вам следует расставлять коды версии так, чтобы APK с наилучшей производительностью выполнялся на каждом устройстве. Например, расставьте коды версии таким образом, чтобы у x86 APK был наиболее высокий код, следом ARMv7 и затем ARMv5TE. Таким образом, x86 APK будет предпочтительным для х86-устройств, и ARMv7 APK – для ARMv7-устройств.

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

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

Мы предлагаем использовать код версии, как минимум, из 8 цифр. Цифры, представляющие поддерживаемые конфигурации, находятся в старшем разряде, а имя версии (из android:versionName) – в младшем разряде. К примеру, когда имя версии приложения – 3.1.0, код версии для ARMv7 ABIи APK с 4 уровнем APIбудет похож на 20400310. Другой пример: когда имя версии приложения – 3.1.0, код версии для x86 ABI и APK с 11 уровнем API будет похож на 61100310. Первая цифра показывает поддерживаемый ABI, 2-я и 3-я зарезервированы под уровень API (4 и 11, соответственно), 4-я и 5-я цифры отданы под размер экрана или форматы текстур GL (в этих примерах не используется), и последние три цифры демонстрируют имя версии приложения (3.1.0). На рисунке 1 показано два примера кодов, состоящих из кода ABI, уровня API и размера дисплея. Код ABI: 7 - x86_64, 6 - x86, 3 - ARM64-V8A, 2 - ARMv7, 1 - ARMv5TE.

version%20code.png

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

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

 
Intel
разработка
разработка мобильных приложений
разработчикам
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться