Android ant build fail

Автоматическая сборка Android-проектов в Ant

Достался мне на новой работе в поддержку и разработку средних размеров проект Android приложения, которое контора планирует выпустить как дополнение к десктопной версии. После ознакомления с фронтом работ, руководство дало задание сделать автоматическую сборку realise-версии «в один клик». До этого все мои проекты прекрасно собирались в IDE, а предстояло сделать безИДЕшную реализацию, поэтому пришлось пройти путь граблей и шишек. Соли добавляло обстоятельство что в проекте используется зависимость от ActionBarSherlock (Maven-проект, apklib).

Аутсорсеры, делавшие проект до меня, использовали Intelij IDE, я же в основном использую в работе NetBeans и Eclipse. Открыть и собрать проект в Eclipse не составило особого труда, только путь к ABS пришлось указать. Компиляция, сборка и запуск готового apk прошла без проблем. А вот с NetBeans такой фокус не прошел. Он упорно отказывается принимать ABS как библиотеку. Погуглив, выяснилось что это баг в НетБинс (к примеру как тут у человека), нашел даже тикет на официальном багрепорте. Так же нашел парочку способов собрать из под НетБинса (изменение pom.xml, копирование исходников ABS в папку основного проекта), но они мне не подходили (дана была четкая установка сделать так, чтобы зависимости основной проект вообще брал с внешнего репозитория и никак не влиял на них).

Поигравшись с IDE, начал реализовывать автосборку. Гугление вывело на эту и эту статью. После нескольких экспериментов был написан такой мануал:

1. Устанавливаем (вдруг у кого не стоит) JAVA_HOME и ANDOID_HOME (к примеру C:\Program Files (x86)\Java\jdk1.7.0_07 и D:\android\android-sdk)
2. Устанавливаем в Path пути к Android tools и Ant (у меня Ant отдельно, последняя версия). Что-то вроде такого должно быть
D:\android\android-sdk\tools;D:\android\android-sdk\platform-tools;D:\android\android-sdk\bin;D:\android\apache-ant-1.9.0\bin
3. Для ленивых открываем проект в NetBens, он создаст основные файлы, для остальных выполняем команду android rebuild , она должна создать необходимые файлы.
4. Поскольку собираем realise-версию, ложим наш файл key.keystore (или как он у вас называется) в папку проекта. В файл ant.properties добавляем:

key.store=key.keystore
key.alias=mykey
key.store.password=pass1
key.alias.password=pass2

5. В project.properties добавляем пути к нашей apklib-зависимости:

android.library.reference.1=../ActionBarSherlock
android.library=false
Сама папка проекта ABS лежит рядом с папкой нашего проекта.

6. Если нужно запускать ProGuard, в том же файле пишем (или раскомментируется):

6. Поскольку у меня задача была сделать сборку «в один клик», создаем батник с содержимым:

echo Build
call ant release
pause
(первая и последняя строчки опционально)

Итогом мы должны получить такую структуру проекта:

ActionBarSherlock/
src/
res/
bin/
libs/
pom.xml
AndroidManigest.xml
…

MyProject/
src/
res/
bin/
jni/
libs/
project.properties
ant.properties
build.xml
build.bat
AndroidManigest.xml
…

Если все сделано правильно, по нажатию на батник мы увидим консоль сборки

Источник

Continuous Integration для Android

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

• unit тестирование,
• интеграционное тестирование,
• тестирование интерфейса,
• тестирование этих типов тестов на различных версиях Android и конфигурациях девайсов,
• рассылка по email в случае сломанного билда;
• таже не помешает автоматическая сборка релизов.

Почти сразу же попался сайт testdroid.com, которые предлагает почти всё то же, и даже больше (тестирование на реальных девайсах), но, естественно, за денюжку.
В связи с этим после двухнедельных изысканий выбор был остановлен на связке на Jenkins + билд-скрипты на Ant (под Windows).

Итак, как же всё это поднять?!

Предварительные условия:

Шаг 1. Установка переменных окружения (необязательный, но так проще).

Создаём в окружении системы (System variables) переменную ANDROID_HOME и указываем в её значеии путь до папки Android SDK. У меня это путь D:\android\android-sdk-windows.
Также добавляем в переменную Path значнеие ;%ANDROID_HOME%\platform-tools.

Шаг 2. Установка Ant

