Com android tools build maven

Содержание
  1. Building Android Apps with Apache Maven — Tutorial
  2. 1. Gradle for building Android applications
  3. 1.1. Using Gradle for Android apps
  4. 1.2. Conversion process from source code to Android application
  5. 1.3. Using Gradle on the command line
  6. 1.4. Removing unused resources and Java classes via resource shrinking
  7. 1.5. Defining dependencies and keeping the version external
  8. 2. Building Android applications with Maven
  9. 3. Tutorial: Building Android Applications with Maven
  10. 4. More information
  11. Публикация Android библиотеки
  12. Регистрация на Sonatype JIRA и создание Issue
  13. Создаем Android библиотеку в Android Studio
  14. Генерации GPG ключа
  15. Настройка библиотеки для публикации:
  16. Публикация
  17. Первый
  18. Второй
  19. Заключение
  20. Советы по работе с Gradle для Android-разработчиков
  21. Небольшой оффтоп для тех, кому совсем ничего не понятно в Gradle-скриптах
  22. #1 Не редактируйте Gradle-скрипты через IDE
  23. #2 Обращайте внимание на соглашение по именованию модулей
  24. #3 Что выбрать: Kotlin vs Groovy
  25. #4 Как прописывать зависимости в многомодульных проектах
  26. Java platform plugin
  27. Описание зависимостей в extra properties
  28. Описание зависимостей в скриптовом плагине
  29. Описание зависимостей в buildSrc
  30. Композитные сборки
  31. #5 Как обновлять зависимости
  32. #6 Старайтесь не использовать feature-флаги в build config
  33. #7 Несколько слов про базовую структуру проекта
  34. #8 Не забывайте про matchingFallbacks
  35. #9 Убирайте ненужные build variant
  36. #10 В некоторых модулях, завязанных на Android Framework, можно не использовать Android Gradle Plugin
  37. #11 Как написать Gradle-плагин для CI на примере gitlab
  38. Шаг 1: в настройках проекта на gitlab создать переменные окружения
  39. Шаг 2: создать композитную сборку
  40. Шаг 3: написать плагин
  41. Шаг 4: подключить плагин
  42. В заключение
  43. Что ещё посмотреть

Building Android Apps with Apache Maven — Tutorial

Android Maven. This tutorial describes how to build Android applications with Apache Maven and the «android-maven-plugin».

1. Gradle for building Android applications

1.1. Using Gradle for Android apps

By default, Android projects are handled by the Gradle build system. If you create a new project in Android studio, the Gradle build scripts are automatically created. Android studio provides the Gradle runtime, hence no additional installation is required.

If you press the run button in Android Studio, it triggers the corresponding Gradle task and starts the application.

You can also run Gradle via the command line. To avoid unnecessary local installation, Gradle provides a wrapper script which allows you to run Gradle without any local installation.

You find the available versions of the Android Gradle plug-in under the following URL: https://jcenter.bintray.com/com/android/tools/build/gradle/

1.2. Conversion process from source code to Android application

The Java source files are converted to Java class files by the Java compiler. The Android SDK contains a tool called dx which converts Java class files into a .dex (Dalvik Executable) file. All class files of the application are placed in this .dex file. During this conversion process redundant information in the class files are optimized in the .dex file. For example, if the same String is found in different class files, the .dex file contains only one reference of this String .

These .dex files are therefore much smaller in size than the corresponding class files.

The .dex file and other resources, e.g., the images and XML files, are packed into an .apk (Android Package) file. The program aapt (Android Asset Packaging Tool) performs this step.

The resulting .apk file contains all necessary data to run the Android application and can be deployed to an Android device via the adb tool.

As of Android 5.0 the Android RunTime (ART) is used as runtime for all Android applications. ART uses a combination of Ahead Of Time and _Just In Time _ compilation. During the installation of an application on an Android device, the application code is translated into machine code.

The dex2oat tool takes the .dex file created by the Android tool chain and compiles that into an Executable and Linkable Format (ELF file). This file contains the dex code, compiled native code and meta-data. Keeping the .dex code allows that existing tools still work.

1.3. Using Gradle on the command line

The Gradle build system is designed to support complex scenarios in creating Android applications:

Multi-distribution: the same application must be customized for several clients or companies

Multi-apk: supporting the creation of multiple apk for different device types while reusing parts of the code

