Build Type — wat is het, debug- en releaseconfiguratie in Gradle

Wat is Build Type?

Build Type is een element van de Gradle-configuratie van een Android-project dat de parameters van compilatie en verpakking van de applicatie beschrijft. Elk Build Type is een benoemde set opties: debuggable (debugging inschakelen), minificationEnabled (codecompressie inschakelen), shrinkResources (broncompressie inschakelen), proguardFiles (ProGuard-regelbestanden), signingConfig (ondertekeningscertificaat) en andere. Build Types worden gedeclareerd in het android.buildTypes-blok van het build.gradle-bestand van de app-module.

De hoofdtaak van Build Type is het scheiden van development workflow (snelle build, gedetailleerde logs, debugging) en production release (geoptimaliseerde code, minimale grootte, beveiliging). De debug-build moet in seconden worden gebouwd en maximale informatie aan de ontwikkelaar geven. De release-build moet zo snel en compact mogelijk zijn voor gebruikers. Build Type is een infrastructurele configuratie die niet gerelateerd is aan de functionaliteit van de applicatie.

Android Gradle Plugin maakt automatisch een source set voor elk Build Type — de map src/<buildType>/ (bijvoorbeeld src/debug/, src/release/). In deze source set kunnen bronnen, code en manifest worden geplaatst die alleen voor dat buildtype worden toegepast. Bijvoorbeeld, in src/debug/ kan AndroidManifest.xml met toestemming voor installatie vanuit ADB worden geplaatst, en in src/release/ — zonder. Build Type source set heeft prioriteit boven Product Flavor source set.

Build Type vs Product Flavor

Het belangrijkste verschil: Build Type beantwoordt de vraag “hoe te bouwen?”, en Product Flavor — de vraag “wat te bouwen?”. Build Type kan debug, release, staging zijn. Product Flavor kan free, paid, enterprise zijn. Build Type verandert de functionaliteit van de applicatie niet (voegt geen schermen toe of verwijdert ze niet), Product Flavor — wel. Build Type kan de debugger uitschakelen en obfuscatie inschakelen, Product Flavor kan applicationId en bronnen wijzigen. Beide werken in paren: elk Build Type combineert met elk Product Flavor en vormt Build Variant.

Standaard Build Types: debug en release

Debug is het Build Type dat standaard door AGP wordt aangemaakt. Het heeft debuggable=true, wat het mogelijk maakt de debugger aan te sluiten, Log.d-logboeken te bekijken en de Android Studio-profiler te gebruiken. Minification is uitgeschakeld, dus de build is snel. In debug-build krijgt applicationId het suffix “.debug” (indien niet overschreven), waardoor de debug-versie parallel met de release-versie op hetzelfde apparaat kan worden geïnstalleerd. Debug wordt ondertekend met het certificaat uit debug.keystore, dat automatisch door Android SDK wordt aangemaakt.

Release is het Build Type voor publicatie van de applicatie. debuggable=false, minificationEnabled=true (standaard), shrinkResources=true. De ontwikkelaar moet signingConfig met een productiecertificaat specificeren — anders wordt de build niet als release beschouwd. Release gebruikt ProGuard of R8 voor obfuscatie, optimalisatie en compressie van code. Android Studio kan geen debugger aansluiten op een release-build (als debuggable=false). Alle Log.d- en Log.v-aanroepen worden in de minificatiefase uit de code verwijderd, als de juiste ProGuard-regels zijn geconfigureerd.

Belangrijk: debug-builds testen het gedrag van release niet. Minificatie kan het gedrag van code veranderen — reflection, serialisatie, Gson/SQLite en andere bibliotheken vereisen vaak ProGuard-regels. Daarom moet u vóór publicatie de release-build maken en testen. Google Play Console en Firebase Test Lab maken het mogelijk release-builds te uploaden voor automatisch testen op echte apparaten vóór publicatie.

android {
    buildTypes {
        debug {
            debuggable true
            minification false
            signingConfig signingConfigs.debug
            versionNameSuffix "-debug"
        }

        release {
            debuggable false
            minification true
            shrinkResources true
            proguardFiles "proguard-rules.pro"
            signingConfig signingConfigs.release
            ndk { abiFilters "arm64-v8a", "x86_64" }
        }
    }
}

