Abhängigkeiten zwischen Tools und Bibliotheken

Build-Abhängigkeiten sind externe Komponenten, die für die erfolgreiche Erstellung Ihres Projekts erforderlich sind. Ein Build kann von Bibliotheken, Plug-ins, Unterprojekten, dem Android SDK, Tools wie Kotlin- und Java-Compilern, Entwicklungsumgebungen wie Android Studio und Gradle selbst abhängen.

Jede Abhängigkeit kann selbst andere Abhängigkeiten erfordern. Diese werden als transitive Abhängigkeiten bezeichnet. Sie können die von Ihrer Anwendung verwendeten Gesamtabhängigkeiten schnell erhöhen. Wenn Sie eine Abhängigkeit aktualisieren möchten, unabhängig davon, ob es sich um eine Bibliothek, ein Tool oder das Android SDK handelt, kann dieses Upgrade kaskadiert werden, wodurch viele andere Abhängigkeiten aktualisiert werden.

Oft ist das kein Problem, da viele Bibliotheken dem semantischen Versionierungsschema folgen. Diese Bibliotheken beschränken die Arten von Änderungen, die sie vornehmen, um für die Kompatibilität mit niedrigeren Versionen zu sorgen.

Die semantische Versionsverwaltung folgt dem Format major.minor.patch. In der Versionsnummer 4.8.3 steht 4 beispielsweise für die major-Version, 8 für die minor-Version und 3 für die patch-Nummer. Wenn sich der major-Teil ändert, kann dies zu wichtigen Änderungen der API oder des Verhaltens der Bibliothek führen. Dies kann sich auf das Build- oder Anwendungsverhalten auswirken.

Wenn sich die Teile minor (neue Funktionen) oder patch (Fehlerkorrekturen) ändern, teilt Ihnen der Entwickler der Bibliothek mit, dass die Bibliothek weiterhin kompatibel ist und keine Auswirkungen auf Ihre Anwendung haben sollte.

Es ist wichtig, auf solche Änderungen zu achten. Mehrere Tools für das Abhängigkeitsupgrade können Ihnen dabei helfen.

Beziehungen in Ihrem Build

Android-Builds enthalten Beziehungen zwischen:

• Quellcode: Code und Ressourcen, über die Sie die Kontrolle haben
• Bibliotheksabhängigkeiten: Externe Bibliotheken oder Module, die beim Erstellen in Ihr Projekt und Ihre untergeordneten Projekte aufgenommen werden
• Tools: Compiler, Plug-ins und SDKs, die Ihre Quelle in eine Anwendung oder Bibliothek umwandeln

Quellcode

Ihr Quellcode ist Kotlin- oder Java-Code, den Sie in Ihre Anwendung oder Bibliothek schreiben. Weitere Informationen zur Verwendung von C++ finden Sie unter Android NDK.

Der Quellcode ist von Bibliotheken (einschließlich Kotlin- und Java-Laufzeitbibliotheken) und dem Android SDK abhängig und erfordert den entsprechenden Kotlin- oder Java-Compiler.

Einige Quellcodes enthalten Annotationen, die zusätzlich verarbeitet werden müssen. Wenn Sie beispielsweise Jetpack Compose-Code schreiben, fügen Sie Anmerkungen wie @Composable hinzu, die vom Compose Kotlin-Compiler-Plug-in verarbeitet werden müssen. Andere Anmerkungen können von einem Kotlin Symbol Processor (KSP) oder separaten Annotationsverarbeitungstools verarbeitet werden.

Bibliotheksabhängigkeiten

Bibliotheken enthalten Bytecode, der als Teil Ihrer Anwendung abgerufen wurde. Dies kann eine Java-JAR-Datei, eine Android-Bibliothek (AAR) oder ein Unterprojekt in Ihrem Build sein. Viele Bibliotheken folgen der semantischen Versionsverwaltung. So können Sie besser nachvollziehen, ob sie nach einem Upgrade weiterhin kompatibel sind oder nicht.

Bibliotheken können zur Wiederverwendung von anderen Bibliotheken abhängig sein, was als transitive Abhängigkeit bezeichnet wird. Dadurch werden die Abhängigkeiten reduziert, die Sie explizit verwalten müssen. Sie geben die Abhängigkeiten an, die Sie direkt verwenden, und Gradle ruft sie zusammen mit diesen transitiven Abhängigkeiten ab. Beachten Sie, dass beim Upgrade Ihrer direkten Abhängigkeiten auch diese vorübergehenden Abhängigkeiten aktualisiert werden können.

Manchmal sind für eine Bibliothek zur Laufzeit (minSdk) oder Kompilierungszeit (compileSdk) Mindestversionen des Android SDK erforderlich. Dies ist erforderlich, wenn eine Bibliothek Funktionen verwendet, die im Android SDK oder in den bereitgestellten JDK APIs enthalten sind. Die effektive minSdk Ihrer Anwendung ist die höchste minSdk, die von Ihrer Anwendung und allen direkten und transitiven Bibliotheksabhängigkeiten angefordert wird.

Für die Verwendung einiger Bibliotheken ist möglicherweise ein bestimmtes Gradle-Plug-in erforderlich. Diese Hilfs-Plug-ins installieren häufig Kotlin-Symbolprozessoren oder andere Anmerkungs-Prozessoren, die Code generieren oder die Kompilierung Ihrer Quelle ändern, um die Verwendung von Bibliotheksfunktionen zu unterstützen. Jetpack Room enthält beispielsweise Annotationen und einen KSP, der sie in generierten Code umwandelt, um Daten in einer Datenbank abzurufen und zu ändern. Für Jetpack Compose muss das Compiler-Plug-in annotierte Funktionen ändern, um zu verwalten, wie und wann diese Funktion noch einmal ausgeführt wird.

Tools

Gradle-Bereiche

Gradle gruppiert Bibliotheksabhängigkeiten in verschiedene Bereiche (in der Gradle API als Konfigurationen bezeichnet), sodass Sie unterschiedliche Gruppen von Bibliotheksabhängigkeiten angeben können, die in verschiedenen Teilen Ihres Builds verwendet werden. Wahrscheinlich möchten Sie beispielsweise keine Testbibliotheken wie JUnit in Ihre veröffentlichte Anwendung oder Bibliothek aufnehmen, aber beim Erstellen und Ausführen Ihrer Einheitentests. Sie verwenden Bereiche auch, um Symbol- oder Annotationsprozessoren hinzuzufügen und Ihren Code zu analysieren.

AGP definiert beispielsweise die Bereiche implementation und api, mit denen Sie festlegen, ob eine Abhängigkeit Nutzern Ihres Unterprojekts zugänglich gemacht werden soll. Beschreibungen dieser und anderer Bereiche, die in einem Android-Build verwendet werden, finden Sie unter Abhängigkeiten konfigurieren.

Fügen Sie im Block dependencies der Build-Dateien Bibliotheksabhängigkeiten als group:artifact:version-Strings hinzu:

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

oder in einem Versionskatalog:

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

und geben Sie die generierten Variablen in Ihren Build-Dateien an:

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}