Gradle: суть системи збірки для Android та build.gradle
Gradle — це система збірки, яка автоматизує компіляцію, тестування та пакування Android-додатків. На відміну від Apache Ant або Maven, вона підтримує інкрементальну збірку та кешування результатів. Докладніше про можливості читайте в офіційній документації Gradle. З 2013 року інструмент використовується як стандартна система збірки для Android-проєктів в Android Studio.
Головне
- Gradle — стандартна система збірки для Android з 2013 року, що замінила Ant та Maven
- Build.gradle.kts на Kotlin DSL — сучасний стандарт конфігурації з перевіркою типів
- Build variants комбінують типи збірки та продуктові флейвори для різних версій додатку
- Плагіни розширюють функціональність: від застосування Android-інструментів до публікації білдів
- Інкрементальна збірка та кешування скорочують час повторної компіляції в кілька разів
Що таке Gradle?
Gradle — це інструмент автоматизації збірки з відкритим кодом на Java, що працює на JVM. Він приймає на вхід вихідний код, залежності та ресурси, а на виході видає готовий додаток — APK або AAB для Android. В основі Gradle лежить концепція орієнтованого ациклічного графа задач (DAG), де кожна задача — це атомарна одиниця роботи, а зв'язки між ними визначають порядок виконання. На відміну від Make або Ant, Gradle не вимагає опису послідовності кроків вручну: достатньо оголосити залежності між задачами, і система сама вибудує оптимальний порядок. Такий підхід робить Gradle гнучким та масштабованим для проєктів будь-якого розміру.
Система використовує три фази виконання: ініціалізацію (визначення учасників проєктів), конфігурацію (побудова графа задач) та виконання (запуск задач у потрібному порядку). Фаза конфігурації — ключова відмінність Gradle: весь скрипт збірки виконується до запуску задач, що дозволяє динамічно змінювати граф залежно від умов. Це дає можливість, наприклад, додавати задачі тільки для певних варіантів збірки без дублювання коду. Збірник написаний на Groovy, але конфігураційні файли підтримують дві мови: Groovy DSL та Kotlin DSL.
Як Gradle керує збіркою Android-проєктів?
Android-плагін для Gradle — це com.android.application та com.android.library, які додають у проєкт задачі для роботи з Android-інструментами. Коли розробник запускає збірку, Gradle послідовно виконує десятки задач: компіляцію Kotlin та Java через javac або kotlinc, обробку ресурсів через AAPT2, генерацію R.java, компіляцію байткоду в DEX через D8 або R8, підписання та зіппінг APK. Кожна задача перевіряє, чи змінилися її вхідні дані, і якщо ні — використовує закешований результат. Цей механізм називається інкрементальною збіркою і прискорює повторну компіляцію на 60–80% порівняно з повною перезбіркою.
Конфігурація Android-модуля задається в блоці android файлу build.gradle.kts. Всередині блоку визначаються compileSdk, minSdk, targetSdk, версія додатку, підписи та інші параметри. Gradle автоматично створює для кожного модуля кілька варіантів збірки — комбінацію типу (release, debug) та флейвору. Наприклад, для модуля з двома флейворами та двома типами Gradle генерує чотири задачі: assembleDemoDebug, assembleDemoRelease, assembleFullDebug, assembleFullRelease. Всі ці задачі можна виконувати окремо або запускати однією командою для всіх варіантів одразу.
Build.gradle та build.gradle.kts: структура конфігурації
Кожен Android-проєкт містить два рівні конфігурації: кореневий build.gradle.kts (налаштування для всіх модулів) та модульний build.gradle.kts (налаштування для конкретного модуля). У кореневому файлі оголошуються плагіни без застосування, репозиторії та загальні змінні. У модульному файлі плагіни застосовуються до конкретного модуля та налаштовуються параметри збірки. Такий підхід дозволяє централізовано керувати версіями залежностей через каталог версій або ext-блок.
Kotlin
@Suppress("UnstableApiUsage")
plugins {
id("com.android.application") version "8.2.2"
id("org.jetbrains.kotlin.android") version "1.9.22"
}
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}Блок dependencies — ще один критичний елемент build.gradle.kts. У ньому перераховуються бібліотеки, модулі та файлові залежності, які потрібні додатку. Gradle підтримує кілька конфігурацій залежності: implementation (доступна тільки поточному модулю), api (доступна і залежним модулям), testImplementation (тільки для тестів), androidTestImplementation (для інструментальних тестів) та compileOnly (тільки на етапі компіляції). Кожна конфігурація керує видимістю класів у графі залежностей, що впливає на час збірки та розмір фінального артефакту.
Kotlin
dependencies {
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
implementation("androidx.activity:activity-compose:1.8.2")
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.5")
}Build variants: варіанти збірки додатку
Build variant — це комбінація build type та product flavor, яка визначає версію додатку з унікальними налаштуваннями, кодом та ресурсами. Build type (тип збірки) задає параметри пакування: debug (з налагодженням та суфіксом .debug) або release (з обфускацією та підписом). Product flavor (продуктовий флейвор) визначає функціональні варіанти: наприклад, demo (обмежена версія) та full (повна версія з додатковими можливостями). Gradle автоматично генерує задачі для кожної комбінації, що дозволяє збирати всі версії однією командою.
Kotlin
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
applicationIdSuffix = ".debug"
}
}
flavorDimensions += "version"
productFlavors {
create("demo") {
dimension = "version"
applicationIdSuffix = ".demo"
}
create("full") {
dimension = "version"
applicationIdSuffix = ".full"
}
}
}Кожному build variant відповідає окремий source set. Gradle використовує каталоги src/demo/release, src/full/debug та інші, де зберігаються унікальні ресурси, маніфести та вихідні файли для конкретного варіанту. Загальний код залишається в src/main. Такий підхід дозволяє перевикористовувати основну логіку та замінювати тільки відмінні частини: рядки, іконки, API-ендпоінти або конфігураційні файли. Source set може перевизначати будь-які ресурси з main: маніфест, drawable, values або навіть Kotlin-класи. При збірці конкретного варіанту Gradle об'єднує файли з main та відповідного source set, при цьому файли з варіанту мають пріоритет.
Плагіни Gradle для Android: розширення можливостей
Екосистема плагінів Gradle охоплює всі етапи розробки Android-додатків. Офіційні плагіни від Google включають com.android.application (для модуля додатку), com.android.library (для бібліотечного модуля), com.android.test (для тестових модулів) та Kotlin-плагіни від JetBrains. Плагіни додають у проєкт нові задачі, розширюють DSL новими блоками конфігурації та підключають додаткові інструменти. Без плагіна com.android.application проєкт не може зібрати APK: цей плагін реєструє всі Android-специфічні задачі та зв'язує їх у граф збірки.
Сторонні плагіни вирішують більш вузькі задачі. Google Services (com.google.gms.google-services) інтегрує Firebase та Google Play Services, автоматично підставляючи google-services.json у збірку. Hilt (dagger.hilt.android.plugin) генерує код для впровадження залежностей на етапі компіляції. Safe Args (androidx.navigation.safeargs.kotlin) створює типобезпечні класи для навігації між фрагментами. Кожен плагін підключається в кореневому build.gradle.kts через блок plugins і зазвичай вимагає мінімальної конфігурації. Gradle автоматично розв'язує транзитивні залежності між плагінами та гарантує сумісність версій через Bom-файли та каталог версій.
Gradle-таски: автоматизація процесів збірки
Таска (task) — це атомарна одиниця роботи в Gradle. Кожна таска має вхідні дані, вихідні дані та дію. Вбудовані таски для Android включають assemble (збірка всіх варіантів), lint (перевірка коду), test (запуск unit-тестів) та clean (очищення тимчасових файлів). Розробник може додавати власні таски за допомогою Groovy або Kotlin DSL. Користувацькі таски корисні для автоматизації рутинних операцій: генерації звітів, копіювання артефактів, деплою на тестові пристрої або інтеграції з CI-системами.
Kotlin
tasks.register("printBuildInfo") {
description = "Виводить інформацію про збірку"
group = "custom"
doLast {
println("Build variant: ${project.name}")
println("Version: ${android.defaultConfig.versionName}")
}
}Кожна таска може залежати від інших тасок через механізм dependsOn. Якщо таска A залежить від таски B, Gradle гарантує, що B виконається раніше A. Система не вимагає ручного вказівки порядку для кожної пари — достатньо оголосити залежності, і Gradle побудує орієнтований граф, оптимізований для паралельного виконання незалежних тасок. Вбудовані таски Android-плагіна вже пов'язані між собою: lint залежить від компіляції, test залежить від assemble, assembleDebug залежить від compileDebugKotlin. Розробник може вбудовувати свої таски в будь-який вузол графа, використовуючи dependsOn, mustRunAfter або shouldRunAfter.
Типові помилки при роботі з Gradle
Одна з частих проблем — конфлікт версій залежностей, коли дві бібліотеки вимагають різні версії однієї й тієї ж транзитивної залежності. Gradle повідомляє про помилку конфлікту, але не завжди пропонує автоматичне рішення. Для діагностики використовуйте команду ./gradlew :app:dependencies, яка виводить повне дерево залежностей. Рекомендується примусово вказати версію конфліктуючої бібліотеки через блок resolutionStrategy. Інший поширений сценарій — повільна збірка через відсутність інкрементальної обробки. Перевірте, що всі плагіни оновлені, Gradle Daemon увімкнено (org.gradle.daemon=true) та в gradle.properties задано достатній обсяг пам'яті: org.gradle.jvmargs=-Xmx4096m.
Проблеми з кешуванням виникають після оновлення залежностей: Gradle може використовувати застарілий кеш, і збірка завершується помилкою. Рішення — запустити збірку з прапорцем --refresh-dependencies або очистити кеш вручну через ./gradlew cleanBuildCache. Третя за частотою помилка — несумісність версій Android Gradle Plugin (AGP) та Gradle. Кожна версія AGP вимагає певної мінімальної версії Gradle. Таблиця сумісності публікується на developer.android.com. Якщо версії несумісні, Gradle завершується помилкою на етапі конфігурації з повідомленням про мінімальну необхідну версію. Завжди перевіряйте, що версія Gradle wrapper відповідає вимогам AGP.
Часті запитання
Що таке Gradle простими словами?
Gradle — це програма-автоматизатор збірки проєктів. Вона бере ваш вихідний код на Kotlin або Java, підключає бібліотеки з інтернету, компілює все в байткод та пакує в APK. Працює на JVM та використовує декларативні скрипти замість ручних інструкцій. Розробнику потрібно тільки описати правила, а решта Gradle робить сам.
Чим build.gradle.kts відрізняється від build.gradle?
Build.gradle пишеться на Groovy — динамічній мові з гнучким синтаксисом і меншою строгістю. Build.gradle.kts використовує Kotlin DSL: строга типізація, автодоповнення в Android Studio та перевірка помилок на етапі компіляції. Google рекомендує Kotlin DSL для всіх нових проєктів. Groovy-файли легше мігрувати, але Kotlin-файли надійніші в підтримці.
Як прискорити збірку Gradle?
Увімкніть Gradle Daemon (org.gradle.daemon=true) та паралельну збірку (org.gradle.parallel=true). Збільште пам'ять JVM до 4–8 ГБ через org.gradle.jvmargs. Використовуйте конфігурацію проєктів on-demand (org.gradle.configureondemand=true). Для Android-проєктів налаштуйте кешування задач та збірку тільки для потрібної ABI. В Android Studio запустіть Build Analyzer, щоб знайти вузькі місця.
Що таке build variant в Android?
Build variant — це комбінація build type (наприклад, debug або release) та product flavor (наприклад, demo або full). Кожен варіант може мати своє ім'я пакета, версію, ресурси та вихідні файли. Gradle автоматично створює окрему задачу збірки для кожного варіанту. Це дозволяє збирати кілька версій додатку з одного проєкту.
Як додати залежність в Gradle?
Залежності додаються в блок dependencies файлу build.gradle.kts. Формат запису: configuration("group:artifact:version"). Наприклад, implementation("androidx.core:core-ktx:1.12.0"). Для тестів використовуйте testImplementation, для інструментальних тестів — androidTestImplementation. Версії зручно виносити в окремий каталог версій (version catalog) через файл libs.versions.toml.
Підсумки
- Gradle — стандартна система збірки для Android, що працює на JVM та використовує DAG-граф задач
- Інкрементальна збірка та кешування скорочують час повторної компіляції на 60–80%
- Kotlin DSL (build.gradle.kts) — сучасний формат конфігурації з автодоповненням та перевіркою типів
- Build variants комбінують build type та product flavor, створюючи окремі source set для кожного варіанту
- Плагіни розширюють Gradle: від базового Android-плагіна до Firebase, Hilt та Safe Args
- Користувацькі таски дозволяють автоматизувати будь-які етапи збірки та інтеграції
- Основні проблеми — конфлікти версій, повільна збірка та несумісність AGP з версією Gradle
Ми розробимо мобільний застосунок під ключ
IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.
Читайте також