Interdipendenze tra strumenti e librerie

Le dipendenze build sono componenti esterni necessari per creare correttamente il progetto. Una build può dipendere da librerie, plug-in, sottoprogetti, dall'SDK Android, da strumenti come i compilatori Kotlin e Java, da ambienti di sviluppo come Android Studio e da Gradle stesso.

Ogni dipendenza può richiedere altre dipendenze. Le chiamiamo dipendenze tratte e possono aumentare rapidamente le dipendenze complessive utilizzate dalla tua applicazione. Quando vuoi eseguire l'upgrade di una dipendenza, che si tratti di una libreria, di uno strumento o dell'SDK Android, l'upgrade può essere in cascata, eseguendo l'upgrade di molte altre dipendenze.

Spesso, ciò non causa problemi, poiché molte librerie seguono uno schema noto come controllo delle versioni semantico. Queste librerie limitano i tipi di modifiche apportate per garantire la compatibilità con le versioni precedenti.

Il controllo delle versioni semantiche segue un formato major.minor.patch. Ad esempio, nel numero di versione 4.8.3, 4 è la versione major, 8 è la versione minor e 3 è il numero patch. Quando la parte major cambia, la libreria potrebbe avere modifiche sostanziali nell'API o nel comportamento. Ciò può influire sul comportamento della build o dell'applicazione.

Quando le parti minor (nuove funzionalità) o patch (correzioni di bug) cambiano, gli sviluppatori della libreria ti comunicano che la libreria è ancora compatibile e non dovrebbe influire sulla tua applicazione.

È importante prestare attenzione a queste modifiche e diversi strumenti di upgrade delle dipendenze possono essere d'aiuto.

Relazioni nella compilazione

Le build di Android contengono relazioni tra:

• Codice sorgente: il codice e le risorse di cui hai il controllo
• Dipendenze libreria: librerie o moduli esterni che il progetto e i sottoprogetti includono durante la creazione
• Strumenti: compilatori, plug-in e SDK che traducono il codice sorgente in un'applicazione o una libreria

Codice sorgente

Il codice sorgente è il codice Kotlin o Java che scrivi nella tua applicazione o nella tua libreria. Per maggiori dettagli sull'utilizzo di C++, vedi Android NDK.

Il codice sorgente dipende dalle librerie (incluse le librerie di runtime Kotlin e Java) e dall'SDK Android e richiede il compilatore Kotlin o Java corrispondente.

Alcuni codici sorgente includono annotazioni che richiedono un'elaborazione aggiuntiva. Ad esempio, se stai scrivendo codice Jetpack Compose, aggiungi annotazioni come @Composable che devono essere elaborate dal plug-in del compilatore Kotlin Compose. Altre annotazioni possono essere elaborate da un Kotlin Symbol Processor (KSP) o da strumenti di elaborazione delle annotazioni separati.

Dipendenze libreria

Le librerie contengono bytecode importati nell'ambito dell'applicazione. Potrebbe essere un JAR Java, una libreria Android (AAR) o un sottoprogetto nella tua build. Molte librerie adottano il versionamento semantico, che può aiutarti a capire se rimangono compatibili (o meno) durante l'upgrade.

Le librerie possono dipendere da altre librerie per essere riutilizzate, chiamata dipendenza transitiva. In questo modo, riduci le dipendenze che devi gestire esplicitamente. Specifica le dipendenze che utilizzi direttamente e Gradle le importa insieme alle dipendenze transitorie. Tieni presente che, durante l'upgrade delle dipendenze dirette, potrebbero essere aggiornate anche le dipendenze traslative.

A volte una libreria potrebbe richiedere versioni minime dell'SDK Android in fase di runtime (minSdk) o di compilazione (compileSdk). Questo è necessario quando una libreria utilizza funzioni incluse nell'SDK Android o nelle API JDK fornite. Il valore minSdk effettivo della tua applicazione è il valore minSdk più alto richiesto dalla tua applicazione e da tutte le sue dipendenze di librerie dirette e traslative.

L'utilizzo di alcune librerie potrebbe richiedere l'uso di un plug-in Gradle specifico. Questi plug-in di supporto spesso installano Kotlin Symbol Processors o altri processori di annotazioni che generano codice o modificano la compilazione del codice sorgente per supportare l'utilizzo delle funzionalità della libreria. Ad esempio, Jetpack Room include annotazioni e un KSP che li trasforma in codice generato per recuperare e modificare i dati in un database. Jetpack Compose richiede il plug-in del compilatore Compose per modificare le funzioni annotate al fine di gestire come e quando tale funzione può essere eseguita di nuovo.

Strumenti

Ambiti Gradle

Gradle raggruppa le dipendenze delle librerie in ambiti diversi (chiamati configurazioni nell'API Gradle), consentendoti di specificare diversi insiemi di dipendenze delle librerie da utilizzare in parti diverse della costruzione. Ad esempio, probabilmente non vuoi includere librerie di test come JUnit nella tua applicazione o libreria pubblicata, ma le vuoi quando compili ed esegui i test di unità. Utilizzi gli ambiti anche per aggiungere elaboratori di simboli o di annotazione per analizzare il codice.

Ad esempio, AGP definisce gli ambiti implementation e api, il tuo modo di specificare se una dipendenza deve essere esposta agli utenti del tuo sottoprogetto. Consulta Configurare le dipendenze per le descrizioni di questi e altri ambiti utilizzati in una build Android.

Aggiungi le dipendenze delle librerie nel blocco dependencies dei file di build come stringhe group:artifact:version:

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

o in un catalogo di versioni:

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

e specifica le variabili generate nei file di build:

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