Mit dem Gradle-Build-System in Android Studio können Sie externe Binärdateien oder andere Bibliotheksmodule als Abhängigkeiten in Ihren Build einbinden. Die Abhängigkeiten können sich auf Ihrem Computer oder in einem Remote-Repository befinden. Alle von ihnen deklarierten vorübergehenden Abhängigkeiten sind ebenfalls automatisch eingeschlossen. Auf dieser Seite wird beschrieben, wie Sie Abhängigkeiten mit Ihrem Android-Projekt verwenden, einschließlich Details zu Verhaltensweisen und Konfigurationen, die für das Android Gradle-Plug-in (AGP) spezifisch sind. Eine ausführlichere konzeptionelle Anleitung zu Gradle-Abhängigkeiten finden Sie im Gradle-Leitfaden für die Abhängigkeitsverwaltung. Denken Sie jedoch daran, dass für Ihr Android-Projekt nur die auf dieser Seite definierten Abhängigkeitskonfigurationen verwendet werden dürfen.
Bibliothek oder Plug-in-Abhängigkeit hinzufügen
Die beste Methode zum Hinzufügen und Verwalten von Build-Abhängigkeiten ist die Verwendung von Versionskatalogen. Diese Methode wird von neuen Projekten standardmäßig verwendet. In diesem Abschnitt werden die gängigsten Konfigurationstypen für Android-Projekte beschrieben. Weitere Optionen finden Sie in der Gradle-Dokumentation. Ein Beispiel für eine App, die Versionskataloge verwendet, findest du unter Now in Android. Wenn Sie bereits Build-Abhängigkeiten ohne Versionskataloge eingerichtet und ein Projekt mit mehreren Modulen haben, empfehlen wir die Migration.
Eine Anleitung zum Hinzufügen und Verwalten nativer Abhängigkeiten (nicht üblich) finden Sie unter Native Abhängigkeiten.
Im folgenden Beispiel fügen wir dem Projekt eine Remote-Binärabhängigkeit (die Jetpack-MacroBenchmark-Bibliothek), eine lokale Bibliotheksmodulabhängigkeit (myLibrary
) und eine Plug-in-Abhängigkeit (das Android-Gradle-Plug-in) hinzu. So fügen Sie Ihrem Projekt diese Abhängigkeiten hinzu:
Fügen Sie im Abschnitt
[versions]
der Versionskatalogdatei einen Alias für die gewünschte Version der Abhängigkeit mit dem Namenlibs.versions.toml
hinzu (im Verzeichnisgradle
in der Projektansicht oder im Gradle-Skript-Ansicht in der Android-Ansicht im Verzeichnisgradle
):[versions] agp = "8.3.0" androidx-macro-benchmark = "1.2.2" my-library = "1.4" [libraries] ... [plugins] ...
Aliasse können Bindestriche oder Unterstriche enthalten. Diese Aliasse generieren verschachtelte Werte, auf die Sie in Build-Skripts verweisen können. Die Verweise beginnen mit dem Namen des Katalogs, dem Teil
libs
vonlibs.versions.toml
. Wenn Sie einen Katalog mit einer einzelnen Version verwenden, empfehlen wir, den Standardwert „libs“ beizubehalten.Fügen Sie einen Alias für die Abhängigkeit in den Abschnitten
[libraries]
(für Remote-Binärdateien oder lokale Bibliotheksmodule) oder[plugins]
(für Plug-ins) der Dateilibs.versions.toml
hinzu.[versions] ... [libraries] androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" } my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" } [plugins] androidApplication = { id = "com.android.application", version.ref = "agp" }
Einige Bibliotheken sind in einer veröffentlichten Stückliste (BOM) verfügbar, in der Bibliothekenfamilien und ihre Versionen zusammengefasst sind. Sie können eine BOM in Ihren Versionskatalog aufnehmen, Dateien erstellen und diese Versionen dann von dieser für Sie verwalten lassen. Weitere Informationen finden Sie unter Verwenden der Materialliste.
Fügen Sie dem Build-Skript der Module, die die Abhängigkeit benötigen, einen Verweis auf den Abhängigkeitsalias hinzu. Konvertieren Sie die Unterstriche und Bindestriche des Alias in Punkte, wenn Sie in einem Build-Skript darauf verweisen. Unser Build-Skript auf Modulebene würde so aussehen:
Kotlin
plugins { alias(libs.plugins.androidApplication) } dependencies { implementation(libs.androidx.benchmark.macro) implementation(libs.my.library) }
Groovig
plugins { alias 'libs.plugins.androidApplication' } dependencies { implementation libs.androidx.benchmark.macro implementation libs.my.library }
Plug-in-Verweise enthalten
plugins
nach dem Katalognamen und Versionsreferenzen enthaltenversions
nach dem Katalognamen. Versionsverweise sind selten. Beispiele für Versionsverweise finden Sie unter Abhängigkeiten mit gleichen Versionsnummern. Bibliotheksreferenzen enthalten keinenlibraries
-Qualifier. Daher können Sie am Anfang eines Bibliotheksalias nichtversions
oderplugins
verwenden.
Abhängigkeiten konfigurieren
Innerhalb des dependencies
-Blocks können Sie eine Bibliotheksabhängigkeit mit einer von mehreren verschiedenen Abhängigkeitskonfigurationen (z. B. implementation
wie oben gezeigt) deklarieren. Jede Abhängigkeitskonfiguration liefert Gradle unterschiedliche Anweisungen zur Verwendung der Abhängigkeit. In der folgenden Tabelle werden alle Konfigurationen beschrieben, die Sie für eine Abhängigkeit in Ihrem Android-Projekt verwenden können.
Konfiguration | Verhalten |
---|---|
implementation |
Gradle fügt die Abhängigkeit dem Kompilierungsklassenpfad hinzu und verpackt sie in die Build-Ausgabe. Wenn Ihr Modul eine implementation -Abhängigkeit konfiguriert, wird Gradle mitgeteilt, dass das Modul die Abhängigkeit bei der Kompilierung nicht an andere Module weitergeben soll. Das heißt, die Abhängigkeit wird nicht anderen Modulen zur Verfügung gestellt, die vom aktuellen Modul abhängen.
Die Verwendung dieser Abhängigkeitskonfiguration anstelle von |
api |
Gradle fügt die Abhängigkeit dem Kompilierungsklassenpfad und der Build-Ausgabe hinzu. Enthält ein Modul eine api -Abhängigkeit, wird Gradle mitgeteilt, dass das Modul diese Abhängigkeit vorübergehend in andere Module exportieren möchte, damit es sowohl zur Laufzeit als auch zur Kompilierung verfügbar ist.
Verwenden Sie diese Konfiguration mit Vorsicht und nur mit Abhängigkeiten, die vorübergehend zu anderen Upstream-Nutzern exportiert werden müssen. Wenn eine |
compileOnly |
Gradle fügt die Abhängigkeit nur dem Kompilierungsklassenpfad hinzu, d. h., sie wird nicht der Build-Ausgabe hinzugefügt. Dies ist nützlich, wenn Sie ein Android-Modul erstellen und die Abhängigkeit während der Kompilierung benötigen. Es ist jedoch optional, sie während der Laufzeit vorhanden zu haben. Wenn Sie beispielsweise auf eine Bibliothek angewiesen sind, die nur Annotationen zur Kompilierungszeit enthält – die normalerweise zum Generieren von Code verwendet wird, aber oft nicht in der Build-Ausgabe enthalten ist –, können Sie diese Bibliothek als compileOnly markieren.
Wenn Sie diese Konfiguration verwenden, muss das Bibliotheksmodul eine Laufzeitbedingung enthalten, mit der geprüft wird, ob die Abhängigkeit verfügbar ist. Anschließend muss sein Verhalten ordnungsgemäß geändert werden, damit es auch funktioniert, wenn sie nicht angegeben wird. Dies trägt dazu bei, die Größe der endgültigen Anwendung zu reduzieren, da keine vorübergehenden Abhängigkeiten hinzugefügt werden, die nicht kritische sind.
Hinweis:Die |
runtimeOnly |
Gradle fügt die Abhängigkeit nur der Build-Ausgabe hinzu, um sie während der Laufzeit zu verwenden. Das heißt, er wird dem Compile-Klassenpfad nicht hinzugefügt.
Dies wird unter Android selten verwendet, aber häufig in Serveranwendungen zur Bereitstellung von Logging-Implementierungen. Eine Bibliothek kann beispielsweise eine Logging API ohne Implementierung verwenden. Nutzer dieser Bibliothek könnten sie als implementation -Abhängigkeit und als runtimeOnly -Abhängigkeit für die tatsächliche Logging-Implementierung hinzufügen.
|
ksp |
Diese Konfigurationen stellen Bibliotheken zur Verfügung, die Annotationen und andere Symbole in Ihrem Code verarbeiten, bevor dieser kompiliert wird. Sie validieren in der Regel Ihren Code oder generieren zusätzlichen Code, sodass Sie weniger Code schreiben müssen. Wenn Sie eine solche Abhängigkeit hinzufügen möchten, müssen Sie sie mithilfe der Konfigurationen Im Android-Gradle-Plug-in wird davon ausgegangen, dass eine Abhängigkeit ein Annotationsprozessor ist, wenn die JAR-Datei die folgende Datei enthält:
Wenn das Plug-in einen Annotationsprozessor erkennt, der sich im Kompilierungsklassenpfad befindet, wird ein Build-Fehler ausgelöst.
Berücksichtigen Sie bei der Entscheidung, welche Konfiguration Sie verwenden möchten:
Weitere Informationen zur Verwendung von Annotationsprozessoren finden Sie unter Annotationsprozessoren hinzufügen. |
lintChecks |
Verwenden Sie diese Konfiguration, um eine Bibliothek mit Lint-Prüfungen hinzuzufügen, die Gradle beim Erstellen Ihres Android-App-Projekts ausführen soll. AAE, die eine |
lintPublish |
Verwenden Sie diese Konfiguration in Android-Bibliotheksprojekten, um Lint-Prüfungen einzufügen, die Gradle in eine lint.jar -Datei und ein Paket in Ihrem AAR kompilieren soll. Dies führt dazu, dass auch Projekte, die AAE nutzen, diese Lint-Prüfungen anwenden. Wenn Sie zuvor die Abhängigkeitskonfiguration lintChecks verwendet haben, um Lint-Prüfungen in das veröffentlichte AAE aufzunehmen, müssen Sie diese Abhängigkeiten migrieren, um stattdessen die Konfiguration lintPublish zu verwenden.
Kotlindependencies { // Executes lint checks from the ":checks" project at build time. lintChecks(project(":checks")) // Compiles lint checks from the ":checks-to-publish" into a // lint.jar file and publishes it to your Android library. lintPublish(project(":checks-to-publish")) } Groovigdependencies { // Executes lint checks from the ':checks' project at build time. lintChecks project(':checks') // Compiles lint checks from the ':checks-to-publish' into a // lint.jar file and publishes it to your Android library. lintPublish project(':checks-to-publish') } |
Abhängigkeiten für eine bestimmte Build-Variante konfigurieren
Bei allen vorherigen Konfigurationen werden Abhängigkeiten auf alle Build-Varianten angewendet. Wenn Sie stattdessen eine Abhängigkeit nur für einen bestimmten Build-Varianten- oder Test-Quellsatz deklarieren möchten, müssen Sie den Konfigurationsnamen großschreiben und den Namen der Build-Variante oder des Testquellsatzes voranstellen.
Wenn Sie beispielsweise mit der Konfiguration implementation
eine Remote-Binärabhängigkeit nur zu Ihrer „kostenlosen“ Produktvariante hinzufügen möchten, verwenden Sie Folgendes:
Kotlin
dependencies { freeImplementation("com.google.firebase:firebase-ads:21.5.1") }
Groovig
dependencies { freeImplementation 'com.google.firebase:firebase-ads:21.5.1' }
Wenn Sie jedoch eine Abhängigkeit für eine Variante hinzufügen möchten, die eine Produkt-Flavor und einen Build-Typ kombiniert, müssen Sie den Konfigurationsnamen initialisieren:
Kotlin
// Initializes a placeholder for the freeDebugImplementation dependency configuration. val freeDebugImplementation by configurations.creating dependencies { freeDebugImplementation(project(":free-support")) }
Groovig
configurations { // Initializes a placeholder for the freeDebugImplementation dependency configuration. freeDebugImplementation {} } dependencies { freeDebugImplementation project(":free-support") }
Wenn Sie implementation
-Abhängigkeiten für Ihre lokalen Tests und instrumentierten Tests hinzufügen möchten, sieht das so aus:
Kotlin
dependencies { // Adds a remote binary dependency only for local tests. testImplementation("junit:junit:4.12") // Adds a remote binary dependency only for the instrumented test APK. androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1") }
Groovig
dependencies { // Adds a remote binary dependency only for local tests. testImplementation 'junit:junit:4.12' // Adds a remote binary dependency only for the instrumented test APK. androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1' }
Bestimmte Konfigurationen sind in dieser Situation jedoch nicht sinnvoll. Da andere Module beispielsweise nicht von androidTest
abhängig sein können, wird bei Verwendung der Konfiguration androidTestApi
die folgende Warnung angezeigt:
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'.
Abhängigkeitsreihenfolge
Die Reihenfolge, in der Sie die Abhängigkeiten auflisten, gibt deren Priorität an: Die erste Bibliothek hat eine höhere Priorität als die zweite, die zweite eine höhere Priorität als die dritte und so weiter. Diese Reihenfolge ist wichtig, wenn Ressourcen zusammengeführt oder Manifestelemente aus den Bibliotheken in Ihrer App zusammengeführt werden.
Wenn in Ihrem Projekt beispielsweise Folgendes deklariert ist:
- Abhängigkeit von
LIB_A
undLIB_B
(in dieser Reihenfolge) - Und
LIB_A
hängt vonLIB_C
undLIB_D
ab (in dieser Reihenfolge) - Und
LIB_B
hängt auch vonLIB_C
ab
Dann sieht die Reihenfolge der flachen Abhängigkeit so aus:
LIB_A
LIB_D
LIB_B
LIB_C
Dadurch wird sichergestellt, dass sowohl LIB_A
als auch LIB_B
LIB_C
überschreiben können und LIB_D
immer noch eine höhere Priorität als LIB_B
hat, da LIB_A
(der davon abhängt) eine höhere Priorität als LIB_B
hat.
Weitere Informationen zum Zusammenführen von Manifesten aus verschiedenen Projektquellen/Abhängigkeiten finden Sie unter Mehrere Manifestdateien zusammenführen.
Informationen zu Abhängigkeiten für die Play Console
Beim Erstellen Ihrer App enthält AGP Metadaten, die die Bibliotheksabhängigkeiten beschreiben, die in Ihrer App kompiliert werden. Beim Hochladen Ihrer App prüft die Play Console diese Metadaten, um Benachrichtigungen zu bekannten Problemen mit SDKs und Abhängigkeiten zu liefern, die die App verwendet. In einigen Fällen gibt sie umsetzbares Feedback zur Lösung dieser Probleme.
Die Daten werden komprimiert, mit einem Google Play-Signaturschlüssel verschlüsselt und im Signaturblock der Release-App gespeichert. Wir empfehlen, diese Abhängigkeitendatei aufzubewahren, um eine sichere und positive Nutzererfahrung zu ermöglichen. Sie können die Funktion deaktivieren, indem Sie den folgenden dependenciesInfo
-Block in die build.gradle.kts
-Datei Ihres Moduls aufnehmen.
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
Weitere Informationen zu unseren Richtlinien und möglichen Problemen mit Abhängigkeiten finden Sie auf unserer Supportseite zur Verwendung von Drittanbieter-SDKs in Ihrer App.
SDK-Statistiken
In Android Studio werden in der Versionskatalogdatei und im Dialogfeld „Projektstruktur“ für öffentliche SDKs im Google Play SDK Index Lint-Warnungen angezeigt, wenn die folgenden Probleme auftreten:
- Die SDKs werden von ihren Autoren als veraltet gekennzeichnet.
- Die SDKs verstoßen gegen die Google Play-Richtlinien.
Die Warnungen sind Signale dafür, dass Sie diese Abhängigkeiten aktualisieren sollten, da die Verwendung veralteter Versionen verhindern kann, dass Sie in Zukunft Inhalte in der Google Play Console veröffentlichen.
Build-Abhängigkeiten ohne Versionskataloge hinzufügen
Wir empfehlen die Verwendung von Versionskatalogen, um Abhängigkeiten hinzuzufügen und zu verwalten, aber einfache Projekte benötigen sie möglicherweise nicht. Hier ist ein Beispiel für eine Build-Datei, die keine Versionskataloge verwendet:
Kotlin
plugins { id("com.android.application") } android { ... } dependencies { // Dependency on a remote binary implementation("com.example.android:app-magic:12.3") // Dependency on a local library module implementation(project(":mylibrary")) }
Groovig
plugins { id 'com.android.application' } android { ... } dependencies { // Dependency on a remote binary implementation 'com.example.android:app-magic:12.3' // Dependency on a local library module implementation project(':mylibrary') }
Diese Build-Datei deklariert eine Abhängigkeit von Version 12.3 der Bibliothek „app-magic“ in der Namespace-Gruppe „com.example.android“. Die Deklaration der Remote-Binärabhängigkeit ist eine Abkürzung für:
Kotlin
implementation(group = "com.example.android", name = "app-magic", version = "12.3")
Groovig
implementation group: 'com.example.android', name: 'app-magic', version: '12.3'
Die Build-Datei deklariert außerdem eine Abhängigkeit von einem Android-Bibliotheksmodul namens „mylibrary“. Dieser Name muss mit dem Bibliotheksnamen übereinstimmen, der in der Datei settings.gradle.kts
mit einem include:
definiert ist. Wenn Sie Ihre Anwendung erstellen, kompiliert das Build-System das Bibliotheksmodul und verpackt den resultierenden kompilierten Inhalt in der Anwendung.
Die Build-Datei deklariert auch eine Abhängigkeit vom Android-Gradle-Plug-in (com.application.android
). Wenn Sie mehrere Module haben, die dasselbe Plug-in verwenden, kann nur eine einzige Version des Plug-ins im Build-Klassenpfad für alle Module vorhanden sein. Anstatt die Version in jedem der Modul-Build-Skripts anzugeben, sollten Sie die Plug-in-Abhängigkeit in das Stamm-Build-Skript mit der Version aufnehmen und angeben, dass sie nicht angewendet werden soll. Durch Hinzufügen von apply false
wird Gradle angewiesen, die Version des Plug-ins zu notieren, aber nicht im Stamm-Build zu verwenden.
In der Regel ist das Root-Build-Skript leer, mit Ausnahme dieses plugins
-Blocks.
Kotlin
plugins { id("org.jetbrains.kotlin.android") version "1.9.0" apply false }
Groovig
plugins { id ‘com.android.application’ version ‘8.3.0-rc02’ apply false }
Wenn Sie ein Projekt mit einem Modul haben, können Sie die Version explizit im Build-Skript auf Modulebene angeben und das Build-Skript auf Projektebene leer lassen:
Kotlin
plugins { id("com.android.application") version "8.3.0" }
Groovig
plugins { id 'com.android.application' version '8.3.0-rc02' }