Build-Abhängigkeiten hinzufügen

Mit dem Gradle-Build-System in Android Studio können Sie externe Binärdateien oder andere Bibliotheksmodule als Abhängigkeiten zu Ihrem Build hinzufügen. Die Abhängigkeiten können sich auf Ihrem Computer oder in einem Remote-Repository befinden. deklarierten transitiven Abhängigkeiten, ebenfalls automatisch eingeschlossen. Auf dieser Seite wird beschrieben, wie Sie Abhängigkeiten mit Ihrem Android-Projekt verwenden, einschließlich zu Verhaltensweisen und Konfigurationen, die für das Android-Gradle-Plug-in (AGP). Für einen ausführlicheren konzeptionellen Leitfaden zu Gradle Abhängigkeiten, sollten Sie auch die Gradle-Leitfaden für die Abhängigkeitsverwaltung , aber denken Sie daran, dass Ihr Android-Projekt nur das Abhängigkeitskonfigurationen, die auf dieser Seite definiert sind.

Bibliothek oder Plug-in-Abhängigkeit hinzufügen

Build-Abhängigkeiten lassen sich am besten mithilfe von Versionskatalogen, wird in neuen Projekten standardmäßig verwendet. In diesem Abschnitt werden die am häufigsten Konfigurationsarten für Android-Projekte finden Sie in der Gradle-Dokumentation finden Sie weitere Optionen. Ein Beispiel für eine Anwendung, die Versionskataloge verwendet, finden Sie unter Jetzt für Android. Wenn Sie Build-Abhängigkeiten bereits eingerichtet haben ohne Versionskataloge und ein Projekt mit mehreren Modulen haben, empfehlen wir migrieren.

Eine Anleitung zum Hinzufügen und Verwalten nativer Abhängigkeiten (nicht üblich) finden Sie unter Native Abhängigkeiten.

Im folgenden Beispiel fügen wir ein Remote-Binärprogramm Abhängigkeit (Jetpack-Makro-Benchmark Library-Modul), lokales Bibliotheksmodul Abhängigkeit (myLibrary) und ein Plug-in (das Android-Gradle-Plug-in) für unser Projekt. Hier sind die allgemeinen um Ihrem Projekt diese Abhängigkeiten hinzuzufügen:

1. Fügen Sie einen Alias für die Version der Abhängigkeit hinzu, die im Abschnitt [versions] der Versionskatalogdatei namens libs.versions.toml (im Verzeichnis gradle in Projektansicht oder Gradle-Skripts in der Android-Ansicht:

   [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 der Katalog, der libs-Teil von libs.versions.toml. Wann? nur einen Versionskatalog verwenden, empfehlen wir, den Standardwert „Bibliotheken“.

2. Fügen Sie einen Alias für die Abhängigkeit in [libraries] hinzu (für Remote-Binärdateien oder lokalen Bibliotheksmodulen) oder [plugins] (für Plug-ins) der Datei libs.versions.toml.

   [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, die gruppiert Familien von Bibliotheken und deren Versionen. Sie können eine Stückliste (BOM) in Ihre Versionskatalog und Build-Dateien erstellen und diese Versionen für Sie verwalten lassen. Weitere Informationen finden Sie unter Weitere Informationen finden Sie in der Materialliste.

3. Fügen Sie dem Build-Skript des Abhängigkeitsalias einen Verweis auf den Abhängigkeitsalias hinzu. Module, die die Abhängigkeit erfordern. Alias konvertieren Unterstriche und Bindestriche wenn Sie in einem Build-Skript darauf verweisen. Unser Build-Script 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 enthalten versions nach dem Katalognamen (Version Verweise sind ungewöhnlich; Siehe Abhängigkeiten mit gleichen Versionsnummern, um Beispiele für Versionsreferenzen zu erhalten. Bibliothek Referenzen haben keinen libraries-Qualifier. Daher können Sie versions oder plugins am Anfang einer Bibliothek Alias.

Abhängigkeiten konfigurieren

Innerhalb des dependencies-Blocks können Sie eine Bibliotheksabhängigkeit mithilfe einer Abhängigkeitskonfigurationen (wie implementation dargestellt) früher). Jede Abhängigkeitskonfiguration stellt Gradle Anweisungen zur Verwendung der Abhängigkeit. In der folgenden Tabelle werden die einzelnen Konfigurationen, die Sie für eine Abhängigkeit in Ihrem Android-Projekt verwenden können.

dependencies {
  // 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"))
}

dependencies {
  // 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 Deklarieren Sie stattdessen eine Abhängigkeit nur für einen bestimmten Build Variante oder für eine Testquelle set enthält, müssen Sie die Konfiguration großschreiben. und stellen Sie ihm den Namen der Build-Variante oder des Testquellensatzes voran.

Um beispielsweise eine Remote-Binärabhängigkeit nur zu Ihrer "kostenlosen" Produkt Flavor mit der implementation-Konfiguration verwenden, verwenden Sie Folgendes:

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

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 ein Produkt -Flavor und einen Build-Typ haben, müssen Sie den Konfigurationsnamen initialisieren:

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

implementation-Abhängigkeiten für lokale und instrumentierte Tests hinzufügen angezeigt wird, sieht das so aus:

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")
}

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. Beispiel: Da andere Module nicht von androidTest abhängen können, erhalten Sie Folgendes: Warnung, 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: hat die erste Bibliothek eine höhere Priorität als die zweite, die zweite eine höhere Priorität. Priorität als das dritte usw. Diese Reihenfolge ist wichtig für den Fall, Ressourcen werden zusammengeführt oder Manifestelemente werden zusammengeführt über die Bibliotheken in Ihre App einbinden.

Angenommen, in Ihrem Projekt wird Folgendes deklariert:

• Abhängigkeit von LIB_A und LIB_B (in dieser Reihenfolge)
• Und LIB_A hängt von LIB_C und LIB_D ab (in dieser Reihenfolge)
• LIB_B hängt auch von LIB_C ab

Dann sieht die flache Abhängigkeitsreihenfolge so aus:

1. LIB_A
2. LIB_D
3. LIB_B
4. LIB_C

Dadurch wird sichergestellt, dass sowohl LIB_A als auch LIB_B LIB_C; und LIB_D hat immer noch eine höhere Priorität als LIB_B, weil LIB_A (abhängig davon) hat eine höhere Priorität als LIB_B.

Weitere Informationen dazu, wie Manifeste aus verschiedenen Projekten Quellen/Abhängigkeiten zusammengeführt werden, siehe Führen Sie mehrere Manifestdateien zusammen.

Abhängigkeitsinformationen für die Play Console

Beim Erstellen Ihrer App nimmt AGP Metadaten mit, die die Bibliothek beschreiben. die in Ihre Anwendung kompiliert sind. Beim Hochladen deiner App zeigt der Play Store Die Console prüft diese Metadaten, um Warnungen zu bekannten Problemen mit SDKs und und geben in einigen Fällen umsetzbares Feedback diese Probleme zu beheben.

Die Daten werden komprimiert, mit einem Google Play-Signaturschlüssel verschlüsselt und in den Signaturblock deiner Release-App. Wir empfehlen, diese Abhängigkeiten für eine sichere und positive Nutzererfahrung. Sie können die Funktion deaktivieren, indem Sie den Follower dependenciesInfo -Block in der build.gradle.kts-Datei deines Moduls ein.

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 unter auf unserer Supportseite Drittanbieter-SDKs in Ihrer App verwenden.

SDK-Statistiken

Android Studio zeigt Lint-Warnungen in der Versionskatalogdatei und im Projekt Dialogfeld „Struktur“ für öffentliche SDKs im Google Play SDK Index, 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 sind Hinweise darauf, dass Sie diese Abhängigkeiten aktualisieren sollten, Wenn du veraltete Versionen verwendest, kannst du möglicherweise keine Veröffentlichungen bei Google Play vornehmen in der Google Cloud Console.

Build-Abhängigkeiten ohne Versionskataloge hinzufügen

Wir empfehlen die Verwendung von Versionskatalogen, um Abhängigkeiten hinzuzufügen und zu verwalten. und Projekte sie möglicherweise nicht benötigen. Hier ist ein Beispiel für eine Build-Datei, Versionskataloge:

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"))
}

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 von „app-magic“. Bibliothek im Bereich „com.example.android“ Namespace-Gruppe. Remote-Binärprogramm Die Abhängigkeitsdeklaration steht für Folgendes:

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

Die Build-Datei deklariert auch eine Abhängigkeit von einem Android-Bibliotheksmodul mit dem Namen "mylibrary"; Dieser Name muss mit dem Bibliotheksnamen übereinstimmen, der mit include: definiert ist in Ihre settings.gradle.kts-Datei. Wenn Sie Ihre App erstellen, kompiliert das Bibliotheksmodul und verpackt die resultierenden kompilierten Inhalte im

Die Build-Datei deklariert auch eine Abhängigkeit vom Android-Gradle-Plug-in. (com.application.android) Wenn Sie mehrere Module haben, Plug-ins können Sie nur eine einzige Version des Plug-ins im Build-Klassenpfad verwenden. in allen Modulen. Anstatt in jedem Modul die Version anzugeben, Build-Scripts sollten Sie die Plug-in-Abhängigkeit in das Root-Build-Skript aufnehmen. durch die Version und geben an, dass sie nicht angewendet werden soll. apply false wird hinzugefügt Gradle. Normalerweise ist das Root-Build-Skript leer, mit Ausnahme dieses plugins-Blocks.

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

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 in das Build-Skript auf Modulebene und lassen Sie das Build-Skript auf Projektebene leer:

plugins {
    id("com.android.application") version "8.3.0"
}

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}