Освоение Gradle для Android: задачи Gradle и Kotlin

Видео: Как использовать Gradle.kts в Android [Ru, Android, Kotlin] / Мобильный разработчик

Содержание

Изучение файлов сборки Gradle
1. settings.gradle
2. build.gradle (уровень проекта)
3. build.gradle (уровень модуля)
Объявление зависимостей вашего проекта: Локальные библиотеки
Добавление зависимости сборки: удаленные репозитории
Подключение к удаленному хранилищу
Объявление удаленной зависимости
Создание нескольких APK: как создавать варианты сборки
Создание пользовательской задачи Gradle
Создание вашего проекта с помощью обёртки Gradle
Какие другие задачи Gradle доступны?
Получите больше от Gradle: добавление плагинов
Gradle Kotlin DSL
Завершение

Вместо Java, XML или Kotlin эти файлы сборки Gradle используют основанный на Groovy доменный язык (DSL). Если вы не знакомы с Groovy, мы построчно рассмотрим каждый из этих файлов сборки Gradle, поэтому к концу этой статьи вам будет удобно читать и писать простой код на Groovy.

Gradle стремится сделать вашу жизнь проще, предоставляя набор настроек по умолчанию, которые вы часто можете использовать с минимальной ручной настройкой - когда вы будете готовы построить свой проект, просто нажмите кнопку «Выполнить» в Android Studio, и Gradle начнет процесс сборки для тебя.

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

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

Изучение файлов сборки Gradle

Каждый раз, когда вы создаете проект, Android Studio будет генерировать одну и ту же коллекцию файлов сборки Gradle. Даже если вы импортируете существующий проект в Android Studio, он все равно Все еще создайте точно такие же файлы Gradle и добавьте их в свой проект.

Чтобы лучше понять Gradle и синтаксис Groovy, давайте построчно рассмотрим каждый из файлов сборки Gradle для Android.

1. settings.gradle

В файле settings.gradle вы определяете все модули вашего приложения по имени, используя ключевое слово «include». Например, если у вас есть проект, состоящий из «app» и «secondModule», то ваш файл settings.gradle будет выглядеть примерно так:

include: app,: secondmodule rootProject.name = MyProject

В зависимости от размера вашего проекта этот файл может быть значительно длиннее.

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

2. build.gradle (уровень проекта)

Файл build.gradle уровня проекта находится в корневом каталоге вашего проекта и содержит параметры, которые будут применены к все ваши модули (также называемые «проектами» Gradle).

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

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

