build.gradle: vad är det, syntax och konfiguration i Android

Vad är build.gradle?

build.gradle är ett byggskript i språket Groovy (tillägget .gradle) eller Kotlin (.gradle.kts) som hanterar alla aspekter av kompileringen av en Android-app. Gradle är ett automatiskt byggsystem som antogs av Google 2013 som standard för Android. build.gradle beskriver: vilka plugins som har tillämpats (Android, Kotlin, bibliotek), vilka beroenden som är anslutna, vilka SDK-versioner som används, hur man signerar appen och var man publicerar.

Byggprocessen omfattar tre faser: Initialization (bestämning av moduler), Configuration (exekvering av build.gradle-skript), Execution (exekvering av uppgifter). build.gradle exekveras i Configuration-fasen, när Gradle skapar uppgiftsgrafen. Vid denna tidpunkt bestäms Build Variants, beroenden beräknas och uppgifter konfigureras. Viktigt: build.gradle är kod, inte bara konfiguration. Den kan innehålla villkor, loopar, metodanrop och externa skript.

Gradle-filer lagras i modulens rot (app/build.gradle) och projektets rot (build.gradle). Dessutom stöder Gradle apply from — anslutning av externa Gradle-skript. Detta gör det möjligt att extrahera repetitiv logik till filer med gemensamma inställningar. Med introduktionen av Convention Plugins (AGP 7+) anses apply from vara föråldrat — Convention Plugins erbjuder ett type-safe och sammansatt sätt att återanvända konfiguration mellan moduler.

Utvecklingen av build.gradle

Sedan 2013 har syntaxen för build.gradle genomgått betydande förändringar: från Groovy med dynamiska konfigurationer till Kotlin DSL med kompileringskontroller. AGP har utvecklats från version 1.0 till 8.7 (2025). Viktiga milstolpar: AGP 3.0 (Java 8 desugar, new variant API), AGP 4.0 (view binding, Java 11), AGP 7.0 (Kotlin DSL som standard, Java 11 min), AGP 8.0 (non-transitive R classes, byggkonfiguration i Kotlin), AGP 8.7 (KSP istället för kapt, snabb konfiguration).

Project-level och Module-level build.gradle

Project-level build.gradle (rot) anger plugins, repositories och konfigurationer som är gemensamma för alla moduler. Huvudblock: plugins (anslutning av Gradle-plugins), repositories (beroendekällor: mavenCentral, google, jitpack). I rot-build.gradle finns det vanligtvis inget android-block — det visas i modulerna. Project-level kan också innehålla blocket subprojects för gemensam konfiguration av alla underprojekt, även om Convention Plugins är att föredra.

Module-level build.gradle (t.ex. app/build.gradle) beskriver en specifik modul. Om modulen är en app tillämpar den plugin-programmet com.android.application. Om det är ett bibliotek — com.android.library. I module-level finns: android-blocket (compileSdk, defaultConfig, buildTypes, productFlavors), dependencies-blocket (modulens beroenden) och valfria block för konfiguration av tester och bygge. Module-level exekveras efter project-level och kan åsidosätta gemensamma inställningar.

Från och med AGP 8.0 kan rot-build.gradle använda version catalogs (libs.versions.toml) för centraliserad hantering av beroendeversioner. En version catalog är en fil i katalogen gradle/ som innehåller versioner, bibliotek och plugins. I build.gradle ansluts beroenden via libs: implementation(libs.retrofit). Version catalogs är obligatoriska för nya projekt och rekommenderas för alla projekt med tre eller fler moduler.

// settings.gradle.kts — projektrot
pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

// build.gradle.kts (projektnivå)
plugins {
    id("com.android.application") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.21" apply false
}

// app/build.gradle.kts (modulnivå)
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    id("com.google.devtools.ksp")
}

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

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 35
        versionCode = 1
        versionName = "1.0.0"
    }
}

Groovy vs Kotlin DSL

