Aggiungi dipendenze build

Il sistema di compilazione Gradle in Android Studio ti consente di includere file binari o altri moduli di libreria alla tua build come dipendenze. La possono trovarsi sulla tua macchina o in un repository remoto anche le dipendenze transitive che dichiarano vengono incluse automaticamente. In questa pagina viene descritto come utilizzare le dipendenze con il progetto Android, incluse quelle relative i dettagli su comportamenti e configurazioni specifici il plug-in Android Gradle (AGP). Per una guida concettuale più completa a Gradle di dipendenze, dovresti vedere anche Guida a Gradle per la gestione delle dipendenze ma ricorda che il tuo progetto Android deve utilizzare solo configurazioni di dipendenza definite in questa pagina.

Aggiungi una dipendenza libreria o plug-in

Il modo migliore per aggiungere e gestire le dipendenze della build è usare cataloghi delle versioni, è quello usato per impostazione predefinita dai nuovi progetti. Questa sezione tratta le più comuni tipi di configurazioni utilizzate per i progetti Android; consulta le Documentazione di Gradle per altre opzioni. Per un esempio di app che utilizza cataloghi delle versioni, vedi Ora su Android. Se hai già configurato le dipendenze della build senza cataloghi delle versioni e hai un progetto multimodulo, è in corso la migrazione.

Per indicazioni sull'aggiunta e la gestione delle dipendenze native (non comune), vedi Dipendenze native.

Nel seguente esempio, aggiungiamo un programma binario remoto della dipendenza (Jetpack Macrobenchmark libreria), modulo della biblioteca locale una dipendenza (myLibrary) e un plug-in (plug-in Android Gradle) al nostro progetto. Ecco le informazioni generali passaggi per aggiungere queste dipendenze al progetto:

1. Aggiungi un alias per la versione della dipendenza che vuoi nel Sezione [versions] del file di catalogo delle versioni, denominata libs.versions.toml (nella directory gradle in visualizzazione progetto o script Gradle nella visualizzazione Android):

   [versions]
   agp = "8.3.0"
   androidx-macro-benchmark = "1.2.2"
   my-library = "1.4"
   
   [libraries]
   ...
   
   [plugins]
   ...
   

   Gli alias possono includere trattini o trattini bassi. Questi alias generano valori nidificati a cui puoi fare riferimento negli script di build. I riferimenti iniziano con il nome del catalogo, la parte libs di libs.versions.toml. Quando utilizzando un catalogo a versione singola, consigliamo di mantenere il valore predefinito "libs".

2. Aggiungi un alias per la dipendenza in [libraries] (per binari remoti o moduli di librerie locali) o [plugins] (per plug-in) del file 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" }
   

   Alcune librerie sono disponibili in una distinta base di materiali (BOM) pubblicata che raggruppa le famiglie di librerie e le relative versioni. Puoi includere un BOM nel catalogo delle versioni e file di build e lasciare che sia lui a gestire quelle versioni. Consulta Utilizzo della distinta base per i dettagli.

3. Aggiungi un riferimento all'alias di dipendenza allo script di build della che richiedono la dipendenza. Converti l'alias trattini bassi e trattini ai punti quando fai riferimento a questo elemento da uno script di build. Script di build a livello di modulo avrà il seguente aspetto:

   Kotlin

   plugins {
     alias(libs.plugins.androidApplication)
   }
   
   dependencies {
     implementation(libs.androidx.benchmark.macro)
     implementation(libs.my.library)
   }
   

   Alla moda

   plugins {
     alias 'libs.plugins.androidApplication'
   }
   
   dependencies {
     implementation libs.androidx.benchmark.macro
     implementation libs.my.library
   }
   

   I riferimenti dei plug-in includono plugins dopo il nome del catalogo e i riferimenti alla versione includono versions dopo il nome del catalogo (versione i riferimenti sono rari; consulta la sezione Dipendenze. con gli stessi numeri di versione per esempi di riferimenti di versione.) Biblioteca riferimenti non includono un qualificatore libraries, quindi non puoi utilizzare versions o plugins all'inizio di una raccolta alias.

Configura le dipendenze

All'interno del blocco dependencies, puoi dichiarare una dipendenza dalla libreria utilizzando una di diverse configurazioni di dipendenze (ad esempio implementation mostrate precedenti). Ogni configurazione delle dipendenze fornisce a Gradle istruzioni su come usare la dipendenza. Nella tabella seguente sono descritti tutti delle configurazioni che puoi usare per una dipendenza nel tuo progetto Android.

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

Configura le dipendenze per una variante di build specifica

Tutte le configurazioni precedenti applicano dipendenze a tutte le varianti di build. Se devi dichiarare una dipendenza solo per una specifica build set di origini di varianti o per un'origine di test impostata, devi scrivere in maiuscolo la configurazione e anteponigli il nome della variante di build o il set di origini di test.