buildscript {repositories {google () jcenter ()} зависимости {classpath com.android.tools.build:gradle:3.5.0-alpha06 // ПРИМЕЧАНИЕ. Не размещайте здесь зависимости приложений; // они принадлежат отдельным файлам build.gradle модуля}} allprojects {repositories {google () jcenter ()}} задача clean (тип: Delete) {delete rootProject.buildDir}

Этот файл build.gradle уровня проекта разделен на следующие блоки:

Buildscript. Он содержит настройки, необходимые для выполнения сборки.
Хранилища. Gradle отвечает за определение зависимостей вашего проекта и предоставление их в вашей сборке. Однако не все зависимости происходят из одного и того же репозитория, поэтому вам нужно определить все репозитории, которые Gradle должен искать, чтобы получить зависимости вашего проекта.
Зависимости. Этот раздел содержит зависимости вашего плагина, которые загружаются и хранятся в вашем локальном кэше. Вам следует не определить любые зависимости модуля в этом блоке.
Allprojects. Здесь вы будете определять репозитории, которые должны быть доступны для все модулей вашего проекта.

3. build.gradle (уровень модуля)

Это файл build.gradle уровня модуля, который присутствует в каждом модуле вашего проекта. Если ваш проект Android состоит из нескольких модулей, он также будет состоять из нескольких файлов build.gradle уровня модуля.

Каждый файл build.gradle уровня модуля содержит имя пакета вашего проекта, имя версии и код версии, а также минимальный и целевой SDK для этого конкретного модуля.

Файл build.gradle уровня модуля также может иметь собственный уникальный набор инструкций и зависимостей сборки. Например, если вы создаете приложение с компонентом Wear OS, тогда ваш проект Android Studio будет состоять из отдельного модуля для смартфона / планшета и модуля Wear - поскольку они предназначены для совершенно разных устройств, эти модули имеют совершенно разные зависимости!

Базовый файл build.gradle уровня модуля обычно будет выглядеть примерно так:

применить плагин: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner_TyNableFoundSigned {ложь) getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} зависимости {реализация fileTree (dir: libs, include:) реализация androidx.appcompat: appcompat: 1.0.2 реализация androidx.constraintlayout: constraintlayout: 1.1. 3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: эспрессо-ядро: 3.1.1}

Давайте подробнее рассмотрим каждый из этих разделов:

применить плагин. Это список плагинов, необходимых для сборки этого модуля. Плагин com.android.application необходим для настройки специфичного для Android процесса сборки, поэтому он добавляется автоматически.
андроид. Здесь вы должны разместить все специфичные для платформы опции модуля.
compileSdkVersion. Это уровень API, с которым скомпилирован этот модуль. Вы не можете использовать функции из API выше, чем это значение.
buildToolsVersion. Это указывает на версию компилятора. В Gradle 3.0.0 и выше buildToolsVersion является необязательным; если вы не укажете значение buildToolsVersion, Android Studio по умолчанию будет использовать самую последнюю версию инструментов сборки.
defaultConfig. Он содержит параметры, которые будут применяться ко всем версиям сборки вашего приложения, таким как отладочная и выпускная сборки.
ApplicationID. Это уникальный идентификатор вашего приложения.
minSdkVersion. Этот параметр определяет самый низкий уровень API, который поддерживает этот модуль.
targetSdkVersion. Это максимальный уровень API, на котором было протестировано ваше приложение. В идеале вам следует протестировать ваше приложение с использованием новейшего API, что означает, что значение targetSdkVersion всегда будет равно значению compileSdkVersion.
VersionCode. Это числовое значение для версии вашего приложения.
versionName. Это удобная строка, представляющая версию вашего приложения.
buildTypes. По умолчанию Android поддерживает два типа сборки: отладка и выпуск. Вы можете использовать блоки «debug» и «release» для указания настроек вашего приложения.
зависимостей. Здесь вы определите все библиотеки, от которых зависит этот модуль.

Объявление зависимостей вашего проекта: Локальные библиотеки

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

Чтобы объявить зависимость от локального файла JAR, вам нужно добавить этот JAR в каталог libs вашего проекта.

Затем вы можете изменить файл build.gradle уровня модуля, чтобы объявить зависимость от этого файла. Например, здесь мы объявляем зависимость от «mylibrary» JAR.

файлы реализации (libs / mylibrary.jar)

В качестве альтернативы, если ваша папка «libs» содержала несколько JAR-файлов, было бы проще просто указать, что ваш проект зависит от всех файлов, находящихся в папке «libs», например:

реализация fileTree (dir: libs, include:)

Добавление зависимости сборки: удаленные репозитории

Если библиотека находится в удаленном хранилище, вам необходимо выполнить следующие шаги:

Определите хранилище, в котором находится эта зависимость.
Объявите индивидуальную зависимость.

Подключение к удаленному хранилищу

Первый шаг - это сообщить Gradle, какой репозиторий (или репозитории) нужно проверить, чтобы получить все зависимости вашего проекта. Например:

репозитории {google () jcenter ()}}

Здесь строка «jcenter ()» гарантирует, что Gradle проверит репозиторий JCenter, который является бесплатным общедоступным репозиторием, размещенным в bintray.

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