You can start your Gradle build via the command line. Here is an overview of the important Android Gradle tasks:

Table 1. Android Gradle build targets

build project, runs both the assemble and check task

./gradlew clean build

build project complete from scratch

./gradlew clean build

build project complete from scratch

Run the instrumentation tests

To see all available tasks, use the gradlew wrapper command.

This command creates in the build folder the output of the Gradle build. By default, the Gradle build creates two .apk files in the build/outputs/apk folder.

To build and start your unit tests on the JVM use the following command.

To build and start your instrumented tests on your Android device use the following command.

1.4. Removing unused resources and Java classes via resource shrinking

The Gradle build system for Android supports resource shrinking at build time. This automatically removes resources that are unused from the packaged application. In addition to that, this also removes unnecessary resources from libraries you are depending on. This can hugely reduce the size of your application.

To enable resource shrinking, update your build file similar to the following snippet.

1.5. Defining dependencies and keeping the version external

A good practice is to define the version of your library dependencies outside the dependencies closure for better maintenance.

Command Description
If you put the ext closure into the root build file, you can access its properties for example with ‘$rootProject.ext.junitVersion’.

2. Building Android applications with Maven

The android-maven-plugin plug-in allows to build Android applications via Maven.

The webpage of this maven plug-in is located under: http://code.google.com/p/maven-android-plugin/ — Android-Maven Plug-in.

The Eclipse support of this plug-in is provided by the https://github.com/rgladwell/m2e-android — m2e project.

You only have to install Maven, write a correct pom.xml file and issue the commands to Maven to build, install and run your application.

The following will build your Android application via Maven.

This will create the application and places the .apk file in the target_ folder.

If you want to install the application via Maven on your Android device, you can use the following command.

If more than one device is available you can specify the relevant device in your pom.xml. Maven can also start and stop an Android virtual device automatically for you.

You can also start the application via Maven.

3. Tutorial: Building Android Applications with Maven

Create a new Android project called «de.vogella.android.build.firstmaven». The actual content of the repository is not important as we are only using this project to create a working build for Maven.

Create the following «pom.xml» file in your directory. Make sure that artifactId is set to your project name.

Switch to the command line and enter the following command:

4. More information

For more information see the complete Maven Android Guide from Sonatype:

Another quick starting guide is available on the android-maven-plugin project side:

Источник

Публикация Android библиотеки

Недавно у меня появилось желание попробовать создать свою собственную Android библиотеку и выложить ее на Maven Central репозиторий.

Это оказалось не так просто, как я думал. В интернете полно непонятных статей на эту тему, в которых легко запутаться.

Я решил поделиться процессом публикации моей библиотеки Awesome-Buttons.

Ну что ж, приступим.

Регистрация на Sonatype JIRA и создание Issue

Перейдите на сайт Sonatype JIRA и создайте себе аккаунт.

Теперь войдите в аккаунт и создайте новый Issue :

Заполните всю необходимую информацию.

Обратите внимание на Group Id . Обычно в качестве его указывается доменное имя в обратном порядке.

Если у вас есть свой сайт или сайт библиотеки, то вы можете использовать его доменное имя (например: ru.freeit256 ), но для этого нужно будет дополнительно прописать запись в вашем регистраторе домена (после создания Issue вы увидите информацию как это сделать).

Я использовал другой подход: указал свой Github в качестве Group Id

Также для того, чтобы использовать Github в качестве Group Id вам нужно создать пустой репозиторий с именем OSSRH-74088

Не забудьте отправить ваше Issue на проверку и дождаться статуса CLOSED

Создаем Android библиотеку в Android Studio

Сначала создайте любое пустое приложение с app модулем.

Затем вы можете либо добавить модуль Android библиотеки, либо изменить текущий модуль на библиотечный. Читайте об этом на официальном сайте

Генерации GPG ключа

Перед публикацией необходимо сгенерировать пару GPG ключей.

Для генерации ключей выполните следующую команду:

Основные параметры при создании ключей:

формат шифрования: RSA and RSA

размер: 4096 бит

срок годности ключа можно указать 0 (никогда не истечет)

имя, email и комментарий укажите свои

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

Обратите внимание, последние 8 символов это ID ключа:

Для подписи библиотеки мы будем использовать приватный ключ, а чтобы пользователи смогли удостовериться, что библиотека принадлежит нам, мы должны выложить публичный ключ на общедоступный сервер, например keyserver.ubuntu.com:

