Build Gradle: что это в Android

Введение: почему build.gradle пугает

«Откройте build.gradle и расскажите, что здесь происходит» — с этого вопроса неожиданно начинаются многие собеседования. Кандидат, который бодро объясняет ViewModel и корутины, на этом месте часто замолкает: файл он видел сотни раз, но что в нём написано — не знает.

Парадокс в том, что build.gradle — это файл, который вы трогаете едва ли не каждый день: добавить зависимость, поднять compileSdk, включить minify. Но мало кто может объяснить, что именно делает Gradle, чем build.gradle отличается от settings.gradle и почему без Android Gradle Plugin этот файл бесполезен.

А ведь это не только вопрос для собеседования. Без понимания сборки невозможно разобраться в том, почему проект собирается две минуты, почему падает билд после обновления AGP и куда делась зависимость, которую вы вроде бы подключили. Разберём build.gradle по косточкам.

Что делает Gradle при сборке

Gradle — это система автоматизации сборки (build automation tool), которая на основе описания проекта выполняет цепочку задач: компилирует Kotlin и Java в байткод, собирает ресурсы, упаковывает их, подписывает и превращает в готовый артефакт. В Android-проекте этим артефактом становится APK или AAB.

Вы не запускаете компилятор и упаковщик руками — вы говорите Gradle «собери мне приложение», и он сам решает, какие задачи и в каком порядке выполнить. Этот принцип описан в Core Concepts документации Gradle.

Сам Gradle написан на JVM и запускается в фоновом процессе — Gradle daemon, поэтому повторные сборки быстрее. Версия Gradle фиксируется в проекте через Gradle Wrapper (gradlew): это маленькая программа, которая сама скачивает и запускает нужную версию Gradle — так все разработчики в команде собирают проект одинаково. Это описано в документации по настройке сборки.

Ещё одна важная деталь — сборка проходит через фазы: сначала Gradle читает настройки и конфигурирует проект (выполняет build-скрипты), потом исполняет задачи. Отсюда следует практический вывод: всё тяжёлое, что написано прямо в скрипте, выполняется на каждой сборке, поэтому конфигурацию держат лёгкой, а реальную работу выносят в задачи. Этот же механизм объясняет инкрементальную сборку: неизменённые задачи Gradle помечает как UP-TO-DATE и пропускает.

Главные файлы сборки

В современном Android-проекте три ключевых файла конфигурации, и это важно понимать именно как систему, а не по отдельности.

settings.gradle.kts — корневой файл настроек. Он объявляет репозитории, из которых берутся плагины и зависимости, и перечисляет модули проекта:

pluginManagement {
    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "My Application"
include(":app")

Корневой build.gradle.kts — описывает версии плагинов для всех модулей. Ключевой момент — apply false: плагин объявляется как зависимость сборки, но не применяется к корневому проекту:

plugins {
    id("com.android.application") version "9.3.0" apply false
    id("com.android.library") version "9.3.0" apply false
    id("org.jetbrains.kotlin.android") version "2.3.21" apply false
}

Модульный build.gradle.kts — файл в папке каждого модуля (app/). Вот он и есть тот самый build.gradle, который вы открываете чаще всего:

plugins {
    id("com.android.application")
}

android {
    namespace = "com.example.myapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 23
        targetSdk = 36
        versionCode = 1
        versionName = "1.0"
    }

    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

dependencies {
    implementation("androidx.appcompat:appcompat:1.8.0")
}

Именно модульный файл настраивает сам модуль: SDK-уровни, типы сборки, сорта приложения и зависимости. Корневой — только версии плагинов.

Android Gradle Plugin: что добавляет AGP

Блок android { ... } в build.gradle — не встроенная возможность Gradle. Его добавляет Android Gradle Plugin (AGP) — плагин, который превращает универсальный Gradle в инструмент сборки Android-приложений.

AGP добавляет Android-специфичные настройки и задачи:

• compileSdk — какой уровень Android API доступен при компиляции кода.
• minSdk — минимальная версия Android, на которой приложение может работать.
• targetSdk — версия, под которую вы тестировали приложение; при более высоком API устройства Android включает режим совместимости.
• applicationId — уникальный идентификатор приложения для публикации.
• buildTypes — типы сборки: по умолчанию debug (с инструментами отладки, подписан debug-ключом) и release (с обфускацией, обычно не подписан).
• productFlavors — сорта приложения, например бесплатная и платная версия с разными applicationId.

Всё это описано в официальном гайде Configure your build, и оттуда же взяты примеры выше — это реальный синтаксис актуального AGP.

Задачи и зависимости

Сборка в Gradle — это выполнение задач (tasks). Посмотреть, какие задачи доступны, можно командой ./gradlew tasks, а запустить сборку — ./gradlew assembleDebug. Знакомые вам вещи — это тоже задачи: lint (проверка качества кода), test (юнит-тесты), bundleRelease (сборка AAB для Google Play), installDebug (установка на устройство).

Gradle выполняет только необходимые задачи: если код не менялся, задача помечается как UP-TO-DATE и пропускается. Поэтому вторая сборка проходит быстрее.

Зависимости объявляются в блоке dependencies с указанием конфигурации:

• implementation — основная конфигурация: зависимость доступна в коде модуля, но не «просвечивает» наружу.
• testImplementation — для юнит-тестов.
• androidTestImplementation — для инструментальных тестов.
• debugImplementation / releaseImplementation — зависимости только для конкретного типа сборки.

Откуда Gradle берёт библиотеки? Из репозиториев, объявленных в settings.gradle: google() — Google Maven с AndroidX и AGP, mavenCentral() — центральный репозиторий Maven. В больших проектах версии выносят в version catalog (файл libs.versions.toml) или BOM, чтобы не дублировать их по модулям — эту практику рекомендует и документация Android.

[versions]
agp = "9.3.0"
appcompat = "1.8.0"

[libraries]
androidx-appcompat = { group = "androidx.appcompat", name = "appcompat", version.ref = "appcompat" }

[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }

Подключение через каталог выглядит как implementation(libs.androidx.appcompat) — и версии перестают разъезжаться между модулями: вы меняете одну строку в libs.versions.toml, и она обновляется везде. В новых проектах Android Studio создаёт version catalog автоматически, так что встретите вы его почти наверняка.

• Gradle — универсальная система автоматизации сборки, AGP добавляет в неё Android-специфику.
• settings.gradle.kts — модули и репозитории; корневой build.gradle.kts — версии плагинов; модульный — настройки конкретного модуля.
• compileSdk, minSdk, targetSdk и applicationId — базовые поля android-блока, спрашивают всегда.
• buildTypes создают варианты сборки; implementation — основная конфигурация зависимостей.
• Version catalog и BOM — современный способ централизовать версии зависимостей.

На собеседованиях я часто вижу одну и ту же картину: человек умеет добавить зависимость через меню Android Studio, но не может объяснить, что произошло после клика. Это нормальная точка роста — сборка перестаёт быть «чёрным ящиком» буквально за пару вечеров разбора. Тот же навык структурированного ответа пригодится и в других темах: платформа, жизненный цикл, архитектура.

Итоги

Build.gradle — это не «страшный файл с настройками», а описание того, как проект превращается в приложение.

• Gradle — универсальная система сборки, которая выполняет цепочку задач.
• AGP — плагин, добавляющий Android-специфику: блок android, SDK-уровни, buildTypes, сорта.
• Три файла — settings.gradle, корневой и модульный build.gradle — отвечают за разные части: репозитории, версии плагинов и настройки модуля.

Если после прочтения вы поняли, что сборку объясняете пока на пальцах — не нужно зубрить. Напишите в Telegram, разберём вашу ситуацию и составим план, с чего начать подготовку.