Скачиваем zip-архив с http://ant.apache.org/bindownload.cgi и распаковываем в какую-нибудь папку (например d:\server\android\ant). Папку ant\bin также необходимо добавить в системную переменную окружения Path.

Шаг 3. Подготовка build-скрипта для ant.

1. android update test-project -m ..\MyProject -p MyProjectTest

Шаг 5. Установка Jenkins.

Заходим на http://jenkins-ci.org/, там справа есть ссылки на дистрибутивы, скачиваем и устанавливаем. По-умолчанию он устанавливается и предоставляет веб-интерфейс по адресу http://127.0.0.1:8080/.

Тут есть небольшая проблема. По умолчанию сервис Jenkins стартует из-под пользовательского аккаунта System, что ведёт к невозможности для плагина, рулящего эмуляторами, создавать AVD в домашней папке аккаунта. Пользователя нужно поменять либо на ваш аккаунт, либо создать специальный аккаунт для Jenkins’а.

Если кто вдруг не знает, для этого нужно зайти в Computer Management (самы простой способ: Start > Computer (правой кнопкой) > Manage (Управление)), там выбираем Services and Applications > Services, находим сервис Jenkins > Properties > закладка LogOn. После смены аккаунта сервис необходимо перезапустить.

Шаг 6. Настройка Jenkins.

Итак, захоидм по адресу http://127.0.0.1:8080/, выбираем Manage Jenkins далее выбираем Manage Plugins. Перейдите на вкладку Available Plugins. Если тут пусто, подождите некоторое время, Jenkins их просто ещё не подгрузил.
Нам понадобятся следующие:

• Jenkins Emma plugin
• Android Emulator Plugin
• Hudson Port Allocator Plug-in
• ant

Возможно некоторые из них у вас уже буду установлены изначально.
В моём случае потрбовалось ещё установить Subversion Plugin, поскольку у меня проект лежал в SVN. Если ваш проект находится под другой SCM, не забудьте установить для неё плагин.
Теперь, нажимаем кнопку «Install without restart” внизу, в процессе можно поставить галку »Restart Jenkins when installation is complete and no jobs are running” чтобы Jenkins перезапустился автоматом и плагины заработали.
Далее идём в Manage Jenkins > Configure System. Здесь

1. в секции Android нужно прописать Android SDK root (как уже писалось выше, в нашем случае это D:\android\android-sdk-windows)
2. Для рассылки email при поломке билда так же стоит заполнить секцию E-mail Notification.

Теперь создадим задание для Jenkins. На главной странице нажимаем New Job, вводим название, тип задания выбираем Build a free-style software project.

Тут необходимо заполнить следующие секции:

1. Source Code Management — выбираем тип вашей системы контроля версий и вводим необходимые параметры. Внимание! Необходимо, чтобы из репозитария вытягивалась только папка trunk, иначе вам нужно будет подправлять все пути, которые будут дальше в настройках задания для Jenkins.
2. Build Triggers — выбираем Poll SCM и прописываем туда * * * * *. Это будет означать, что Jenkns будет проверять репозитарий раз в минуту и, если там будут новые коммиты, запускать билд. Для сборки раз в 5 минут можно указать */5 * * * *.
3. Build Environment — Тут лучше поставить галочку Assign unique TCP ports to avoid collisions.
4. Run an Android emulator during build. Заполняем параметры эмулатора, например
   • Android OS Version: 2.1 (Убедитесь, что данная версия скачана у вас в SDK)
   • Screen density: 240
   • Screen resolution: WVGA
   • Device locale: en_US
   • SD card size: 16M
5. Раздел Build, добавляем Invoke Ant, в здесь
   • Target: all clean emma debug install test
   • Build File: QuickMeetingTest\build.xml
   • Properties: sdk.dir=D:\\android\\android-sdk-windows (именно так, с двойными слешами)

