Автоматизация процесса сборки Android приложения при помощи Ant

Третьяков Илья Неотъемлемой частью разработки Android приложения является создание его сборки (build). В простейшем случае данный процесс заключается в изменении версии приложения и получение подписанного *.apk файла. Популярная среда разработки Eclipse позволяет с легкостью это сделать. Такой вариант, скорее всего, устроит программистов одиночек, которые сами разрабатывают небольшие приложения. Разработка крупных проектов выдвигает ряд дополнительных требований, а именно:
  • использования автоматической системы сборки (и последующего запуска тестов),
  • добавления некоторых специфических шагов в сборку,
  • использование сборок с различной конфигурацией.
Eclipse достаточно сложно использовать для этих целей. Однако, не все так плохо: Android SDK поддерживает Apache Ant. Apache Ant – это инструмент для автоматизации процесса сборки программного продукта, который очень популярен среди Java программиста. Именно он и поможет нам в решении задач, для которых трудно или невозможно использовать Eclipse. Для того, чтобы выполнить какое-либо действие с помощью Ant необходимо написать build-скрипт. Скрипты пишутся на языке XML. Скрипт сборки содержит один проект и как минимум одну цель. Цель (target) в build-скрипте – это набор задач(tasks), которые должны быть выполнены при вызове данной цели. Задача(task) же является просто некоторым кодом. Немаловажными элементами build-скрипта являются свойства (properties). Они используются для определения переменных в файлах сборки.

Необходимое ПО

Данное руководство предполагает, что у вас уже установлено следующее ПО: Для удобства использования этих инструментов стоит добавить директории, куда они были установлены, в переменные окружения. Для текущего сеанса работы это можно сделать с помощью команд (для Windows): set path=%PATH%;E:dev_toolsandroid_sdktools set path=%PATH%;E:dev_toolsapache_antbin В данном примере E:dev_toolsandroid_sdk и E:dev_toolsapache_ant – директории где находится Android SDK и Apache Ant соответственно.

Создание скрипта сборки

К счастью, писать с нуля скрипт нам не придется. Как я уже сказал выше Android SDK «из коробки» поддерживает Apache Ant. Поэтому нам достаточно будет обновить существующий проект с помощью команды: android update project –path В случае успешного выполнения вы увидите: E:workspaceTestProject>android update project –path . Updated local.properties Added file E:workspaceTestProjectbuild.xml Updated file E:workspaceTestProjectproguard.cfg Как видно в проекте появился файл build.xml. Это и есть скрипт сборки, и именно его нам потребуется доработать для решения поставленных целей. Так же если вы создаёте новый проект, то можно воспользоваться командой: android create project –target <target_ID> –name <your_project_name> –path path/to/your/project –activity <your_activity_name> –package <your_package_namespace> Параметрами команды являются:
  • target_ID – соответствует версии библиотеки Android platform, которую необходимо использовать при сборке. Список доступных библиотек можно просмотреть с помощью команды android list targets,
  • your_project_name – название проекта,
  • path/to/your/project – директория, где необходимо разместить проект,
  • your_activity_name – название Activity,
  • your_package_namespace – имя пакета приложения.

Подписание Android приложения

Android OS требует, чтобы все устанавливаемые приложения были подписаны сертификатом, которым владеет разработчик приложения. Если вы потеряете сертификат, то вы не сможете выложить обновление для своего приложения. Стоит также отметить, что все сборки которые вы создаете в процессе разработки, уже подписаны DEBUG сертификатом. Однако, вы все равно не можете установить его на устройство (кроме как, используя Android SDK) и естественно эту сборку нельзя будет выложить в Android маркет. Более подробно про подписание приложения можно прочитать в документации Android OS[5]. Для подготовки сборки к публикации требуется:
  1. Создать сертификат (только один раз)
  2. Сделать сборку
  3. Подписать сборку созданным сертификатом.