Groovy är ett dynamiskt JVM-språk som var Gradles ursprungliga syntax. Groovy-skript (.gradle) använder dynamisk typning: typer kan utelämnas, citattecken kan användas eller inte, metoder som inte finns i kompileringsfasen kan anropas. Flexibiliteten hos Groovy är också dess nackdel: IDE kan inte kontrollera syntax och typer före exekvering av skriptet, vilket leder till runtime-fel vid felaktigt parameternamn eller typ.

Kotlin DSL (.gradle.kts) använder Kotlins statiska typning. IDE kontrollerar typer, föreslår tillgängliga parametrar via autoslutförande och markerar fel i redigeringsfasen. Kotlin DSL är långsammare i Configuration-fasen (på grund av kompilering av .kts-filer till bytekod), men Google förbättrar kontinuerligt prestandan: AGP 8.5+ använder Gradle Configuration Cache och Caching Kotlin DSL compilation, vilket minskar skillnaden till 1-2 sekunder.

Google rekommenderar Kotlin DSL för alla nya projekt och gradvis migrering av befintliga. Migrering från Groovy till Kotlin DSL är enkel: citattecken ersätts med parenteser, typer läggs till, operatorer omvandlas till funktioner. De flesta bibliotek tillhandahåller Kotlin DSL-exempel i dokumentationen. För komplexa fall (Custom Plugin, Task Graph) erbjuder Kotlin DSL type-safe API och förhindrar fel som i Groovy upptäcks först vid körning. Version catalogs (libs.versions.toml) fungerar likadant med båda syntaxerna.

Android-block: konfigurera appen

compileSdk, minSdk och targetSdk

Android-blocket — den centrala delen av module-level build.gradle. Inuti det konfigureras: namespace (för R och BuildConfig), compileSdk, defaultConfig, buildTypes, productFlavors, sourceSets, compileOptions, packaging, bundle. Alla parametrar i android-blocket gäller endast Android-moduler. Om modulen är ett bibliotek används biblioteksplugin istället för app, och det finns inget applicationId i android-blocket.

compileSdk — SDK-versionen som koden kompileras med. Bör vara lika med det senaste Android API (vid skrivande stund — 35). minSdk — den lägsta API-versionen för support. targetSdk — den version som appen är riktad mot (beteendeförändringar i denna version tillämpas). Skillnaden mellan compileSdk och targetSdk: compileSdk bestämmer tillgängliga API:er, targetSdk — runtime-beteende. Rekommendation: compileSdk = latest, targetSdk = latest - 1 (för att testa anpassning till nya ändringar).

compileOptions ställer in Java-kompatibilitet: sourceCompatibility och targetCompatibility. AGP 8+ kräver Java 17+ för kompilering. packaging hanterar inkludering av filer från bibliotek: exclude, merge, pickFirst för att lösa META-INF-konflikter. buildFeatures aktiverar/inaktiverar ViewBinding, DataBinding, Compose. aaptOptions konfigurerar resursbearbetning: ignoreAssetsPattern, cruncherEnabled. Varje element i android-blocket optimerar en specifik aspekt av bygget.

android {
    namespace = "com.example.myapp"
    compileSdk = 35
    buildToolsVersion = "35.0.0"

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 35
        versionCode = 5
        versionName = "2.3.1"

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        getByName("debug") { isDebuggable = true }
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"))
        }
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }

    buildFeatures {
        viewBinding = true
        compose = true
    }
}

Hantera beroenden

BOM (Bill of Materials)

Beroenden i build.gradle är bibliotek och moduler som är anslutna till projektet. Blocket dependencies finns på samma nivå som android-blocket. Gradle stöder flera konfigurationer: implementation (biblioteket är tillgängligt i denna modul, inte transitivt), api (biblioteket är transitivt tillgängligt för beroende moduler), compileOnly (endast för kompilering, ingår inte i APK), runtimeOnly (endast vid körning), annotationProcessor / ksp (annotationsprocessorer), testImplementation (endast för testning), androidTestImplementation (endast för instrumentella tester).