6. Раздел Post-build Actions
   • Archive the artifacts: **/*test-TEST.xml
   • Publish JUnit test result report: **/*test-TEST.xml
   • Record Emma coverage report: **/coverage.xml
   • Record fingerprints of files to track usage: **/*test-TEST.xml

7. E-mail Notification — настроить по своему вкусу.

Собственно, с настройкой Jenkins почти закончили, но не спешите, пока ещё не всё готово.

Есть две проблемы.

Проблема 1.

2. android:name = «pl.polidea.instrumentation.PolideaInstrumentationTestRunner»
3. android:targetPackage = «com.example.MyProject» />

Проблема 2.

Шаг 7. Добавление тестов UI.

Для этого есть удобный инструиент Robotium. Взять можно здесь code.google.com/p/robotium.
Настройка:

1. Скачиваем robotium-solo-3.1.jar (на данный момент это последняя версия), кладём в trunk\MyProjectTest\libs.
2. Добавляем в свойствах проекта в Java Build Path\Libraries
3. Создаём тестовый класс и наследуем его от ActivityInstrumentationTestCase2
   1. super ( «com.example.myproject» , MyActivity. class ) ;

   1. private Solo solo ;
   2. @Override
   3. publicvoid setUp ( ) throws Exception <
   4. solo = new Solo ( getInstrumentation ( ) , getActivity ( ) ) ;
   5. >
   6. @Override
   7. publicvoid tearDown ( ) throws Exception <
   8. solo. finishOpenedActivities ( ) ;
   9. >

   1. publicvoid testPreferenceIsSaved ( ) throws Exception <
   2. solo. sendKey ( Solo. MENU ) ;
   3. solo. clickOnText ( «More» ) ;
   4. solo. clickOnText ( «Preferences» ) ;
   5. solo. clickOnText ( «Edit File Extensions» ) ;
   6. Assert . assertTrue ( solo. searchText ( «rtf» ) ) ;
   7. solo. clickOnText ( «txt» ) ;
   8. solo. clearEditText ( 2 ) ;
   9. solo. enterText ( 2 , «robotium» ) ;
   10. solo. clickOnButton ( «Save» ) ;
   11. solo. goBack ( ) ;
   12. solo. clickOnText ( «Edit File Extensions» ) ;
   13. Assert . assertTrue ( solo. searchText ( «application/robotium» ) ) ;
   14. >

   Шаг 8. Тестирование на нескольких эмуляторах.

   1. При создании задания для Jenkins можно выбрать тип задания Build multi-configuration project.
   2. В разделе Configuration Matrix создаём оси для каждого изменяющегося параметра, например, разрешение и версия андроид и подставляем в настройки Run emulator with properties в виде $. Посмотрите картинки по вышеуказанной ссылке, всё станет понятно.
   3. Остальные параметы указываем как в обычном задании.

   Подробности тут.

   Шаг 9. Подготовка релизной сборки.

   1. Targets:
   2. release
   3. Build File:
   4. MyProject\build.xml
   5. Properties:
   6. sdk.dir = D:\\android\\android-sdk-windows
   7. key.store = ..\\myproject.keystore (относительный путь к файлу-хранилищу ключа, сам ключ я положил в trunk\)
   8. key.alias =
   9. key.store.password =

Можно ещё настроить Archive the artifacts с Files to archive = **\*-release.apk (если вы хотите бережно хранить все релизы и иметь возможность их скачивать через веб-интерфейс Jenkins).

Для обфускации релиза при помощи ProGuard потребуется всего лишь добавить в project.properties (или в properties шага InvokeAnt задания в Jenkins) строчку proguard.config=proguard.cfg, где

• proguard.config — имя переменной, в которой должно находиться имя файла с настройками для ProGuard,
• а файл proguard.cfg автоматически создаётся Eclipse при создании проекта.

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

Также отдельное спасибо за поддержку руководству компании Артезио, которое поддержало мою инициативу и выделило время на данное исследование.

Источник

Apache Ant – быстрый старт

Apache Ant должен быть знаком каждому Java-программисту: это популярный инструмент сборки ПО (build tool), полностью написанный на Java. Ant использует сценарий, который является обычным XML-файлом. Несмотря на его Java-направленность, веб-разработчики тоже используют этот инструмент.

Мы пройдём пять простых шагов, чтобы начать использовать Ant:

1. Скачаем, установим и проверим.
2. Напишем простой HelloWorld сценарий.
3. Разберёмся с принципами работы и XML форматом сценария сборки.
4. Узнаем минимально необходимый список заданий.
5. Напишем сценарий для полного цикла сборки и тестирования учебного проекта.

Нам потребуется Java SE Development Kit (JDK, скачиваем по адресу www.oracle.com/technetwork/java/javase/downloads), ваш любимый текстовый редактор (в Linux – vi/vim/gedit, для Windows рекомендую Notepad++) и базовые навыки работы в командной строке. Сценарии сборки и примеры на Java протестированы в Linux (Simply Linux 7.95.0, CentOS Linux 6.8) и в Windows (XP/7). Использование Ant одинаково и в Linux и в Windows.

1. Скачиваем, устанавливаем, проверяем

Linux: устанавливаем из репозитария командой вроде sudo apt-get install ant (замените apt-get на yum если необходимо). Важно: нам нужна версия не ниже 1.8.*. В репозитарии CentOS 6.8 версия 1.7.1, поэтому лучше использовать скрипт, описанный в предыдущей статье.

Windows: посещаем веб-сайт ant.apache.org, заходим в раздел Download/Binary Distributions и скачиваем архив apache-ant-1.10.1-bin.zip (возможно сейчас есть уже более свежая версия). Содержимое архива копируем в любой каталог, например в «C:\Program Files\Apache Ant». Затем добавляем путь к каталогу bin (C:\Program Files\Apache Ant\bin) в системную переменную Path.

Проверяем работоспособность, вызвав ant в командной строке:

$ ant -version
Apache Ant(TM) version 1.10.1 compiled on February 2 2017

Если аналогичное сообщение получено – всё в порядке.

2. Пишем HelloWorld сценарий

Создаём в домашнем каталоге подкаталог hello (в Linux это делает команда mkdir, в Windows – md) и сохраняем туда файл с именем build.xml, содержащий предложенный выше сценарий. Переходим в этот каталог и вызываем ant:

$ mkdir hello
$ cd hello
$ ant
Buildfile: /home/lamp/hello/build.xml

hello:
[echo] Hello, World!
BUILD SUCCESSFULL

Total time: 0 seconds

3. Основные принципы работы

В target есть возможность указать зависимость с помощью атрибута depends. Зависимости связывают target’ы между собой. Например, есть target c именем “compile”, а есть – с именем “run”, зависимый от “compile”. И если мы захотим выполнить “run”, сначала выполнится “compile”.

4. Минимально необходимый список заданий (tasks)

Стандартная версия Ant содержит более 150 заданий (https://ant.apache.org/manual/tasklist.html). Нам пока потребуются только семь:

• echo – вывод сообщений в консоль
• mkdir – создание директорий
• delete – удаление файлов и директорий
• javac – компиляция Java–кода
• java – запуск class и jar файлов
• jar – создание jar файла
• junit – запуск тестов

5. Сценарий для сборки и тестирования Java проекта

И сохраняем туда файл HelloWorld.java следующего содержания:

А затем немного усложняем текст нашего сценария (build.xml):

Теперь сценарий содержит три target (команды): compile (компиляция файла(ов) .java), run (запуск файла .class), clean (удаление папок с результатами компиляции). При этом compile содержит два tasks – mkdir и javac. Обратите внимание на зависимость: target run предварительно вызовет compile. Кроме того run – это target по умолчанию для проекта.

Запускаем сценарий без параметров и видим результат работы Java программы: Hello, World!

Прямое указание имен каталогов не говорит о хорошем стиле. Особенно если имена в сценарии повторяются. Модифицируем build.xml, используя property (обратите внимание, как нам пригодилось имя проекта, заданное в project) и добавив пару комментариев:

Теперь добавим в сценарий target package для формирования jar файла:

и убедимся что всё работает:

$ ant package
$ java -jar build/HelloWorld.jar
Hello, World!

Перейдём к тестированию. Изменим код проекта (чтобы было что тестировать):

и добавим в каталог src файл/класс TestHello.java с простым тестом:

Используя информацию со страницы https://github.com/junit-team/junit4/wiki/getting-started скачиваем два файла, junit-4.12.jar и hamcrest-core-1.3.jar и копируем их в каталог нашего JDK/jre/lib/ext (такую команду копирования используем в CentOS 6.8):

$ java -cp build/classes org.junit.runner.JUnitCore TestHello
JUnit version 4.12
.
Time: 0,281
OK (1 test)

Добавляем в наш сценарий ещё один target – test:

и дополняем строку в target package (jar):

Теперь к списку команд нашего сценария (compile, run, package, clean) добавилась test.
В заключение меняем код нашего проекта так, чтобы приветствие выводилось в отдельном графическом окне. Затем формируем jar файл и запускаем его двойным кликом мыши (у вас должно быть настроено выполнение jar файлов по двойному клику).

Третья версия Java кода:

Слегка дополняем сценарий (в target run), дописав fork=«true» (запуск выполнения класса в другой виртуальной машине). В противном случае run не сработает (проверено экспериментально):

Выполняем команду формирования jar файла ($ ant package), открываем в проводнике файлов каталог

Источник