Kotlin-Build-Abhängigkeiten

Kotlin-Build-Abhängigkeiten sind der Teil deines Android-Projekts, der festlegt, welche Kotlin-Version, welche Gradle-Plugins und welche Libraries beim Bauen, Testen und Ausführen verwendet werden. Wenn du verstehst, wie diese Bausteine in dein Projekt gelangen, kannst du Fehler schneller einordnen, Updates kontrollierter durchführen und Builds in Android Studio sowie in der Continuous Integration stabil halten.

Was ist das?

Kotlin-Build-Abhängigkeiten sind alle externen Bausteine, die dein Projekt über Gradle einbindet, damit Kotlin-Code kompiliert, geprüft, getestet und als Android-App verpackt werden kann. Dazu gehören vor allem Libraries und Plugins. Eine Library ist Code, den du in deiner App direkt verwendest, zum Beispiel eine Jetpack-Bibliothek, Kotlin Coroutines, ein Test-Framework oder Compose-Komponenten. Ein Plugin erweitert dagegen den Build-Prozess. Es sagt Gradle etwa, dass ein Modul ein Android-App-Modul ist, dass Kotlin-Quellcode kompiliert werden soll oder dass ein Kotlin-Compiler-Plugin aktiv sein muss.

Das mentale Modell ist wichtig: Libraries landen in deinem Klassenpfad und werden von deinem App- oder Testcode genutzt. Plugins verändern, wie Gradle dein Projekt verarbeitet. Wenn du diese beiden Gruppen vermischst, entstehen schnell falsche Erwartungen. Eine Dependency in implementation macht keine neue Gradle-Aufgabe verfügbar. Ein Plugin in plugins kannst du nicht wie eine Klasse importieren.

In modernen Android-Projekten ist dieses Thema jeden Tag sichtbar. Du nutzt Kotlin als Hauptsprache, Jetpack-Bibliotheken für Architektur und UI, Compose für deklarative Oberflächen, JUnit oder AndroidX Test für Tests und oft zusätzliche Tools für Codequalität. All das wird nicht manuell in Android Studio zusammengeklickt, sondern in Gradle-Dateien beschrieben. Dadurch kann dein Projekt auf verschiedenen Maschinen gleich gebaut werden: lokal, im Team und auf dem CI-Server.

Kotlin-Build-Abhängigkeiten sind deshalb kein Nebenthema. Sie entscheiden mit darüber, ob dein Projekt zuverlässig startet, ob Tests laufen, ob Compose richtig kompiliert wird und ob ein Update nur eine kleine Änderung oder ein längerer Fehlersuchlauf wird.

Wie funktioniert es?

Gradle liest dein Projekt in mehreren Schritten. Zuerst werden Einstellungen wie Repositories und Version Catalogs ausgewertet. Danach lädt Gradle die Plugins für die Module. Anschließend werden die Abhängigkeiten der einzelnen Module aufgelöst und die passenden Tasks erzeugt, zum Beispiel für Kompilierung, Tests, Lint oder Packaging.

Ein Android-Projekt hat meist mehrere relevante Dateien. In settings.gradle.kts legst du oft fest, aus welchen Repositories Plugins und Libraries geladen werden dürfen, zum Beispiel google() und mavenCentral(). In build.gradle.kts auf Projektebene oder in einem Version Catalog wie libs.versions.toml verwaltest du Versionen zentral. In den Moduldateien, etwa app/build.gradle.kts, wendest du Plugins an und deklarierst konkrete Abhängigkeiten.

Bei Kotlin sind zwei Arten von Plugins besonders wichtig. Das Kotlin-Android-Plugin verbindet Kotlin mit dem Android-Gradle-Plugin, damit Kotlin-Code im Android-Modul korrekt kompiliert wird. Compiler-Plugins greifen tiefer ein. Sie erweitern oder verändern die Kotlin-Kompilierung. Compose nutzt zum Beispiel einen eigenen Compiler-Anteil, damit Composable-Funktionen übersetzt werden können. Auch andere Kotlin-Werkzeuge können über Plugins eingebunden werden.

Die wichtigsten Dependency-Konfigurationen solltest du sauber unterscheiden. implementation ist die Standardwahl für Produktionscode, wenn die Library intern im Modul genutzt wird. api wird eher in Library-Modulen relevant, wenn eine Abhängigkeit Teil der öffentlichen Modul-API ist. testImplementation gilt für lokale Unit-Tests auf der JVM. androidTestImplementation gilt für instrumentierte Tests, die auf Gerät oder Emulator laufen. debugImplementation wird nur im Debug-Build genutzt.

Diese Scopes sind nicht nur Ordnung. Sie beeinflussen Build-Zeit, Sichtbarkeit und Testbarkeit. Wenn du eine Test-Library versehentlich mit implementation einbindest, kann sie im Produktionsklassenpfad landen. Wenn du eine Library, die dein öffentliches API prägt, fälschlich nur mit implementation einbindest, kann ein anderes Modul beim Kompilieren scheitern. Bei größeren Projekten werden solche Details schnell teuer.

Versionen sind der zweite Kernpunkt. Kotlin, Android Gradle Plugin, Compose Compiler, Compose Libraries und Jetpack-Bibliotheken müssen zueinander passen. Nicht jede neue Version kann beliebig mit jeder anderen kombiniert werden. Deshalb solltest du Updates bewusst und in kleinen Schritten machen. In professionellen Projekten prüfst du nach einem Update nicht nur, ob die App startet, sondern auch, ob Unit-Tests, instrumentierte Tests, Lint und CI weiterlaufen.

In der Praxis

