Gradle und Build-Varianten

Wenn du eine Android-App entwickelst, schreibst du nicht nur Kotlin-Code und Compose-UIs. Du musst auch festlegen, wie daraus eine installierbare App entsteht: eine Debug-Version für dich, eine Release-Version für den Play Store und oft Varianten für unterschiedliche Server, Marken oder Produktstufen. Genau dabei helfen Gradle und Build-Varianten.

Was ist das?

Gradle ist das Build-System, das Android Studio für Android-Projekte verwendet. Es liest deine Build-Dateien, löst Abhängigkeiten auf, kompiliert Kotlin und Ressourcen, führt Tests aus und erzeugt am Ende Artefakte wie APKs oder Android App Bundles. Du beschreibst also nicht jeden Build-Schritt manuell, sondern formulierst Regeln: Welche Plugins gelten? Welche SDK-Version wird verwendet? Welche Bibliotheken braucht die App? Wie soll eine Release-Version signiert und optimiert werden?

Build-Varianten sind die konkreten Kombinationen, die aus diesen Regeln entstehen. In einem einfachen Projekt gibt es meist mindestens debug und release. debug ist für Entwicklung gedacht: debuggable, oft mit Zusatzlogs, anderer App-ID und ohne starke Optimierung. release ist für Auslieferung gedacht: signiert, optimiert, ohne Entwicklungsfunktionen und passend für den Play Store vorbereitet.

Dazu kommen Product Flavors. Ein Flavor beschreibt eine fachliche oder technische Variante deiner App, etwa dev, staging und prod für verschiedene Backend-Umgebungen oder free und paid für Produktstufen. Gradle kombiniert Build Types und Flavors. Aus dev plus debug wird zum Beispiel devDebug, aus prod plus release wird prodRelease.

Das mentale Modell ist wichtig: Ein Android-Projekt ist nicht nur eine App, sondern eine Vorlage für mehrere App-Artefakte. Jede Variante kann eigene Konstanten, Ressourcen, Abhängigkeiten, Manifest-Einträge und Quellcodedateien haben. Moderne Android-Entwicklung mit Kotlin, Jetpack Compose, Architekturkomponenten, Tests und CI baut darauf auf. Du willst dieselbe Codebasis nutzen, aber kontrolliert verschiedene Ergebnisse erzeugen.

Wie funktioniert es?

Die zentrale Konfiguration liegt in der Regel in build.gradle.kts deines App-Moduls. Dort aktivierst du das Android-Plugin, setzt namespace, compileSdk, defaultConfig, buildTypes und optional productFlavors. Gradle erzeugt daraus automatisch Tasks. Für eine Variante wie stagingDebug gibt es dann Aufgaben zum Kompilieren, Testen, Paketieren und Installieren.

Build Types beschreiben typisches Build-Verhalten. debug ist oft automatisch vorhanden. release konfigurierst du bewusst: Minification mit R8, Ressourcen-Shrinking, ProGuard-Regeln, Signing und Debug-Schalter. Dabei geht es nicht nur um Performance, sondern auch um Qualität und Sicherheit. Eine Release-App sollte keine Debug-Endpunkte, Testdaten oder internen Logs enthalten.

Flavors beschreiben Unterschiede, die nicht nur aus Debug oder Release entstehen. Ein häufiger Fall sind Backend-Umgebungen. Deine App spricht im Alltag vielleicht mit einer Entwicklungs-API, vor dem Release mit einer Staging-API und im Store mit der Produktions-API. Diese URLs gehören nicht hart in ViewModels oder Repository-Klassen. Du legst sie besser als buildConfigField, Ressource oder über Dependency Injection fest, damit die Variante entscheidet und nicht verstreuter Fachcode.

Gradle kennt außerdem Source Sets. Neben src/main kannst du Ordner wie src/debug, src/release, src/staging oder src/stagingDebug verwenden. Dateien in spezifischeren Source Sets überschreiben oder ergänzen allgemeine Dateien. Das ist nützlich für Ressourcen, Icons, Manifest-Platzhalter oder kleine Implementierungen. Du solltest es aber sparsam einsetzen, denn zu viele variantenspezifische Dateien machen Code-Reviews schwerer.

Im Alltag siehst du Build-Varianten direkt in Android Studio im Build-Variants-Fenster. Dort wählst du aus, welche Variante gerade gebaut, gestartet und getestet wird. In der CI passiert dasselbe über Gradle-Tasks wie ./gradlew testDevDebugUnitTest, ./gradlew connectedStagingDebugAndroidTest oder ./gradlew bundleProdRelease. Damit wird aus lokaler Entwicklung ein reproduzierbarer Prozess.

