Mit dem Gradle-Build-System in Android Studio können Sie externe Binärdateien oder andere Bibliotheksmodule als Abhängigkeiten in Ihren Build aufnehmen. Die Abhängigkeiten können sich auf Ihrem Computer oder in einem Remote-Repository befinden. Alle von ihnen deklarierten transitiven Abhängigkeiten werden ebenfalls automatisch einbezogen. Auf dieser Seite wird beschrieben, wie Sie Abhängigkeiten mit Ihrem Android-Projekt verwenden, einschließlich Details zu Verhaltensweisen und Konfigurationen für das Android-Gradle-Plug-in (AGP). Einen ausführlicheren konzeptionellen Leitfaden zu Gradle-Abhängigkeiten finden Sie im Gradle-Leitfaden für die Abhängigkeitsverwaltung. Beachten Sie jedoch, dass in Ihrem Android-Projekt nur die auf dieser Seite definierten Abhängigkeitskonfigurationen verwendet werden dürfen.
Bibliothek oder Plug-in-Abhängigkeit hinzufügen
Die beste Möglichkeit zum Hinzufügen und Verwalten von Build-Abhängigkeiten besteht in der Verwendung von Versionskatalogen, der Methode, die bei neuen Projekten standardmäßig verwendet wird. In diesem Abschnitt werden die gängigsten Konfigurationstypen für Android-Projekte behandelt. Weitere Optionen finden Sie in der Gradle-Dokumentation. Ein Beispiel für eine App, die Versionskataloge verwendet, findest du unter Jetzt in Android. Wenn Sie bereits Build-Abhängigkeiten ohne Versionskataloge eingerichtet haben 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), die Modulabhängigkeit des lokalen Bibliotheksmoduls (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 mit dem Namenlibs.versions.toml
(im Verzeichnisgradle
in der Projektansicht oder unter Gradle-Skripts in der Android-Ansicht) einen Alias für die gewünschte Version der Abhängigkeit hinzu:[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
libs
-Teil vonlibs.versions.toml
. Wenn Sie einen einzelnen Versionskatalog verwenden, empfehlen wir, den Standardwert "libs" beizubehalten.Fügen Sie einen Alias für die Abhängigkeit im Abschnitt
[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 (Bill of Materials, Stückliste) verfügbar, in der Bibliotheken und ihre Versionen zusammengefasst sind. Sie können eine BOM in Ihren Versionskatalog und Ihre Build-Dateien aufnehmen und diese Versionen für Sie verwalten lassen. Weitere Informationen finden Sie unter Materialliste verwenden.
Fügen Sie dem Build-Skript der Module, die die Abhängigkeit benötigen, einen Verweis auf den Abhängigkeitsalias hinzu. Wandeln Sie die Unterstriche und Bindestriche des Alias in Punkte um, 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) }
Cool
plugins { alias 'libs.plugins.androidApplication' } dependencies { implementation libs.androidx.benchmark.macro implementation libs.my.library }
Plug-in-Referenzen enthalten
plugins
nach dem Katalognamen und Versionsverweise enthaltenversions
nach dem Katalognamen. Versionsverweise sind selten. Beispiele für Versionsverweise finden Sie unter Abhängigkeiten mit denselben Versionsnummern. Bibliotheksverweise enthalten keinenlibraries
-Qualifier. Daher können Sieversions
oderplugins
nicht am Anfang eines Bibliotheksalias verwenden.
Abhängigkeiten konfigurieren
Innerhalb des dependencies
-Blocks können Sie eine Bibliotheksabhängigkeit mit einer von mehreren verschiedenen Abhängigkeitskonfigurationen deklarieren, z. B. mit implementation
. Jede Abhängigkeitskonfiguration bietet Gradle eine andere Anleitung zur Verwendung der Abhängigkeit. In der folgenden Tabelle werden die einzelnen 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 Compiler-Klassenpfad hinzu und verpackt die Abhängigkeit zur Build-Ausgabe. Wenn das Modul eine implementation -Abhängigkeit konfiguriert, teilt es Gradle mit, dass das Modul die Abhängigkeit nicht bei der Kompilierung an andere Module weitergeben soll. Das heißt, die Abhängigkeit wird nicht für andere Module verfügbar gemacht, die vom aktuellen Modul abhängen.
Die Verwendung dieser Abhängigkeitskonfiguration anstelle von |
api |
Gradle fügt die Abhängigkeit dem Compiling-Klassenpfad und der Build-Ausgabe hinzu. Wenn ein Modul eine api -Abhängigkeit enthält, wird Gradle darüber informiert, dass das Modul diese Abhängigkeit vorübergehend in andere Module exportieren möchte, damit sie sowohl zur Laufzeit als auch zur Kompilierungszeit verfügbar ist.
Verwenden Sie diese Konfiguration mit Vorsicht und nur mit Abhängigkeiten, die Sie vorübergehend in andere vorgelagerte Nutzer exportieren müssen. Wenn sich die externe API einer |
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, dass sie während der Laufzeit vorhanden ist. Wenn Sie beispielsweise von einer Bibliothek abhängig sind, die nur Anmerkungen zur Kompilierungszeit enthält, die normalerweise zum Generieren von Code verwendet werden, aber häufig nicht in der Build-Ausgabe enthalten sind, können Sie diese Bibliothek mit compileOnly markieren.
Wenn Sie diese Konfiguration verwenden, muss Ihr Bibliotheksmodul eine Laufzeitbedingung enthalten, um zu prüfen, ob die Abhängigkeit verfügbar ist, und dann sein Verhalten ordnungsgemäß ändern, sodass es auch ohne Angabe weiter funktionieren kann. Dies hilft, die Größe der endgültigen Anwendung zu reduzieren, da keine vorübergehenden Abhängigkeiten hinzugefügt werden, die nicht kritisch sind.
Hinweis:Die |
runtimeOnly |
Gradle fügt die Abhängigkeit nur der Build-Ausgabe hinzu, damit sie während der Laufzeit verwendet werden kann. Das heißt, er wird nicht zum Compiler-Klassenpfad hinzugefügt.
Dies wird unter Android selten verwendet, aber häufig in Serveranwendungen genutzt, um Logging-Implementierungen bereitzustellen. Beispielsweise könnte eine Bibliothek eine Logging API verwenden, die keine Implementierung enthält. Nutzer dieser Bibliothek könnten sie als implementation -Abhängigkeit hinzufügen und eine runtimeOnly -Abhängigkeit für die eigentliche zu verwendende Logging-Implementierung einschließen.
|
ksp |
Diese Konfigurationen stellen Bibliotheken bereit, die Annotationen und andere Symbole in Ihrem Code verarbeiten, bevor er kompiliert wird. Sie validieren in der Regel Ihren Code oder generieren zusätzlichen Code, sodass Sie weniger Code schreiben müssen. Um eine solche Abhängigkeit hinzuzufügen, müssen Sie sie mithilfe der Konfigurationen Das Android-Gradle-Plug-in geht davon aus, 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 ausgegeben.
Berücksichtigen Sie bei der Entscheidung, welche Konfiguration Sie verwenden möchten, Folgendes:
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 hinzuzufügen, die Gradle in eine lint.jar -Datei und ein Paket in Ihrem AAR kompilieren soll. Dadurch werden diese Lint-Prüfungen auch bei Projekten angewendet, in denen AAE verwendet wird. Wenn Sie zuvor die Abhängigkeitskonfiguration lintChecks verwendet haben, um Lint-Prüfungen in den veröffentlichten AAR aufzunehmen, müssen Sie diese Abhängigkeiten migrieren, um stattdessen die lintPublish -Konfiguration 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")) } Cooldependencies { // 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
Alle vorherigen Konfigurationen wenden Abhängigkeiten auf alle Build-Varianten an. Wenn Sie stattdessen eine Abhängigkeit nur für einen bestimmten Build-Varianten-Quellsatz oder für einen Testquellsatz deklarieren möchten, müssen Sie den Konfigurationsnamen großschreiben und ihm den Namen der Build-Variante oder des Testquellsatzes voranstellen.
Wenn Sie beispielsweise eine binäre Remote-Abhängigkeit nur zu Ihrem "kostenlosen" Produkt-Flavor mit der implementation
-Konfiguration hinzufügen möchten, verwenden Sie Folgendes:
Kotlin
dependencies { freeImplementation("com.google.firebase:firebase-ads:21.5.1") }
Cool
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 Produktvariante 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")) }
Cool
configurations { // Initializes a placeholder for the freeDebugImplementation dependency configuration. freeDebugImplementation {} } dependencies { freeDebugImplementation project(":free-support") }
So fügen Sie implementation
-Abhängigkeiten für Ihre lokalen und instrumentierten Tests hinzu:
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") }
Cool
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 nicht von androidTest
abhängen können, wird die folgende Warnung ausgegeben, wenn Sie die androidTestApi
-Konfiguration verwenden:
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'.
Abhängigkeitsreihenfolge
Die Reihenfolge, in der Sie Ihre Abhängigkeiten auflisten, gibt die Priorität der einzelnen Abhängigkeiten an: Die erste Bibliothek hat eine höhere Priorität als die zweite, die zweite hat eine höhere Priorität als die dritte und so weiter. Diese Reihenfolge ist wichtig für den Fall, dass Ressourcen oder Manifestelemente aus den Bibliotheken in Ihrer App zusammengeführt werden.
Angenommen, in Ihrem Projekt wird Folgendes deklariert:
- Abhängigkeit von
LIB_A
undLIB_B
(in dieser Reihenfolge) - Und
LIB_A
hängt vonLIB_C
undLIB_D
(in dieser Reihenfolge) ab. LIB_B
hängt auch vonLIB_C
ab
Dann sieht die flache Abhängigkeitsreihenfolge 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
(das 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.
Abhängigkeitsinformationen für die Play Console
Beim Erstellen Ihrer App fügt AGP Metadaten hinzu, 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 Ihrer App bereitzustellen und in einigen Fällen umsetzbares Feedback zur Behebung dieser Probleme zu geben.
Die Daten werden komprimiert, mit einem Google Play-Signaturschlüssel verschlüsselt und im Signaturblock der Release-App gespeichert. Wir empfehlen, diese Abhängigkeitendatei für eine sichere und positive Nutzererfahrung aufzubewahren. Zum Deaktivieren können Sie den folgenden dependenciesInfo
-Block in die build.gradle.kts
-Datei Ihres Moduls einfügen.
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
Android Studio zeigt Lint-Warnungen in der Versionskatalogdatei und im Dialogfeld „Projektstruktur“ für öffentliche SDKs im Google Play SDK Index an, wenn die folgenden Probleme auftreten:
- Die SDKs wurden von ihren Autoren als veraltet gekennzeichnet.
- Die SDKs verstoßen gegen die Google Play-Richtlinien.
Die Warnungen deuten darauf hin, dass du diese Abhängigkeiten aktualisieren solltest. Die Verwendung veralteter Versionen könnte dazu führen, dass du in Zukunft keine Inhalte mehr in der Google Play Console veröffentlichen kannst.
Build-Abhängigkeiten ohne Versionskataloge hinzufügen
Wir empfehlen die Verwendung von Versionskatalogen, um Abhängigkeiten hinzuzufügen und zu verwalten. Für einfache Projekte werden sie jedoch möglicherweise nicht benötigt. 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")) }
Cool
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 steht für Folgendes:
Kotlin
implementation(group = "com.example.android", name = "app-magic", version = "12.3")
Cool
implementation group: 'com.example.android', name: 'app-magic', version: '12.3'
Die Build-Datei deklariert auch eine Abhängigkeit von einem Android-Bibliotheksmodul namens "mylibrary". Dieser Name muss mit dem Bibliotheksnamen übereinstimmen, der in der settings.gradle.kts
-Datei mit einem include:
definiert ist. Wenn Sie Ihre Anwendung erstellen, kompiliert das Build-System das Bibliotheksmodul und verpackt die resultierenden kompilierten Inhalte in der Anwendung.
Die Build-Datei deklariert auch eine Abhängigkeit vom Android-Gradle-Plug-in (com.application.android
). Wenn mehrere Module dasselbe Plug-in verwenden, kann für alle Module nur eine einzige Version des Plug-ins im Build-Klassenpfad verwendet werden. Anstatt die Version in jedem Build-Skript des Moduls anzugeben, sollten Sie die Plug-in-Abhängigkeit in das Root-Build-Skript mit der Version aufnehmen und angeben, dass sie nicht angewendet werden soll. Wenn Sie apply false
hinzufügen, wird Gradle die Version des Plug-ins notieren, aber nicht im Root-Build verwenden.
Normalerweise ist das Root-Build-Skript leer, mit Ausnahme dieses plugins
-Blocks.
Kotlin
plugins { id("org.jetbrains.kotlin.android") version "1.9.0" apply false }
Cool
plugins { id ‘com.android.application’ version ‘8.3.0-rc02’ apply false }
Wenn Sie ein Projekt mit einem einzelnen 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" }
Cool
plugins { id 'com.android.application' version '8.3.0-rc02' }