Чтобы получить приватный ключ для подписи нужно выполнить:

Вуаля! Позже он нам понадобится.

Настройка библиотеки для публикации:

Добавляем плагин io.github.gradle-nexus в корневой файл build.gradle :

Далее нам нужно создать два скрипта для модуля и корня нашей библиотеки.

Создадим в корне проекта папку scripts , и добавим новый скрипт publish-module.gradle :

Также нам нужно добавить скрипт publish-root.gradle :

Теперь нам нужно добавить maven-publish плагин и некоторые константы в начало build.gradle файла нашего модуля:

И самый важный момент, файл local.properties :

Публикация

После основных настроек, зайдите на Nexus Repository Manager и войдите под учетными данными JIRA Sonatype.

Далее переходим во вкладку Staging Profiles и выбираем необходимый профиль.

Копируем sonatypeStagingProfileId из адреса сайта и указываем его в local.properties файле:

Переходим к публикации.

Далее у вас есть два варианта зарелизить либу: вручную через графический интерфейс или с помощью gradle задачи.

Первый

Зайдите на сайт Nexus Repository Manager , перейдите во вкладку Staging Repositories и выберите необходимый репозиторий.

Чтобы выпустить релиз библиотеки нужно воспользоваться двумя командами close и release .

Для отмены релиза юзайте drop

Второй

Выполните команду, которая сама закроет и зарелизит вашу либу:

Заключение

Вы уже убедились, что процесс публикации Andorid либы весьма затратный и рутинный.

Я постарался изложить только основные моменты. Возможно у вас возникнут какие-либо ошибки, которые вам придется самим решать ну и конечно же гуглить!

Такова жизнь прогера: постоянно гуглить. 🙂

Надеюсь, что статья оказалась вам полезной.

Желаю всем хорошего кода и побольше успешных релизов! 🙂

Источник

Советы по работе с Gradle для Android-разработчиков

Всем привет! Я пишу приложения под Android, в мире которого система сборки Gradle является стандартом де-факто. Я решил поделиться некоторыми советами по работе с системой с теми, у кого нет чёткого понимания, как правильно структурировать свои проекты и писать build-скрипты.

Часто разработчики используют Gradle по наитию и не изучают целенаправленно, потому что не всегда хватает ресурсов на инфраструктурные задачи. А если возникают какие-либо проблемы, то просто копируют готовые куски build-скриптов из ответов на Stack Overflow. Во многом проблема кроется в сложности и чрезмерной гибкости Gradle, а также в отсутствии описания лучших практик в официальной документации.

Поработав больше пяти лет на аутсорсе, я видел много проектов разной сложности. И на всех этих проектах build-скрипты писались по-разному, где-то встречались не очень удачные решения. Я провел небольшую ретроспективу и резюмировал свой опыт в виде разных советов по использованию Gradle и рассказал их на одном из наших внутренних митапов. В статье я перевел эти советы в текст.

Небольшой оффтоп для тех, кому совсем ничего не понятно в Gradle-скриптах

Я заметил, что в Android-сообществе встречаются люди, которые могут годами разрабатывать приложения, но при этом не понимать, как работает Gradle. И достаточно продолжительное время и я был одним из них. Но однажды всё же решил, что гораздо проще потратить время на системное изучение Gradle, чем постоянно натыкаться на непонятные проблемы.

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

#1 Не редактируйте Gradle-скрипты через IDE

Android studio умеет генерировать стартовый проект с базовой структурой и готовыми build-скриптами, а также удалять и добавлять модули в существующем проекте. А при редактировании Gradle-скриптов IDE нам заботливо подсказывает, что можно вносить изменения в скрипты через графический интерфейс в меню «File -> Project structure. «. И в начале своей карьеры я вполне успешно пользовался этим инструментом. Но у него есть существенный недостаток: IDE не запускает честную фазу конфигурации Gradle и не смотрит на то, что формируется в памяти при сборке, а всего лишь пытается как-то парсить build-скрипты. Зачастую этот инструмент не распознает то, что было написано вручную, что, на мой взгляд, перечеркивает его пользу.

Мой совет: лучше не редактировать скрипты через IDE, а использовать редактор кода.

#2 Обращайте внимание на соглашение по именованию модулей