Ein typisches App-Modul mit Kotlin, Android, Compose und Tests kann so aussehen. Das Beispiel nutzt Kotlin DSL und einen Version Catalog. Die genauen Versionen stehen dann zentral in gradle/libs.versions.toml.

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.kotlin.compose)
}

android {
    namespace = "de.android_coden.beispiel"
    compileSdk = 35

    defaultConfig {
        applicationId = "de.android_coden.beispiel"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"

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

    buildFeatures {
        compose = true
    }
}

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.lifecycle.runtime.ktx)
    implementation(libs.androidx.activity.compose)
    implementation(platform(libs.androidx.compose.bom))
    implementation(libs.androidx.compose.ui)
    implementation(libs.androidx.compose.material3)

    testImplementation(libs.junit)

    androidTestImplementation(libs.androidx.junit)
    androidTestImplementation(libs.androidx.espresso.core)
    androidTestImplementation(platform(libs.androidx.compose.bom))
    androidTestImplementation(libs.androidx.compose.ui.test.junit4)

    debugImplementation(libs.androidx.compose.ui.tooling)
    debugImplementation(libs.androidx.compose.ui.test.manifest)
}

Hier siehst du die Trennung klar. Die Plugins oben aktivieren Fähigkeiten des Moduls: Android-App, Kotlin für Android und Compose-Kompilierung. Die Dependencies unten liefern Code für die App, für lokale Tests, für instrumentierte Tests und für Debug-Werkzeuge.

Eine sinnvolle Entscheidungsregel lautet: Frage zuerst, wer die Abhängigkeit braucht. Braucht dein Produktionscode sie, verwende meistens implementation. Brauchen nur JVM-Unit-Tests sie, verwende testImplementation. Brauchen nur Emulator- oder Gerätetests sie, verwende androidTestImplementation. Brauchst du sie nur für Debugging, Vorschau oder Test-Hilfsdateien im Debug-Build, verwende debugImplementation.

Eine zweite Regel betrifft Plugins: Wende ein Plugin nur in den Modulen an, die es wirklich brauchen. Ein reines Kotlin-Library-Modul braucht kein Android-App-Plugin. Ein Modul ohne Compose braucht kein Compose-Compiler-Plugin. Zu viele Plugins machen den Build schwerer zu verstehen und können Konfigurationszeit kosten.

Typische Stolperfallen

Eine häufige Stolperfalle ist das Kopieren von Gradle-Zeilen ohne Kontext. Du findest online ein Beispiel, fügst mehrere Dependencies ein, und der Build läuft zunächst. Später tauchen aber doppelte Versionen, veraltete Artefakte oder falsche Test-Scopes auf. Besonders bei Compose kann eine Mischung aus BOM, direkten Versionsnummern und alten Compiler-Einstellungen unübersichtlich werden. Nutze entweder bewusst die Compose BOM für passende Library-Versionen oder dokumentiere klar, warum du eine Version direkt setzt.

Ein weiterer Fehler ist, Build-Fehler nur als Android-Studio-Problem zu behandeln. Wenn Unresolved reference, Duplicate class, No matching variant oder ein Kotlin-Compiler-Fehler erscheint, liegt die Ursache oft in der Dependency-Auflösung. Öffne dann nicht wahllos Dateien, sondern prüfe gezielt: Ist das Repository vorhanden? Ist das Plugin im richtigen Modul aktiv? Passt der Scope? Gibt es zwei Versionen derselben Library? Läuft der Fehler lokal und in CI gleich?

Für den Alltag ist auch wichtig, dass Tests eigene Abhängigkeiten haben. Androids Testing-Grundlagen unterscheiden lokale Tests und instrumentierte Tests nicht aus Formalität, sondern weil sie in verschiedenen Laufzeitumgebungen ausgeführt werden. Ein lokaler Unit-Test läuft auf der JVM deines Rechners. Ein instrumentierter Test läuft mit Android-Laufzeit auf Gerät oder Emulator. Entsprechend gehören die Libraries in unterschiedliche Gradle-Konfigurationen.

Prüfe dein Verständnis praktisch, indem du eine kleine Dependency bewusst einbindest und entfernst. Füge zum Beispiel eine Test-Library nur mit testImplementation hinzu, schreibe einen lokalen Test und beobachte, dass Produktionscode diese Library nicht importieren sollte. Danach verschiebe testweise eine Android-Test-Library in den falschen Scope und lies die Fehlermeldung aufmerksam. Diese Übung klingt unscheinbar, schärft aber dein Gefühl für Klassenpfade und Build-Phasen.

In Code-Reviews solltest du Dependency-Änderungen ernst nehmen. Frage bei jeder neuen Library: Wird sie wirklich gebraucht? Ist der Scope eng genug? Ist die Version zentral gepflegt? Gibt es eine kleinere Alternative im bestehenden Stack? Sind Tests oder CI-Anpassungen nötig? Diese Fragen schützen dein Projekt vor schleichender Komplexität.

Fazit

Kotlin-Build-Abhängigkeiten zeigen dir, wie Kotlin-Libraries und Compiler-Plugins kontrolliert in ein Android-Projekt kommen. Wenn du Libraries, Plugins, Scopes und Versionen sauber unterscheidest, verstehst du viele Build-Fehler deutlich schneller und kannst Projektänderungen sicherer prüfen. Nimm dir ein bestehendes Modul, ordne jede Dependency einem Zweck zu und kontrolliere danach mit Tests oder CI, ob deine Annahmen stimmen. So wird Gradle von einer undurchsichtigen Datei zu einem Werkzeug, das du bewusst einsetzt.