Aangepaste Build Types maken

Overerving via initWith

Naast debug en release kunt u eigen Build Types maken — bijvoorbeeld staging (tussenomgeving) of benchmark (voor prestatietests). Een aangepast Build Type wordt gedeclareerd in het buildTypes-blok, net als debug en release. De naam kan willekeurig zijn, maar het wordt aanbevolen om semantisch begrijpelijke namen in het Engels te gebruiken. Voor staging wordt meestal debuggable=true (voor diagnose van problemen in de staging-omgeving) en minification=true (om obfuscatie te testen vóór productie) ingesteld.

Een aangepast Build Type krijgt automatisch de bijbehorende source set (src/staging/) en genereert taken zoals assembleStaging. AGP legt geen beperkingen op aan het aantal aangepaste types, maar elk nieuw type vermenigvuldigt het aantal Build Variants. De praktische limiet is 4-5 Build Types: debug, staging, benchmark, release en eventueel debugMinified (debug met ingeschakelde minificatie voor het testen van ProGuard-regels).

Voor een aangepast Build Type kan debuggable worden overgeërfd van debug met behulp van initWith. Het trefwoord initWith kopieert alle parameters van het opgegeven Build Type, waarna ze kunnen worden overschreven. Dit is handig voor het maken van staging op basis van debug: initWith debug + extra minificatie inschakelen. Zonder initWith zou u alle parameters van het basistype handmatig moeten opsommen.

android {
    buildTypes {
        staging {
            initWith debug
            minification true
            shrinkResources true
            proguardFiles "staging-proguard-rules.pro"
            versionNameSuffix "-staging"
        }

        benchmark {
            initWith release
            signingConfig signingConfigs.debug
            matchingFallbacks = ["release"]
        }
    }
}

// matchingFallbacks — voor bibliotheken die geen benchmark-type hebben
// als de bibliotheek alleen release heeft — gebruikt AGP het

Ondertekenconfiguratie voor verschillende buildtypes

SigningConfig bepaalt met welk certificaat APK of AAB wordt ondertekend. Android vereist ondertekening van alle installeerbare applicaties — zonder dit staat het systeem installatie van de APK niet toe. Voor debug-builds gebruikt AGP debug.keystore — een vooraf geïnstalleerd certificaat met een bekend wachtwoord, gegenereerd door Android SDK Tools. Voor release-builds moet u uw eigen certificaat maken via Android Studio (Build → Generate Signed Bundle/APK) of met de opdracht keytool.

Het opslaan van ondertekeningssleutels is een kritiek beveiligingsaspect. Het wordt aanbevolen geen release-sleutels op te slaan in de broncoderepository. In plaats daarvan worden gebruikt: het bestand keystore.properties (toegevoegd aan .gitignore), CI/CD-omgevingsvariabelen of de versleutelde opslag van Android Studio. In CI/CD (GitHub Actions, GitLab CI) worden ondertekeningssleutels opgeslagen in secrets en doorgegeven aan build.gradle via systeemeigenschappen. Voorbeeld: storePassword = System.getenv("KEYSTORE_PASSWORD").