В Gradle имя проекта (модуля) берется из соответствующего поля name в объекте Project или названия директории, в которой он лежит. В своей практике я видел разные стили именования модулей, например, в camel- или snake- кейсе: MyAwesomeModule , my_awesome_module . Но есть ли какие-то устоявшиеся соглашения об именах модулей? Кажется, официальная документация Gradle ничего нам об этом не говорит. Но нужно принять во внимание тот факт, что проекты Gradle при публикации в Maven будут соответствовать один к одному модулям Maven. И у Maven есть соглашение, что слова в названиях модулей должны разделяться через символ — . То есть правильнее будет такое название модуля: my-awesome-module .

#3 Что выбрать: Kotlin vs Groovy

Изначально в Gradle для DSL использовался язык Groovy, но впоследствии была добавлена возможность писать build-скрипты на Kotlin. Возникает вопрос: что же сейчас использовать? И однозначного ответа на него пока что нет.

Лично я за использование Kotlin, так как не очень хочу только лишь ради build-системы изучать ещё один язык — Groovy. Наверно, для всего Android сообщества DSL на Kotlin существенно понижает порог вхождения в Gradle. Кроме того, у build-скриптов на Kotlin лучше поддержка в IDE с автокомплитом, но, тем не менее, она все еще далека от идеала.

В качестве минуса Kotlin я бы выделил то, что могут встретиться какие-то старые плагины, которые изначально были заточены только под Groovy, и для их подключения придется потратить больше времени.

Если у вас старый большой проект с build-скриптами на Groovy, то могу посоветовать частично попробовать какие-то скрипты перевести на Kotlin, если вам понравится, то можно будет постепенно делать рефакторинг и переписывать все скрипты на Kotlin, не обязательно делать это единовременно.

#4 Как прописывать зависимости в многомодульных проектах

Возьмем небольшой пример проекта со следующей структурой:

Основной модуль, из которого собирается apk, зависит от feature-модулей, а также в нём прописаны какие-то внешние зависимости. feature-модули, в свою очередь, содержат транзитивные зависимости, которые могут пересекаться с зависимостями в других модулях.

В чем проблема такого проекта? Здесь будет тяжело глобально обновлять зависимости в каждом из файлов. Очень легко забыть поднять версию в одном из скриптов, и тогда возникнут конфликты. По умолчанию Gradle умеет разрешать такие конфликты, выбирая максимальную версию, так что, скорее всего, сборка будет успешной (поведение можно менять через resolution strategy).

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

Java platform plugin

Разработчики Gradle предлагают для описания зависимостей создать отдельный специальный модуль, где будут описаны только зависимости с конкретными версиями. К этому модулю надо применить java platform plugin. Далее подключаем этот модуль в остальные модули и при указании каких-то внешних зависимостей не пишем конкретную версию:

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

Перейду к общепринятым в сообществе способам описания зависимостей.

Описание зависимостей в extra properties

Достаточно часто можно увидеть практику, когда строки с зависимостями хранят в extra properties корневого проекта, по сути это словарь, доступный всем дочерним модулям. Пример использования можно встретить в некоторых библиотеках от Google.

В корневом проекте описываем зависимости. Вот кусок build-скрипта из библиотеки Google, где зависимость возвращается функцией compatibility :

И обращаемся к ним из дочерних модулей:

Описание зависимостей в скриптовом плагине

Описанный способ с extra properties можно немного модифицировать и вынести описание зависимостей в скриптовый плагин, чтобы не засорять корневой проект. А уже скриптовый плагин можно применить или к корневому, или ко всем дочерним проектам сразу (через allprojects <> ), или к отдельным. Такой способ я тоже встречал.

Описание зависимостей в buildSrc

В buildSrc можно писать любой код, который будет компилироваться и добавляться в classpath build-скриптов. В последнее время стало популярно использовать buildSrc для описания там зависимостей. Например, в библиотеке Insetter Chris Banes так и делает.

Все, что нужно, — это добавить синглтон со строками в buildSrc, и он станет виден всем модулям в проекте:

Использовать buildSrc для зависимостей очень удобно, так как будут статические проверки и автокомплит в IDE:

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

Композитные сборки

Можно достичь похожего результата со статическими проверками и автокомплитом, используя композитные сборки, при этом избавившись от проблемы инвалидации всего кэша. Я расскажу про него лишь кратко, а подробный гайд по миграции с buildSrc можно прочитать в статье из блога Badoo или статье от Josef Raska.