Tests hängen eng damit zusammen. Unit-Tests und instrumentierte Tests laufen gegen eine konkrete Variante. Wenn dein debug-Build eine andere API-URL, andere Feature Flags oder zusätzliche Test-Abhängigkeiten nutzt, prüfst du nicht automatisch das Release-Verhalten. Gute Android-Qualität entsteht daher nicht nur durch Tests, sondern durch Tests gegen die richtige Variante und durch klare Regeln in der Pipeline.

In der Praxis

Ein kompaktes Beispiel zeigt die Grundidee. Angenommen, du hast drei Umgebungen und willst verhindern, dass eine lokale Debug-App dieselbe App-ID wie die Store-App nutzt. Dann kann deine Modulkonfiguration so aussehen:

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "de.androidcoden.demo"
    compileSdk = 35

    defaultConfig {
        applicationId = "de.androidcoden.demo"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"
    }

    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
            versionNameSuffix = "-debug"
            isDebuggable = true
        }

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

    flavorDimensions += "environment"

    productFlavors {
        create("dev") {
            dimension = "environment"
            applicationIdSuffix = ".dev"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://dev.api.example.com\""
            )
        }

        create("staging") {
            dimension = "environment"
            applicationIdSuffix = ".staging"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://staging.api.example.com\""
            )
        }

        create("prod") {
            dimension = "environment"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.example.com\""
            )
        }
    }
}

Im Kotlin-Code kannst du die Konstante dann an einer zentralen Stelle verwenden, zum Beispiel beim Aufbau deines Netzwerkmoduls:

object ApiConfig {
    val baseUrl: String = BuildConfig.BASE_URL
}

Wichtig ist nicht die konkrete URL, sondern die Regel dahinter: Konfigurationsunterschiede gehören in die Build-Konfiguration oder in klar angebundene Konfigurationsklassen, nicht quer verteilt in UI, ViewModel und Repository. Eine Compose-Oberfläche sollte nicht wissen müssen, ob sie gerade in devDebug oder prodRelease läuft. Diese Entscheidung liegt unterhalb der UI-Schicht.

Eine typische Stolperfalle ist die Verwechslung von Build Type und Flavor. debug und release beschreiben, wie gebaut wird. dev, staging und prod beschreiben, wofür gebaut wird. Wenn du diese Ebenen vermischst, entstehen seltsame Varianten wie debugProd-Logik im Fachcode oder Release-Builds, die noch auf Testserver zeigen. Halte die Begriffe sauber getrennt.

Eine zweite Stolperfalle betrifft Secrets. API-Schlüssel, Signing-Daten und Tokens gehören nicht ungeschützt in dein Repository. Gradle kann Werte aus lokalen Properties, Umgebungsvariablen oder CI-Secrets lesen. Für Lernprojekte wirkt das anfangs übertrieben, aber spätestens vor dem Release ist es relevant. Der Play-Store-Prozess erwartet reproduzierbare, signierte und korrekt vorbereitete Artefakte. Wenn Signing nur auf deinem lokalen Rechner funktioniert, ist dein Release-Prozess fragil.

Auch die Anzahl der Varianten braucht Disziplin. Jede Flavor-Dimension multipliziert die möglichen Builds. Zwei Build Types, drei Umgebungen und zwei Produktstufen ergeben bereits zwölf Varianten. Das kann sinnvoll sein, kostet aber Zeit in CI, Testausführung und Pflege. Eine gute Entscheidungsregel lautet: Erstelle einen Flavor nur, wenn daraus wirklich ein anderes Artefakt entstehen muss. Für reine Laufzeit-Schalter reichen oft Remote Config, lokale Einstellungen oder Dependency Injection.

Prüfe dein Verständnis praktisch. Wähle in Android Studio verschiedene Build-Varianten aus und kontrolliere BuildConfig.BASE_URL, App-ID, App-Name und Icon. Baue lokal ein prodRelease-Bundle und ein devDebug-APK. Starte Unit-Tests für eine konkrete Variante und schau dir die erzeugten Gradle-Tasks an. In einem Code-Review solltest du fragen: Ist klar, welche Variante veröffentlicht wird? Sind Debug-Funktionen im Release ausgeschlossen? Laufen Tests gegen die Variante, die für Qualität und Auslieferung zählt?

Fazit

Gradle und Build-Varianten geben dir Kontrolle über den Weg vom Android-Projekt zum installierbaren Artefakt. Wenn du Build Types für technisches Build-Verhalten und Flavors für fachliche oder umgebungsbezogene Unterschiede nutzt, bleibt deine Codebasis sauberer und dein Release-Prozess nachvollziehbarer. Übe das Thema nicht nur durch Lesen: Baue mehrere Varianten, prüfe ihre App-IDs und Konfigurationen, führe variantenspezifische Tests aus und achte im Code-Review gezielt darauf, ob Debug-, Staging- und Release-Verhalten sauber getrennt sind.