В Eclipse есть специальный мастер для выполнения этих этапов (Project Properties -> Android Tools -> Export Signed Application Package…). Нам же требуется автоматизировать, как можно больше вещей, которые ранее разработчик делал вручную, и шаги №2 и №3 будут первые в очереди. Для достижения это цели мы добавим информацию о нашем сертификате в файл ant.properties (в старых версиях Android SDK – build.properties). Если файла нет в директории проекта, то создайте его. Свойства, которые надо добавить: key.store=path_to_keystore key.alias=mykeystore key.store.password=password1 key.alias.password=password2 Значения свойств:
  • path_to_keystore – путь к файлу хранилища сертификатов;
  • mykeystore – псевдоним сертификата;
  • password1 – пароль к хранилищу сертификатов;
  • password2 – пароль к псевдониму сертификата.
Внимание! Возможно, в вашей компании запрещено хранить в VCS (системе контроля версий) эти данные. Поэтому убедитесь, что вы не нарушаете корпоративные правила. Проверим, что у нас все работает правильно: E:workspaceTestProject>ant release Buildfile: E:workspaceTestProjectbuild.xml -set-mode-check: -set-release-mode: -release-obfuscation-check: -setup: [echo] Gathering info for TestAndroidActivity… // skip some output -release-nosign: release: [echo] Signing final apk… [signjar] Signing JAR: E:workspaceTestProjectbinTestAndroidActivity-release-unsigned.apk to E:workspaceTestProjectbinTestAndroidActivity-release-unaligned.apk as test_alias [zipalign] Running zip align on final apk… [echo] Release Package: E:workspaceTestProjectbinTestAndroidActivity-release.apk BUILD SUCCESSFUL Total time: 16 seconds Как видно, теперь мы с помощью одной команды можем получать release-сборку.

Создание сборок с различной конфигурацией

При разработке приложения программисты делают огромное количество сборок: для себя во время разработки нового функционала, для тестера, чтобы он проверил все ли выполнено верно, для заказчика, чтобы он был в курсе как идут дела у его продукта. В свою очередь все эти сборки могут отличаться. Например, программисты хотят получать максимум информации в лог (logcat для Android), в то же время для сборки, которая будет публиковаться, это не требуется. Сборка, которая будет выкладываться в маркет, может содержать код отправляющий статистику использования приложения на сервер. Если сборки программистов и тестеров будут делать то же самое, то это только исказит статистику. Если приложение публикуется не только в Android Market, но еще и в других магазинах (Amazon AppStore, GetJar и т.д.), то следует добавить автоматическую отправку отчетов об ошибках разработчикам. Это поможет как можно быстрее исправлять ошибки. Однако данный функционал следует отключать во время разработки, чтобы ошибки, которые делают программисты во время работы, не попадали в общую базу. Для простоты мы сократим все возможные варианты конфигураций до одного параметра DEBUG. Остальные вы сможете с легкостью добавить сами. Создадим два файла, содержащие этот параметр для development-сборки:
package com.enterra.android.apps.test.settings; /** * This is configuration file for development-builds. * If you want to change it – edit file &lt;project_root&gt;/dev_config/Configuration.java. * Then use Ant script for switching between configurations. */ public class Configuration { public final static Boolean DEBUG = true; }
и для release-сборки:
package com.enterra.android.apps.test.settings; /** * This is configuration file for release-builds. * If you want to change it – edit file <project_root>/release_config/Configuration.java. * Then use Ant script for switching between configurations. */ public class Configuration { public final static Boolean DEBUG = false; } Первый файл будет находиться в директории “<project_root>/config_dev”, второй – “<project_root>/config_release”. Также нам необходимо будет скопировать один из этих файлов в директорию с исходным кодом. В моем случае это будет: <project_root>/src/com/enterra/android/apps/test/settings. Теперь добавим в наш скрипт сборки код, который будет менять настройки в зависимости от того, какую сборку требуется сделать.
Configuration file: ${config.filename}   Selected developer configuration Selected release configuration С этого момента, чтобы получить сборку, необходимо использовать команды ant release-public для release-сборки и ant release-dev для development-сборки. Данный скрипт заменяет файл конфигурации в коде на необходимый и дальше запускает стандартный процесс сборки. Пример вывода в консоль успешно отработавшего скрипта: E:workspaceTestProject>ant release-public Buildfile: E:workspaceTestProjectbuild.xml release-public: [echo] Selected release configuration switch-config: [echo] Configuration file: config_release/Configuration.java [copy] Copying 1 file to E:workspaceTestProjectsrccomenterraandroidappstestsettings -set-mode-check: -set-release-mode: -release-obfuscation-check: -setup: // skip some output release: [echo] Signing final apk… [signjar] Signing JAR: E:workspaceTestProjectbinTestAndroidActivity-release-unsigned.apk to E: workspaceTestProjectbinTestAndroidActivity-release-unaligned.apk as test_alias [zipalign] Running zip align on final apk… [echo] Release Package: E:workspaceTestProjectbinTestAndroidActivity-release.apk BUILD SUCCESSFUL Аналогичным образом можно добавить еще одну конфигурацию для тестеров. Кроме этого, не должно составить труда и использование дополнительных параметров для сервисов статистики, отправки сообщений об ошибках и т.д.

