Создание нескольких apk для 2+ измерений (Creating Multiple APKs with 2+ Dimensions)


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

Убедитесь что вам необходимо иметь несколько apk

При попытке создать приложение, которое работает с огромным диапазоном доступных устройств, естественно, вы захотите, чтобы ваше приложение выглядело наилучшим образом на каждом из них. Вы захотите воспользоваться всем пространством больших экранов, но также поддерживать и маленькие, использовать новые функции Android API или доступные визуальные текстуры на новых устройствах, но и не отказываться от старых. С самого начала может показаться, что использование нескольких APK является лучшим решением, но это часто не так. Раздел Использование одного APK вместо того, чтобы в руководстве разработчика нескольких APK включает в себя некоторую полезную информацию о том, как сделать это в одном APK, включая использование нашей support library, а также ссылки на ресурсы по всему Android Developer guide.

Если вы сможете управлять этим, ограничивая приложение одним APK, то получите ряд преимуществ, в том числе:

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

Остальная часть этого урока предполагает, что вы исследовали тему, старательно изучили связанный с темой материал в ресурсах, и определили, что несколько APK это правильный путь вашего приложения.

Составление диаграммы ваших требований

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

3 4 5 6 7 8 9 10 11 12 +
small
normal
large
xlarge

Выше приведен пример с четырьмя APK. Синий для всех small/normal экранов, зеленый для large экранов и красный для xlarge экранов устройств, все из диапазона API 3-10. Фиолетовый является особым случаем, так как этот APK для всех размеров экрана, но только для API 11 и выше. Что еще более важно так это то, что просто взглянув на эту диаграмму, вы сразу же знаете, какой APK охватывает любую из комбинаций API/размера экрана. У вас также есть шикарные кодовые имена для каждого из APK, вопрос вроде “Есть ли у нас протестированный красный?” намного проще, чем “Неужели мы протестировали 3 из 10 xlarge APK на Xoom?” Распечатайте эту диаграмму и вручите ее каждому человеку, работающему с вашим кодом. Жизнь стала намного легче.

Объединение общего кода и ресурсов в проект библиотеки

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

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

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

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

Создание нового APK проекта

Для каждого APK, который вы собираетесь выпустить, должен быть отдельный Android проект. Для простоты организации, поместите проект библиотеки и все проекты, связанные с АПК, в ту же родительскую папку. Также помните, что имя пакета для каждого APK должно быть одинаковым, хоть они и не обязаны делить имя пакета с библиотекой. Если бы у вас было 4 APK, то по схеме, описанной ранее, ваша корневая директория может выглядеть следующим образом:

Как только проекты будут созданы, добавьте проект библиотеки в качестве ссылки в каждый проект АПК. Если это возможно, определите, стартовую активити в проекте библиотеки и наследуйте эту активити в вашем проекте APK. Наличие стартовой активити, определенной в проекте библиотеки, дает вам шанс поместить всю инициализацию вашего приложения в одном месте, таким образом каждый APK избавится от надобности в повторной реализации “универсальных” задач, таких как инициализация Analytics, запуск проверки лицензирования и любых других процедур инициализации, которые часто не изменяются от APK к APK.

Регулировка манифестов

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

  • Манифест должен показать какой APK может быть использован
  • Из подходящих APK выигрывает тот, у которого больший номер версии

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

3 4 5 6 7 8 9 10 11 12 +
small
normal
large
xlarge

Мы можем описать области, охватываемые каждым APK вот так:

  • Синий охватывает все экраны, minSDK 3.
  • Зеленый охватывает Large экраны и больше, minSDK 3.
  • Красный охватывает XLarge экраны (как правило это планшеты), minSDK 9.
  • Фиолетовый охватывает все экраны, minSDK 11.

Обратите внимание на то, что есть много перекрытий в этих правилах. Например, XLarge устройства с API 11 предположительно могут запустить любой из 4 указанных APK. Однако с помощью правила “выигрывает тот, у которого больший номер версии”, мы можем установить порядок предпочтения следующим образом:

Фиолетовый ≥ Красный ≥ Зеленый ≥ Синий

Почему позволяютсят пересечения? Давайте представим, что фиолетовый APK имеет некоторые требования, а два других – нет.
Страница Market Filters в Android Developer guide имеет целый список возможных требований. Ради примера, давайте предположим, что фиолетовый требует переднюю камеру. На самом деле, вся суть фиолетового APK в том, чтобы делать разные занимательные вещи с использованием фронтальной камеры. Но, оказывается, не все устройства, поддерживающие API 11+ имеют фронтальную камеру! Ужас!