В композитных сборках мы создаем так называемые «включенные сборки» (included build), в которых можно писать плагины и подключать их в своих модулях. Включенные сборки описываются в файле settings.gradle .

Если мы хотим всего лишь подсунуть в classpath build-скриптов строки с зависимостями, то достаточно создать пустой плагин, а рядом с ним положить тот же файл с зависимостями, который мы использовали раньше в buildSrc:

Все, что осталось сделать, — применить плагин к корневому проекту:

И мы получим практически тот же результат, как и с использованием buildSrc.

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

#5 Как обновлять зависимости

В любом активном проекте надо постоянно следить за обновлением библиотек. IDE умеет подсвечивать для каждого модуля, описанного в блоке dependencies <> , наличие новых стабильных версий в репозиториях:

Но этот инструмент работает только для зависимостей, описанных строковыми литералами в build-скриптах, а если мы попытаемся использовать способ с композитными сборками, buildSrc или extra properties, то IDE перестанет нам помогать. Кроме того, визуально просматривать build-скрипты в модулях, для того чтобы сделать обновление библиотек, на мой взгляд, не очень удобно.

Но есть решение — использовать gradle-versions-plugin. Для этого просто применяем плагин к корневому проекту и регистрируем task для проверки новых версий зависимостей. Этот task надо настроить, передав ему лямбду для определения нестабильных версий:

Теперь запуск команды ./gradlew dependencyUpdates выведет список зависимостей, для которых есть новые версии:

#6 Старайтесь не использовать feature-флаги в build config

Во многих проектах release, debug и другие сборки отличаются по функциональности. Например, в отладочных сборках могут быть включены какие-то логи, мониторинг сетевого трафика через прокси, debug menu для смены окружений и т.д. И часто для реализации такого используют флаги, прописанные в build config, например:

А дальше такие флаги используются в коде приложения:

И у такого решения есть недостатки. Довольно легко перепутать значения флагов и ветки if/else: if (enabled) <> else <> или if (disabled) <> else <> . Именно так однажды, во время рефакторинга, я случайно отправил в релиз то, что должно было включаться только в сборках для QA-отдела (думаю, у многих были похожие истории). Тогда проблему обнаружили оперативно, мы перевыпустили сборку в маркет. Кроме того, недостижимый код может быть скомпилирован и попасть в релиз (здесь я не буду рассуждать о том, что «мертвый» код может вырезаться из итогового приложения). Ну и многим известно, что любые операторы ветвления лучше заменять полиморфизмом. И в Gradle есть статический полиморфизм.

Вместо флагов можно использовать разные source set для различных build variant («src/release/java . «, «src/debug/java . «). А если такой код хочется вынести в отдельные модули, то можно использовать специальные конфигурации: debugImplementation , releaseImplementation и т.д. Тогда мы сможем написать код с одним и тем же интерфейсом, но разной реализацией для различных типов сборок.

Например, мы можем выделить debug menu в отдельный модуль и подключать его только для debug и QA-сборок:

А stub реализацию для релизной сборки можно реализовать через source set.

#7 Несколько слов про базовую структуру проекта

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

Если для крупных проектов модуляризация кажется вполне очевидным решением, то не совсем понятно, как стоит поступать при старте небольших проектов или когда невозможно предсказать дальнейшее развитие кодовой базы продукта. Нужно ли выделять какие-то модули или достаточно начать с монолита? Я бы, помимо app модуля с основным приложением, всегда выделял как минимум два отдельных модуля:

  • UI kit: стили, кастомные элементы управления, виджеты и т.д. Обычно элементы управления на всех экранах приложения делаются консистентно в одном стиле (а возможно, у вас целая дизайн-система), и если в какой-то момент захочется выделить feature-модуль, то он также будет опираться на единый UI kit. Заранее подготовленный модуль с элементами управления и стилями упростит задачу и не потребует значительного рефакторинга приложения.
  • Common / utils: все утилитные классы и любые решения, которые не только потребуются в нескольких модулях, но и могут даже копироваться из проекта в проект. Особенно в контексте аутсорса такой модуль будет удобным при старте новых проектов. При вынесении классов в отдельный модуль, а не пакет, можно быть уверенным, что в его коде не окажется каких-либо бизнес сущностей конкретного приложения. Потенциально такой модуль может стать полноценной библиотекой, опубликованной в репозиторий.