Ad esempio, per aggiungere una dipendenza binaria remota solo al file "senza costi" prodotto versione con la configurazione implementation, utilizza questo:

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

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

Tuttavia, se vuoi aggiungere una dipendenza per una variante che combina un prodotto e un tipo di build, devi inizializzare il nome della configurazione:

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

Per aggiungere dipendenze implementation per i test locali e i test instrumentati , ha il seguente aspetto:

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'
}

Tuttavia, alcune configurazioni non hanno senso in questa situazione. Ad esempio: poiché gli altri moduli non possono dipendere da androidTest, viene visualizzato quanto segue avviso se utilizzi la configurazione androidTestApi:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

Ordine delle dipendenze

L'ordine in cui elencare le dipendenze indica la priorità di ciascuna: la prima libreria ha una priorità più alta della seconda, la seconda è più alta principale rispetto alla terza e così via. Questo ordine è importante nel caso in cui risorse unite o gli elementi manifest vengono uniti nella tua app dalle librerie.

Ad esempio, se il tuo progetto dichiara quanto segue:

• Dipendenza da LIB_A e LIB_B (in questo ordine)
• E LIB_A dipende da LIB_C e LIB_D (in quell'ordine)
• E LIB_B dipende anche da LIB_C

Quindi, l'ordine delle dipendenze stabile sarà il seguente:

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

Ciò garantisce che sia LIB_A sia LIB_B possano eseguire l'override LIB_C; e LIB_D ha ancora una priorità più alta di LIB_B perché LIB_A (che dipende) ha una priorità maggiore di LIB_B.

Per ulteriori informazioni su come si manifesta da diversi progetti le origini/dipendenze sono unite; consulta Unire più file manifest.

Informazioni sulle dipendenze per Play Console

Quando crei la tua app, AGP include i metadati che descrivono la libreria di dipendenze compilate nella tua app. Quando carichi l'app, lo strumento La console controlla questi metadati per fornire avvisi relativi a problemi noti relativi agli SDK delle dipendenze utilizzate dalla tua app e, in alcuni casi, fornire feedback strategici risolvere questi problemi.

I dati sono compressi, criptati da una chiave di firma di Google Play e archiviati in il blocco di firma della release dell'app. Consigliamo di conservare queste dipendenze per un'esperienza utente sicura e positiva. Puoi disattivare questa opzione includendo il persone che seguo dependenciesInfo nel file build.gradle.kts del modulo.

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

Per ulteriori informazioni sulle nostre norme e sui potenziali problemi con le dipendenze, consulta la nostra pagina di assistenza utilizzando SDK di terze parti nella tua app.

Approfondimenti sull'SDK

Android Studio mostra avvisi di lint nel file di catalogo delle versioni e nella sezione Finestra di dialogo della struttura per gli SDK pubblici nel Google Play SDK Index quando si verificano i seguenti problemi:

• Gli SDK sono contrassegnati come obsoleti dai rispettivi autori.
• Gli SDK violano le norme di Google Play.

Gli avvisi indicano che è necessario aggiornare queste dipendenze, l'utilizzo di versioni obsolete potrebbe impedirti di pubblicare su Google Play di Google Cloud in futuro.

Aggiungi dipendenze build senza cataloghi delle versioni

Ti consigliamo di usare i cataloghi delle versioni per aggiungere e gestire le dipendenze, ma potrebbero non essere necessari per alcuni progetti. Ecco un esempio di file di build che non utilizza cataloghi delle versioni:

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

Questo file di build dichiara una dipendenza dalla versione 12.3 di "app-magic" all'interno della libreria "com.example.android" gruppo dello spazio dei nomi. Il programma binario remoto la dichiarazione delle dipendenze è un modo breve per:

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

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

Il file di build dichiara anche una dipendenza da un modulo della libreria Android denominato "mialibreria"; questo nome deve corrispondere al nome della libreria definito con include: in il tuo file settings.gradle.kts. Quando crei la tua app, il sistema di compilazione compila il modulo della libreria e pacchettizza i contenuti compilati risultanti nel dell'app.

Il file di build dichiara anche una dipendenza dal plug-in Android Gradle (com.application.android) Se hai più moduli che utilizzano lo stesso puoi avere una sola versione del plug-in nel classpath della build in tutti i moduli. Invece di specificare la versione in ogni modulo script di build, devi includere la dipendenza del plug-in nello script di build principale alla versione e indicare di non applicarla. L'aggiunta di apply false dice Gradle per annotare la versione del plug-in, ma non per utilizzarla nella build root. In genere lo script di compilazione principale è vuoto, ad eccezione di questo blocco plugins.

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

plugins {
    id ‘com.android.application’ version ‘8.3.0-rc02’ apply false
}

Se hai un progetto a modulo singolo, puoi specificare la versione in modo esplicito lo script di build a livello di modulo e lascia vuoto lo script di build a livello di progetto:

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

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