Освоєння Gradle для Android: завдання Gradle та Kotlin

Зміст

Вивчення файлів збірки Gradle
1. settings.gradle
2. build.gradle (рівень проекту)
3. build.gradle (рівень модуля)
Декларація залежностей вашого проекту: Місцеві бібліотеки
Додавання залежності збірки: Віддалені сховища
Підключення до віддаленого сховища
Оголошення віддаленої залежності
Генерування декількох APK: як створити варіанти збірки
Створення користувацького завдання Gradle
Створення вашого проекту за допомогою обгортки Gradle
Які ще завдання Gradle доступні?
Вихід із Gradle: додавання плагінів
DSL 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 - це те, де ви будете визначати всі модулі вашої програми за назвою, використовуючи ключове слово "включити". Наприклад, якщо у вас був проект, що складається з "програми" та "secondModule", то ваш файл settings.gradle виглядатиме приблизно так:

включають: 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 ()}} завдання очищення (тип: Видалити) {delete rootProject.buildDir}

Цей файл build.gradle на рівні проекту розділений на такі блоки:

Buildscript. Це містить параметри, необхідні для виконання збірки.
Сховища. Gradle відповідає за пошук залежностей вашого проекту та надання їх доступності у вашій збірці. Однак не всі залежності походять з одного сховища, тому вам потрібно буде визначити всі сховища, в яких Gradle повинен шукати, щоб знайти залежності вашого проекту.
Залежності. Цей розділ містить ваші залежності від плагіна, які завантажуються та зберігаються у вашому локальному кеші. Ти повинен ні визначити будь-які залежності модуля в цьому блоці.
Всіпроекти. Тут ви визначаєте сховища, до яких мають бути доступні всі модулів вашого проекту.

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

Це файл build.gradle на рівні модуля, який присутній у кожному модулі у вашому проекті. Якщо ваш проект Android складається з декількох модулів, він також буде складатися з декількох файлів build.gradle на рівні модулів.

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

Файл build.gradle на рівні модуля також може мати власний унікальний набір інструкцій і залежностей щодо збірки. Наприклад, якщо ви створюєте додаток із компонентом ОС Wear, ваш проект Android Studio буде складатися з окремого модуля смартфона / планшета та модуля Wear - оскільки вони націлені на зовсім інші пристрої, ці модулі мають різно різний залежності!

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