repositories {mavenCentral () maven {// Настройка целевого URL // url "http://repo.mycompany.com/myprivaterepo"} maven {credentials {имя пользователя myUsername пароль myPassword} url "http://repo.mycompany.com / myprivaterepo "}

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

Объявление удаленной зависимости

Следующим шагом является объявление зависимости в файле build.gradle уровня модуля. Вы добавляете эту информацию в блок «зависимости», используя любое из следующего:

Реализация. Это нормальная зависимость, которая вам нужна при создании проекта. Зависимость «реализации» будет присутствовать через все ваши сборки.
Testimplementation. Это зависимость, необходимая для компиляции исходного кода вашего приложения и запуска тестов на основе JVM. Когда вы помечаете зависимость как «Testimplementation», Gradle будет знать, что ему не нужно запускать задачи для этой зависимости во время обычной сборки, что может помочь сократить время сборки.
Androidtestimplementation. Это зависимость, которая требуется при запуске тестов на устройстве, например, платформа Espresso является распространенной «Androidtestimplementation».

Мы определяем удаленную зависимость, используя одно из указанных выше ключевых слов, а затем атрибуты группы, имени и версии зависимости, например:

зависимости {реализация fileTree (dir: libs, include:) реализация androidx.appcompat: appcompat: 1.0.2 реализация androidx.constraintlayout: constraintlayout: 1.1.3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: эспрессо-ядро: 3.1.1}

Создание нескольких APK: как создавать варианты сборки

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

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

Откройте файл strings.xml и удалите исходную строку имени приложения.
Затем определите названия каждого продукта, который вы хотите создать; в этом случае я использую:

Мое бесплатное приложение Мое платное приложение

Откройте файл AndroidManifest.xml и замените android: label = ”@ string / app_name” на:

Android: метка = "$ {APPNAME}"

Откройте файл build.gradle уровня модуля и добавьте в блок «android» следующее:

flavourDimensions "mode" productFlavors {free {измерение "mode" applicationIdSuffix ".free" manifestPlaceholders =} paid {измерение "mode" applicationIdSuffix ".paid" manifestPlaceholder =}}}

Давайте разберемся, что здесь происходит:

flavorDimensions. Плагин Android создает варианты сборки, комбинируя различные варианты. Здесь мы создаем измерение вкуса, состоящее из «бесплатной» и «платной» версий нашего приложения. На основе приведенного выше кода Gradle создаст четыре варианта сборки: paidDebug, paidRelease, freeDebug и freeRelease.
productFlavors. Здесь указывается список разновидностей и их настроек, которые в приведенном выше коде являются «платными» и «бесплатными».
Бесплатно / платно. Это названия наших двух продуктов.
Dimension. Нам нужно указать значение параметра «измерение»; в этом случае я использую «режим».
applicationIdSuffix. Поскольку мы хотим создать несколько версий нашего приложения, нам нужно дать каждому APK уникальный идентификатор приложения.
manifestPlaceholders. Каждый проект имеет отдельный файл манифеста, содержащий важную информацию о конфигурации вашего проекта. При создании нескольких вариантов сборки вы, как правило, захотите изменить некоторые из этих свойств Manifest во время сборки. Вы можете использовать файлы сборки Gradle, чтобы указать уникальные записи манифеста для каждого варианта сборки, которые затем будут вставлены в ваш манифест во время сборки. В приведенном выше коде мы изменяем значение «appName» в зависимости от того, собирает ли Gradle бесплатную или платную версию нашего приложения.

Создание пользовательской задачи Gradle

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

Задача - это именованная коллекция действий, которые Gradle будет выполнять при сборке, например, при создании Javadoc. Gradle поддерживает множество задач по умолчанию, но вы также можете создавать собственные задачи, которые могут пригодиться, если у вас есть очень специфический набор инструкций по сборке.

В этом разделе мы создадим пользовательскую задачу Gradle, которая будет перебирать все варианты сборки нашего проекта (paidDebug, paidRelease, freeDebug и freeRelease), создавать отметку даты и времени, а затем добавлять эту информацию к каждому сгенерированному APK.

Откройте файл build.gradle уровня модуля и добавьте следующее:

task addDateAndTime () {// Итерация по всем вариантам сборки вывода // android.applicationVariants.all {option -> // Итерация по всем файлам APK // variable.outputs.all {output -> // Создание экземпляра текущие дата и время в указанном формате // def dateAndTime = new Date (). format ("yyyy-MM-dd: HH-mm") // Добавить эту информацию к имени файла APK // def fileName = варианту. name + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

Далее нам нужно сказать Gradle когда он должен выполнить эту задачу. Во время сборки Gradle идентифицирует все, что ему нужно для загрузки, и все задачи, которые он должен выполнить, и упорядочивает их в направленном ациклическом графе (DAG). Затем Gradle выполнит все эти задачи в соответствии с порядком, определенным в его группе DAG.

Для моего приложения я собираюсь использовать метод whenReady, который гарантирует, что наша задача будет вызвана после заполнения группы доступности базы данных, и Gradle будет готова приступить к выполнению своих задач.

Добавьте следующее в файл build.gradle уровня модуля:

// Выполнить эту задачу // gradle.taskGraph.whenReady {addDateAndTime}

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

Создание вашего проекта с помощью обёртки Gradle

Команды Gradle вы используете с помощью оболочки Gradle («gradlew»). Этот сценарий является предпочтительным способом запуска сборки Gradle, поскольку он делает выполнение сборки независимым от вашей версии Gradle. Это разделение может быть полезно, если вы сотрудничаете с другими людьми, у которых не обязательно установлена одна и та же версия Gradle.

При вводе команд оболочки Gradle вы будете использовать «gradlew» для Unix-подобных операционных систем, включая macOS, и «gradlew.bat» для Windows. У меня есть Mac, поэтому я буду использовать команды «gradlew».

Вы можете выполнять команды Gradle из Android Studio:

На панели инструментов Android Studio выберите «Вид> Инструменты Windows> Терминал». Откроется панель «Терминал» в нижней части окна IDE.
Введите в терминал следующую команду:

./gradlew build

Android Studio должна выглядеть примерно так:

Нажмите клавишу «Ввод» на клавиатуре. Gradle теперь создаст ваш проект.

Gradle хранит все сгенерированные APK в каталоге вашего проекта app / build / output / apk, поэтому перейдите в этот каталог. Папка «APK» должна содержать несколько папок и подпапок; убедитесь, что Gradle сгенерировал APK для каждого из ваших вариантов сборки, и что правильная информация о дате и времени была добавлена в каждый файл.

Какие другие задачи Gradle доступны?

В дополнение к любым настраиваемым задачам, которые вы можете создать, Gradle поддерживает список предопределенных задач из коробки. Если вам интересно узнать, какие именно задачи доступны, то:

Откройте окно терминала Android Studio, если оно еще не открыто (выбрав «Вид> Инструменты Windows> Терминал» на панели инструментов Android Studio).
Введите следующее в Терминал:

./gradlew -q задачи

Нажмите клавишу «Ввод» на клавиатуре.

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

Получите больше от Gradle: добавление плагинов

Gradle поставляется с несколькими предварительно установленными плагинами, но вы можете расширить Gradle, добавив новые плагины. Эти плагины делают новые задачи доступными для ваших проектов Android, например, плагин Java включает в себя задачи, которые позволяют вам скомпилировать исходный код Java, выполнить модульные тесты и создать файл JAR, такой как «compileJava», «compileText», «jar» «Javadoc» и «чистый».

Чтобы применить плагин, добавьте объявление «apply plugin» в файл build.gradle уровня модуля, а затем его имя. Например, здесь мы применяем плагин Java:

применить плагин: Java

Если вам интересно посмотреть, какие плагины доступны, то воспользуйтесь поиском плагинов Gradle, который предоставляет полный реестр плагинов Gradle.

Gradle Kotlin DSL

По умолчанию вы будете писать свои скрипты сборки Gradle, используя Groovy DSL, но если вы один из многих разработчиков, которые приняли Kotlin для разработки под Android, вы можете вместо этого написать свои скрипты сборки на Kotlin.

В отличие от Groovy, Kotlin - это язык программирования со статической типизацией, поэтому если вы сделаете это, то ваши файлы сборки будут совместимы с функциями автозаполнения и навигации по исходному коду в Android Studio. Кроме того, переход с Groovy на Kotlin означает, что вы будете использовать один и тот же язык программирования в своем проекте, что может сделать разработку более простой, особенно если вы не слишком знакомы с Groovy!

Если вы хотите начать писать логику сборки на Kotlin, вам нужно будет настроить Gradle Kotlin DSL и следовать инструкциям в руководстве по миграции.

Завершение

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

Вы расширили Gradle для автоматизации других частей процесса сборки Android? Дайте нам знать в комментариях ниже!