Как настроить build.gradle в Android‑проекте

В файлах build.gradle задаются версия AGP и Kotlin, compileSdk/minSdk, зависимости и правила сборки — то есть всё, что нужно для корректной сборки APK/AAB. Ниже — практическая структура и готовые шаблоны, которые можно вставить и сразу использовать.

Project-level (корень): плагины и репозитории

Файл в корне проекта управляет версиями плагинов и общими репозиториями. Блок plugins фиксирует версии AGP и Kotlin — это убережёт от конфликтов при обновлениях.

Пример (settings.gradle.kts или build.gradle в корне с плагинами):

plugins {
    id 'com.android.application' version '8.7.2' apply false
    id 'com.android.library'     version '8.7.2' apply false
    id 'org.jetbrains.kotlin.android' version '2.0.20' apply false
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

Практический совет: фиксируйте версии плагинов в корне и не дублируйте их в модульных build-файлах.

App-level: android { }, dependencies и buildTypes

Основной файл — app/build.gradle(.kts). Здесь указывают namespace, compileSdk, defaultConfig, buildTypes, signingConfigs и зависимости.

Пример (Groovy):

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
    id 'kotlin-kapt'
}

android {
    namespace 'com.example.myapp'
    compileSdk 36

    defaultConfig {
        applicationId "com.example.myapp"
        minSdk 24
        targetSdk 36
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
    kotlinOptions { jvmTarget = "17" }
}

Примеры зависимостей (группируйте по назначению):

dependencies {
    // Core
    implementation 'androidx.core:core-ktx:1.15.0'
    implementation 'androidx.appcompat:appcompat:1.7.0'

    // Network
    implementation 'com.squareup.retrofit2:retrofit:2.11.0'
    implementation 'com.squareup.retrofit2:converter-gson:2.11.0'

    // DI
    implementation 'com.google.dagger:hilt-android:2.52'
    kapt 'com.google.dagger:hilt-compiler:2.52'
}

Сборки, flavor'ы, подпись и CI

• Product flavors используют applicationIdSuffix и versionNameSuffix для параллельных установок:

productFlavors {
    free { applicationIdSuffix ".free"; versionNameSuffix "-free" }
    pro  { applicationIdSuffix ".pro" }
}

• signingConfigs для CI: храните секреты в переменных окружения, не в файлах репозитория:

signingConfigs {
    release {
        storeFile file(System.getenv("KEYSTORE_PATH"))
        storePassword System.getenv("KEYSTORE_PASS")
        keyAlias System.getenv("KEY_ALIAS")
        keyPassword System.getenv("KEY_PASS")
    }
}

• Сборка в CI: ./gradlew assembleRelease или сборка AAB через bundleRelease. Включите параметр --no-daemon и кеширование Gradle для ускорения.

Частые ошибки

• Конфликты версий библиотек → используйте dependencyConstraints или resolutionStrategy.
• Хардкод секретов (keystore, пароли) в репозитории → храните в CI secrets.
• Несовместимый JDK/AGP → проверяйте JavaVersion и AGP-версии перед обновлением.
• Забытый minify/proguard для релиза → увеличивает размер APK и риски утечек.

FAQ

• Как перейти на Kotlin DSL?
  Перенесите build.gradle → build.gradle.kts, используйте типобезопасные плагины и обновите синтаксис зависимостей; тестируйте в ветке CI.

• Почему приложение падает после обновления библиотеки?
  Часто из‑за изменений API или конфликтов транзитивных зависимостей — фиксируйте версии и проверяйте changelog.

• Нужно ли включать minifyEnabled для debug?
  Нет. Minify полезен для релиза (оптимизация и обфускация), в debug он затруднит отладку.

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