Elk Build Type kan naar zijn eigen signingConfig verwijzen. Voor release — het productiecertificaat, voor debug — debug.keystore, voor staging — een apart staging-certificaat. De ondertekenconfiguratie heeft direct invloed op de mogelijkheid om de applicatie te installeren: als debug is ondertekend met debug.keystore en staging met een productiesleutel, kan staging niet over de debug-versie worden geïnstalleerd vanwege niet-overeenkomende handtekeningen. ApplicationId moet ook verschillend zijn — hiervoor wordt applicationIdSuffix gebruikt.

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
        release {
            storeFile file("release-key.jks")
            storePassword System.getenv("KEYSTORE_PASS")
            keyAlias "my-key"
            keyPassword System.getenv("KEY_PASS")
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Minification, ProGuard en R8

Resource Shrinking

Minification is het proces van het verwijderen van ongebruikte code en het hernoemen van klassen, methoden en velden naar korte namen. AGP voert minificatie uit met ProGuard (verouderd) of R8 (aanbevolen, ingebouwd in AGP sinds versie 3.4). R8 voert vier bewerkingen uit: shrinking (verwijderen van ongebruikte klassen), optimisation (vereenvoudigen van code), obfuscation (hernoemen) en preverify (toevoegen van compatibiliteitsinformatie). Resultaat — een APK met kleinere grootte die moeilijker te decompileren is.

Minificatieregels worden gedefinieerd in ProGuard rules files — tekstbestanden met de syntaxis -keep, -dontwarn, -keepclassmembers. Zonder regels verwijdert of hernoemt R8 klassen die via reflection worden gebruikt (Gson, Retrofit, Room, Kotlin serialization). Het Android Studio projectsjabloon maakt proguard-rules.pro aan, waar regels voor specifieke bibliotheken worden toegevoegd. Bibliotheken kunnen ook ingebouwde regels bevatten — deze worden automatisch uit jar/aar geladen.

Shrink resources (shrinkResources=true) verwijdert ongebruikte bronnen uit de APK. R8 bepaalt eerst welke bronnen niet in de code worden gebruikt (controleert R.java en verwijzingen in het manifest) en verwijdert ze vervolgens uit de definitieve build. Voor bronnen die via getIdentifier() of door bibliotheken van derden worden gebruikt, moet tools:keep="@layout/my_layout" worden toegevoegd aan de bronnen. In combinatie met minificatie kan resource shrinking de APK-grootte met 40-60% verminderen.

# proguard-rules.pro — verplichte regels
# Gson: bewaar klassen voor serialisatie
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: bewaar API-interfaces
-keep,allowobfuscation interface com.example.api.*

# Room: bewaar DAO en Entity
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: voorkom verwijdering van Continuation
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: bewaar service loader
-keep class okhttp3.** { *; }

BuildConfigField en bronnen voor Build Type

BuildConfig is een automatisch gegenereerde Java/Kotlin-klasse die constanten bevat die zijn gedefinieerd in defaultConfig, productFlavors en buildTypes. Via buildConfigField kunnen aangepaste velden worden toegevoegd: buildConfigField "String", "API_URL", '"https://api.example.com"'. BuildConfigField gedeclareerd in buildType is beschikbaar in alle varianten van dit type. Waarden in buildType overschrijven waarden uit productFlavor, die op hun beurt defaultConfig overschrijven.

Voor debug-builds is het handig om API_URL in te stellen op localhost of een staging-server, en voor release — op productie. BuildConfig.FLAVOR en BuildConfig.BUILD_TYPE worden ook automatisch gegenereerd en bevatten de naam van de huidige flavor en build type. In code kan worden gebruikt: if (BuildConfig.DEBUG) { /* logs */ } — de constante DEBUG is alleen true voor debug build type. BuildConfig.DEBUG is een standaard veld dat AGP aan elke BuildConfig toevoegt.

Bronnen voor Build Type worden gedefinieerd via source set src/<buildType>/res/. Bijvoorbeeld, src/debug/res/values/strings.xml kan de tekst “Server: Dev” bevatten, en src/release/res/ — “Server: Prod”. Manifestbronnen worden ook overschreven via source set: src/debug/AndroidManifest.xml kan <uses-permission android:name="android.permission.INTERNET" /> alleen voor debug-builds bevatten. Dit is schoner dan BuildConfig-controle in code en werkt zelfs voor attributen die niet programmatisch kunnen worden ingesteld (bijvoorbeeld networkSecurityConfig).

// src/debug/kotlin/.../DebugConfig.kt
object DebugConfig {
    val apiUrl = "http://localhost:8080/api"
    val enableLogging = true
    val enableCrashReporting = false
}

// src/release/kotlin/.../ReleaseConfig.kt
object ReleaseConfig {
    val apiUrl = "https://api.production.com/v2"
    val enableLogging = false
    val enableCrashReporting = true
}

// Gebruik: hoofdklasse laadt Config via reflection
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}