Версия приложения

В Android за версию приложения отвечает 2 атрибута из манифеста (файл AndroidManifest.xml):
  • android:versionName – строковое представление версии приложения. Предназначен только для отображения пользователю.
  • android:versionCode – внутренний номер версии (целое число). Используется для определения, какая версия приложения вышла позже. Данное число должно увеличиваться с каждой новой версией. Увидеть данное число средствами Android OS можно только через Application Manager.
Таким образом, нам необходимо сделать, чтобы android:versionCode с каждой release сборкой увеличивался на единицу. В случае android:versionName мы будет генерировать версию из двух частей: major и minor. Первая часть (major) всегда будет изменяться разработчиком, вторая (minor) – будет так же увеличиваться на единицу при каждой сборке. Для реализации описанного функционала создадим файл <project_root>/version.properties, содержащий информацию о текущей версии приложения: app.version.code=10 app.version.major=1.0. app.version.minor=4 Следующим шагом будет добавление задачи в build-скрипт:
Version code: ${app.version.code} Version name: ${app.version.major}${app.version.minor} Суть данного скрипта заключается в том, что он берет свойства app.version.code и app.version.minor из файла <project_root>/version.properties, увеличивает их на единицу и сохраняет эти значения. Затем он обновляет атрибуты android:versionName и android:versionCode в файле AndroidManifest.xml. Данную задачу можно запустить отдельно, чтобы проверить правильность ее выполнения: E:workspaceTestProject>ant increase-version Buildfile: E:workspaceTestProjectbuild.xml increase-version: [propertyfile] Updating property file: E:workspaceTestProjectversion.properties [propertyfile] Updating property file: E:workspaceTestProjectversion.properties [echo] Version code: 11 [echo] Version name: 1.0.5 BUILD SUCCESSFUL Финальным шагом будет добавления выполнения этого скрипта в задачу release-public:
Selected release configuration

Взаимодействие с системой контроля версий (VCS)

Важный момент, который осталось обсудить, это правила работы с системой контроля версий и созданными файлами.
  1. Нельзя добавлять файл local.properties в систему контроля версий.
  2. Необходимо добавить в систему контроля версий файлы ant.properties, version.properties, default.properties и build.xml
  3. Так же необходимо добавить в VCS файлы конфигураций (config_dev/Configuration.java, config_release/Configuration.java).
  4. Разработчики не должны вносить в VCS локальные изменения параметров в файле конфигурации <project_root>/src/…/Configuration.java. Данное правило не относится к добавлению новых параметров.
  5. После создания release-сборки, сделайте также tag для нее. Это поможет в будущем для нахождения ошибок по присылаемым отчетам об ошибках.

Заключение

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

Ссылки

  1. http://developer.android.com/
  2. http://developer.android.com/sdk/installing.html
  3. http://ant.apache.org
  4. http://ant.apache.org/bindownload.cgi
  5. http://developer.android.com/guide/publishing/app-signing.html
Хотите использовать наш опыт в разработке мобильных приложений для Android? Начните с оценки Вашего проекта прямо сейчас!