Варианты сборки, задачи Gradle и Kotlin: освоение Gradle для Android

Похоже на то, что Android Studio собирает пакеты и создает ваши приложения с очень небольшим вкладом от вас?

За кулисами Android Studio использует Набор инструментов для автоматической сборки Gradle, и хотя Gradle можно запускать с очень небольшой ручной настройкой (если вообще есть), Gradle может предложить гораздо больше, чем то, что доступно из коробки!

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

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

Итак, что же такое Gradle?

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

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

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

Как работает Gradle?

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

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

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

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

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

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

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

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

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 на уровне проекта, то по-прежнему можно переопределить или расширить эти задачи для отдельных модулей, отредактировав их соответствующую сборку на уровне модуля . gradle.

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

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

Этот проект -уровневая сборка. Файл 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 на уровне модуля обычно выглядит примерно так:

 apply plugin: 'com.android.application'android {compileSdkVersion 28  defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"} buildTypes {release {minify '  , 'proguard-rules.pro'}}} зависимости {реализация fileTree (dir: 'libs', include: ['* .jar']) реализация 'androidx.appcompat: appcompat: 1.0.2' реализация 'androidx.constraintlayo  ut: constraintlayout: 1.1.3 'testImplementation' junit: junit: 4.12 'androidTestImplementation' androidx.test.ext: junit: 1.1.0 'androidTestImplementation' androidx.test.espresso: espresso-core: 3.1.1 '} 

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

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

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

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

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

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

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

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

 implementation fileTree (dir: '  libs ', включают: [' *. jar ']) 

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

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

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

Подключение к удаленному репозиторию

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

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

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

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

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

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

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

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

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

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

 зависимости {реализация fileTree (dir: 'libs', include: ['* .jar']) реализация '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: espresso-core: 3.1.1 '} 

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

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

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

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

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

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

 android  : label = "$ {appName}" 

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

[ appName: «@ string/app_name_paid»]}}}

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

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

Создание настраиваемой задачи Gradle

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

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

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

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

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

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

Для своего приложения я собираюсь использовать метод whenReady, который гарантирует, что наша задача будет вызываться после заполнения DAG, и 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 должна выглядеть примерно так :

• Нажмите клавишу «Enter» на клавиатуре. Теперь Gradle соберет ваш проект.

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

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

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

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

 ./gradlew -q tasks 

• Нажмите клавишу «Enter» на клавиатуре.

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

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

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

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

 apply plugin: 'java' 

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

Gradle Kotlin DSL

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

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

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

Заключение

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

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