застосувати плагін: com.android.application андроїд {compileSdkVersion 28 defaultConfig {ApplicationID "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 VersionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"} buildTypes {{вивільнення minifyEnabled помилкових proguardFiles getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} залежності {file fileTree (dir: libs, include:) реалізація androidx.appcompat: appcompat: 1.0.2 реалізація androidx.constraintlayout: constraintlayout: 1.1. 3 тест-реалізація: липень: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: еспресо-ядро: 3.1.1}

Давайте докладніше розглянемо кожен із цих розділів:

застосувати плагін. Це список плагінів, необхідних для складання цього модуля. Плагін com.android.application необхідний для налаштування специфічного для Android процесу збирання, тому він додається автоматично.
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 підтримує два типи збірки: налагодження та випуск. Ви можете використовувати блоки "налагодження" та "випуск", щоб вказати налаштування вашого типу програми.
залежності. Тут ви визначаєте будь-які бібліотеки, від яких залежить цей модуль.

Декларація залежностей вашого проекту: Місцеві бібліотеки

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

Щоб оголосити залежність від локального файлу JAR, вам потрібно буде додати цей JAR до каталогу "libs" вашого проекту.

Потім ви можете змінити файл build.gradle на рівні модуля, щоб оголосити залежність від цього файлу. Наприклад, тут ми оголосили залежність від "mylibrary" JAR.

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

Крім того, якщо у вашій папці "libs" міститься декілька JAR-файлів, можливо, простіше просто сказати, що ваш проект залежить від усіх файлів, розташованих у папці "libs", наприклад:

file fileTree (dir: libs, include:)

Додавання залежності збірки: Віддалені сховища

Якщо бібліотека розташована у віддаленому сховищі, вам потрібно буде виконати наступні дії:

Визначте сховище, де знаходиться ця залежність.
Заявіть про індивідуальну залежність.

Підключення до віддаленого сховища

Перший крок - сказати Gradle, яке сховище (або сховища) йому потрібно перевірити, щоб відновити всі залежності вашого проекту. Наприклад:

сховища {google () jcenter ()}}

Тут рядок "jcenter ()" гарантує, що Gradle перевірить сховище JCenter, яке є безкоштовним, загальнодоступним сховищем, розміщеним у bintray.

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

сховища {mavenCentral () maven {// Налаштування цільової URL-адреси // url "http://repo.mycompany.com/myprivaterepo"} maven {облікові дані {ім'я користувача myUsername пароль myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Якщо залежність присутня в декількох сховищах, то Gradle вибере "найкращу" версію цієї залежності на основі таких факторів, як вік кожного сховища та статична версія.

Оголошення віддаленої залежності

Наступним кроком є оголошення залежності у вашому файлі build.gradle на рівні модуля. Ви додаєте цю інформацію до блоку "залежності", використовуючи будь-яке з наступного:

Впровадження. Це нормальна залежність, яка вам потрібна щоразу, коли ви будуєте проект. Залежність "впровадження" буде присутня у всіх всі ваші побудови.
Випробування. Це залежність, необхідна для складання джерела тесту вашої програми та проведення тестів на базі JVM. Якщо ви позначите залежність як "Testimplementation", Gradle дізнається, що не потрібно виконувати завдання для цієї залежності під час звичайної збірки, що може допомогти скоротити час збирання.
Android-тестування. Це залежність, необхідна під час запуску тестів на пристрої, наприклад, рамка Espresso - це звичайна "Androidtestimplementation".

Ми визначаємо віддалену залежність, використовуючи одне з перерахованих вище ключових слів, а потім атрибути групи, назва та версію залежності, наприклад:

залежності: {file fileTree (реж .: libs, включають:) реалізація androidx.appcompat: appcompat: 1.0.2 реалізація androidx.constraintlayout: constraintlayout: 1.1.3 testImplication junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Генерування декількох APK: як створити варіанти збірки

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

Це завдання збирання, з яким може допомогти Gradle, тому давайте подивимось, як ви змінили процес збирання, щоб створити декілька APK-файлів з одного проекту:

Відкрийте файл strings.xml та видаліть початковий рядок імені програми.
Далі визначте назви кожного аромату продукту, який ви хочете створити; у цьому випадку я використовую:

Мій безкоштовний додаток Мій платний додаток

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

android: label = "$ {appName}"

Відкрийте файл build.gradle на рівні модуля та додайте до блоку «android» наступне:

colorDimensions "режим" productFlavors {вільний {вимір "режим" applicationIdSuffix ".free" manifestPlaceholders =} виплачений {вимір "режим" applicationIdSuffix ".paid" manifestPlaceholders =}}}

Давайте розберемо, що тут відбувається:

смакові розміри Плагін Android створює варіанти побудови, поєднуючи смаки різних розмірів. Тут ми створюємо смаковий вимір, який складається з "безкоштовної" та "платної" версії нашого додатка. Виходячи з наведеного вище коду, Gradle генерує чотири варіанти складання: paidDebug, paidRelease, freeDebug та freeRelease.
Ароматизатори Тут вказується перелік ароматів та їх налаштування, які у наведеному вище коді є "оплаченими" та "безкоштовними".
Безкоштовно / платно. Це назви наших двох ароматів продуктів.
Вимір. Нам потрібно вказати значення параметра «розмірність»; в цьому випадку я використовую "режим".
applicationIdSuffix. Оскільки ми хочемо створити кілька версій нашого додатка, нам потрібно надати кожному APK унікальний ідентифікатор програми.
маніфестВласники. Кожен проект має один файл Manifest, який містить важливу інформацію про конфігурацію вашого проекту. Створюючи кілька варіантів складання, зазвичай потрібно змінити деякі з цих властивостей Manifest під час створення. Ви можете використовувати файли збірки Gradle, щоб вказати унікальні записи Manifest для кожного варіанту збірки, які потім будуть вставлені у ваш Manifest під час збирання. У наведеному вище коді ми змінюємо значення "appName" залежно від того, будує Gradle безкоштовну чи платну версію нашого додатка.

Створення користувацького завдання Gradle

Іноді може знадобитися налаштувати процес збирання, використовуючи Gradle завдання.

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

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

Відкрийте файл build.gradle на рівні модуля та додайте наступне:

завдання addDateAndTime () {// Ітерація через всі варіанти збірки вихідних файлів // android.applicationVariants.all {variant -> // Ітерація через усі файли APK // variant.outputs.all {output -> // Створення примірника поточну дату та час у вказаному форматі // def dateAndTime = new Date (). формат ("yyyy-MM-dd: HH-mm") // Додайте цю інформацію до імені файлу APK // def fileName = варіант. 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-файли у каталозі додатків / build / output / apk вашого проекту, тому перейдіть до цього каталогу. Папка "APK" повинна містити кілька папок і підпапок; переконайтеся, що Gradle створив APK для кожного з варіантів збірки, а також, щоб до кожного файлу була додана правильна інформація про дату та час.

Які ще завдання Gradle доступні?

На додаток до будь-яких спеціальних завдань, які ви можете створити, Gradle підтримує список попередньо визначених завдань поза вікном. Якщо вам цікаво дізнатися, які саме завдання доступні, тоді:

Відкрийте вікно терміналу Android Studio, якщо воно ще не відкрите (вибравши "Переглянути> Інструменти Windows> Термінал" на панелі інструментів Android Studio).
Введіть у термінал наступне:

./gradlew -q завдання

Натисніть клавішу «Enter» на клавіатурі.

Це завдання "завдання" тепер буде запущено, і через декілька моментів Термінал покаже список усіх завдань, доступних для цього проекту, разом з коротким описом кожного завдання.

Вихід із Gradle: додавання плагінів

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

Щоб застосувати плагін, додайте декларацію «застосувати плагін» до файлу build.gradle на рівні модуля, а потім ім'я плагіна. Наприклад, тут ми застосовуємо плагін Java:

застосувати плагін: java

Якщо вам цікаво дізнатись, які плагіни доступні, перегляньте пошук плагінів Gradle, який забезпечує всебічний реєстр плагінів Gradle.

DSL Gradle Kotlin DSL

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

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

Якщо ви хочете почати писати свою логіку побудови в Котліні, вам знадобиться встановити DSL Gradle Kotlin та дотримуватися вказівок у посібнику з міграції.

Підведенню

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

Ви розширили Gradle для автоматизації інших частин процесу збирання Android? Повідомте нас у коментарях нижче!