#8 Не забывайте про matchingFallbacks

Часто, помимо debug и release , мы создаем и другие типы сборок, например, qa для тестов. И при создании модулей в приложении необязательно их прописывать в каждом build-скрипте. Достаточно при создании своего build type указать в модуле основного приложения те build type, которые следует выбирать при отсутствии каких-то конкретных:

#9 Убирайте ненужные build variant

Build variant формируются из всех возможных сочетаний product flavor и build type. Возьмем небольшой синтетический пример: создадим три build type – debug (отладочная сборка), release (сборка в маркет) и qa (сборка для тестирования), а во flavor вынесем разные сервера, на которые может смотреть сборка, – production и staging (тестовое окружение). Возможные build variant будут выглядеть так:

Очевидно, что сборка в маркет, которая будет смотреть на тестовое окружение, совершенно бессмысленна и не нужна ( stagingRelease ). И чтобы исключить ее, можно добавить variant filter:

#10 В некоторых модулях, завязанных на Android Framework, можно не использовать Android Gradle Plugin

Если какой-то из ваших модулей завязан на классы из Android Framework, то вовсе не обязательно сразу применять к нему Android Gradle Plugin и писать там файл манифеста. Модули с AGP — более тяжеловесные, чем чистые java/kotlin модули, так как при сборке будут объединяться манифесты, ресурсы и т.д. Когда вам всего лишь требуется для компиляции модуля что-то вроде классов Activity , Context и т.д., то можно просто добавить Android Framework как зависимость:

#11 Как написать Gradle-плагин для CI на примере gitlab

Настройка CI — отдельная большая тема, которая потянет на целую увесистую статью. Но я решил немного коснуться её и рассказать, как при помощи написания Gradle-плагина настроить версионирование сборок. Возможно, этот совет поможет тем, кто только поднимает CI, но не знает, как лучше это сделать.

Задача — сделать так, чтобы в сборках на CI versionCode ставился автоматически и представлял из себя последовательные номера 1, 2, 3 и т.д. Я встречал в своей практике, когда в качестве versionCode брался CI job id или каким-то образом использовался timestamp. В таких случаях versionCode с каждой новой версией повышался и был уникальным, но семантически такие версии выглядели достаточно странно.

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

В случае использования Gitlab CI подставляемый versionCode можно хранить в переменной окружения Gitlab. В его API есть метод для обновления переменных окружения: PUT /projects/:id/variables/:key . Для авторизации используем или project access token, или personal access token для старых версий gitlab.

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

Шаг 1: в настройках проекта на gitlab создать переменные окружения

Нам понадобятся переменные VERSION_CODE_NEXT для хранения номера версии и токен для доступа к API gitlab:

Шаг 2: создать композитную сборку

Добавим в корне проекта директорию ./includedBuilds/ci , а в ней файл build.gradle.kts :

Рядом создадим пустой файл ./includedBuilds/ci/settings.gradle.kts , если этого не сделать, то у вас сломается clean проекта.

В корневом проекте в файл settings.gradle.kts добавим строку includeBuild(«includedBuilds/ci») .

Шаг 3: написать плагин

Так будет выглядеть метод для получения versionCode , его можно будет использовать в build-скрипте (можно добавить в любой файл: при применении плагина код будет скомпилирован и добавлен в classpath build-скрипта):

Примерно так можно написать метод для обновления переменной на gitlab:

Далее пишем task, который при выполнении будет инкрементировать версию:

И напишем плагин, который добавит task в проект:

Шаг 4: подключить плагин

В build-скрипте проекта, из которого собирается apk, добавим следующие строки:

Теперь команда ./gradlew assembleRelease appDistributionUploadRelease incrementVersionCode будет делать новую сборку, публиковать ее и инкрементировать версию. Остается добавить эту команду на нужный триггер в ваш скрипт в .gitlab-ci.yml .

В заключение

Думаю, что у многих есть свои best practices по работе с Gradle, которыми вы бы могли поделиться с сообществом. Или что-то описанное в этой статье можно сделать лучше. Так что буду рад увидеть ваши советы в комментариях.

Что ещё посмотреть

Мне очень помогли доклады про работу с Gradle, которые делал Степан Гончаров в разные годы. Ссылки на них, если кому-то интересна эта тема:

Источник

Читайте также:  Как удалить scweather android
Оцените статью