Från och med AGP 8.0 har Non-Transitive R classes — varje bibliotek har sin egen R-klass, vilket förhindjar resurskonflikter. I dependencies-blocket är det viktigt att använda rätt konfigurationer: implementation avslöjar inte transitiva beroenden, vilket påskyndar bygget. api avslöjar — används när biblioteket exporterar typer från ett annat bibliotek (t.ex. Retrofit använder OkHttp-typer i sitt publika API).

För versionshantering rekommenderas att använda BOM (Bill of Materials) — en byggfil som bestämmer kompatibla versioner av bibliotek. Firebase BOM: implementation(platform("com.google.firebase:firebase-bom:33.0.0")). Efter anslutning av BOM kan endast biblioteksnamnet utan version anges — BOM väljer automatiskt den kompatibla versionen. Detta eliminerar konflikter mellan transitiva beroenden från olika bibliotek. BOM finns tillgängligt för Firebase, Compose, Kotlin, Ktor, AndroidX.

dependencies {
    // BOM — versionshantering
    implementation(platform("androidx.compose:compose-bom:2024.12.01"))
    implementation(platform("com.google.firebase:firebase-bom:33.0.0"))

    // AndroidX och Compose
    implementation("androidx.core:core-ktx")
    implementation("androidx.lifecycle:lifecycle-runtime-ktx")
    implementation("androidx.activity:activity-compose")
    implementation("androidx.compose.ui:ui")

    // Network
    implementation("com.squareup.retrofit2:retrofit:2.11.0")
    implementation("com.squareup.okhttp3:okhttp:4.12.0")

    // Firebase (versioner från BOM)
    implementation("com.google.firebase:firebase-firestore")
    implementation("com.google.firebase:firebase-crashlytics")

    // Testning
    testImplementation("junit:junit:4.13.2")
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
}

build.gradle i multimodulära projekt

I multimodulära projekt har varje modul sin egen build.gradle. För att ansluta en modul till en annan används syntaxen implementation(project(":module-name")). Gradle bygger automatiskt modulen om dess konfiguration har ändrats. Multimodulär arkitektur förbättrar byggtiden (inkrementellt bygge, parallellism) och delar upp ansvaret mellan feature-moduler, core-moduler och bibliotek.

Huvudproblemet med multimodulära projekt — duplicering av konfiguration. Om 10 moduler har samma minSdk, compileSdk och Compose-beroenden är det 10 kopior i olika build.gradle-filer. Lösningen — Convention Plugins (tidigare buildSrc). Convention Plugin är ett Gradle-plugin skrivet i Kotlin som tillämpas på moduler: plugins { id("myapp.android.library") }. Plugin-programmet innehåller gemensam konfiguration och ändringar tillämpas omedelbart på alla moduler.

För organisering av Convention Plugins används katalogen build-logic/ i projektroten. Den innehåller includeBuild i settings.gradle och Kotlin-plugins. Convention Plugins kan publiceras i ett maven-repository för återanvändning mellan projekt. Google rekommenderar Convention Plugins som standard för multimodulära projekt, vilket ersätter subprojects { } och apply from. Övergången till Convention Plugins minskar modulens build.gradle till 10-15 rader.

// build-logic/src/main/kotlin/AndroidLibraryConventionPlugin.kt
class AndroidLibraryConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            with(plugins) {
                apply("com.android.library")
                apply("org.jetbrains.kotlin.android")
            }
            extensions.configure<CommonExtension<*, *, *, *>> {
                compileSdk = 35
                defaultConfig { minSdk = 26 }
                compileOptions {
                    sourceCompatibility = JavaVersion.VERSION_17
                    targetCompatibility = JavaVersion.VERSION_17
                }
            }
        }
    }
}

// module/build.gradle.kts — efter Convention Plugin
plugins {
    id("myapp.android.library")
}

dependencies {
    implementation(project(":core:network"))
}