К счастью, если пользователь просматривает маркет с такого устройства, Android Market будет проверять манифест приложения, увидит в Фиолетовом списке требование наличия передней камеры и спокойно проигнорирует его, определив, что фиолетовый и устройство не соответствуют. Он увидит, что Красный не только совместим с xlarge устройствами, но и не заботится о наличии передней камеры! Пользователь может загрузить приложение из Android Market, поскольку, несмотря на отсутствие передней камеры, APK попрежнему поддерживает определенный уровень API.

Для сохраннения порядка всех ваших APK в отдельных треках, очень важно иметь хорошую схему нумерации версий кода. Рекомендуется найти одну из них на странице Version Codes руководства разработчика. Стоит прочитать весь раздел, но основная суть для этого набора APK заключается в том, что мы будем использовать две цифры представляющие minSDK и минимальный/максимальный размер экрана, а 3-я цифра – номер сборки. Таким образом, когда устройство обновлено до новой версии Android, (скажем 10 или 11), любой APK из набора является допустимым и предпочтительным, в противном случае установленный APK будет рассматриваться устройством как требующий “обновления”. Схема нумерации версий для данного набора APK, может выглядеть так:

Синий: 0304001, 0304002, 0304003…

Зеленый: 0334001, 0334002, 0334003…

Красный: 0344001, 0344002, 0344003…

Фиолетовый: 1104001, 1104002, 1104003…

Собрав все вместе в ваш Android манифест, скорее всего вы получите что-то вроде:

Синий:

Зеленый

Красный

Фиолетовый

Обратите внимание, что технически несколько APK будут работать с любым тегом поддержки (supports-screens) или совместимости (compatible-screens) экрана. Поддержка экрана – предпочтительнее, и обычно очень плохая идея использовать оба тега в одном манифесте. Это приводит к усложнению, а также увеличивает возможность появления ошибок. Также отметим, что вместо того, чтобы воспользоваться значениями по умолчанию (small и normal всегда true по умолчанию), манифест явно указывает значение для каждого размера экрана. Это может уберечь вас от головной боли в будущем. Например, манифест с target SDK <9 по умолчанию будет иметь xlarge установленном как false, так как такого размера экрана еще не существовало.

Соблюдение контрольного списка предзапуска приложения

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

  • Все APK должны иметь одинаковое имя пакета
  • Все APK должны быть подписаны одинаковым сертификатом
  • Если APK перекрывают версии платформы, один из них, с наивысшим minSdkVersion, должен иметь более высокую версию кода.
  • Для каждого размера экрана, который вам нужен в APK, установите true в манифесте. Для каждого размера экрана, который вам не нужен – установите false
  • Тщательно проверьте настройки фильтров для выявления противоречивой информации (APK, который поддерживает только cupcake на XLarge экранах не будет виден никому)
  • Каждый манифест APK должен быть уникальным хотя бы для одного из поддерживаемых экранов, OpenGL текстуры или версии платформы
  • Попробуйте протестировать каждый APK, по крайней мере на одном устройстве. Как исключение – у вас один из самых настраиваемых эмуляторов устройств на вашем компьютере. Вперед!

Стоит также проверить скомпилированный APK непосредственно перед отправкой в маркет, чтобы убедиться в отсутствии сюрпризов, которые могли бы скрыть ваше приложение в маркете. На самом деле это довольно просто – используйте инструмент "aapt". Aapt (the Android Asset Packaging Tool) является частью процесса сборки и упаковки вашего Android приложения, а также очень удобным инструментом для их проверки.

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

Почему? При добавлении необходимого разрешения SEND_SMS, было неявно добавлено требование android.hardware.telephony. Так как большинство (если не все) xlarge устройств являются планшетами без оборудования телефонии, маркет будет отфильтровывать этот APK, пока будущие устройства не будут достаточно большими, чтобы восприниматься как xlarge размер экрана, и будут обладать аппаратной телефонией.

К счастью, это легко исправить, добавив следующие строки в ваш манифест:

После сверки с контрольным списком загрузите APKs на Android Market. Чтобы приложение появилось в Android Market должно пройти немного времени, но когда это произойдет, выполните одну последнюю проверку. Скачайте приложение на любое устройство для тестирования, которое у вас есть, чтобы убедиться, что APKs ориентируются на свой диапазон устройств.

Оставьте комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *