Plug-in Android per Gradle 7.0.0 (luglio 2021)

Il plug-in Android per Gradle 7.0.0 è una release principale che include una serie di nuove funzionalità e miglioramenti.

Compatibilità

JDK 11 necessario per eseguire AGP 7.0

Quando utilizzi il plug-in Android Gradle 7.0 per creare la tua app, ora è obbligatorio JDK 11 per eseguire Gradle. Android Studio Arctic Fox include JDK 11 e configura Gradle per utilizzarlo per impostazione predefinita, il che significa che la maggior parte degli utenti di Android Studio non deve apportare modifiche alla configurazione dei propri progetti.

Se devi impostare manualmente la versione JDK utilizzata da AGP in Android Studio, devi utilizzare JDK 11 o versioni successive.

Quando utilizzi AGP indipendentemente da Android Studio, esegui l'upgrade della versione JDK impostando la variabile di ambiente JAVA_HOME o l'opzione a riga di comando -Dorg.gradle.java.home nella directory di installazione di JDK 11.

Tieni presente che SDK Manager e AVD Manager nel pacchetto SDK Tools deprecato non funzionano con JDK 11. Per continuare a utilizzare SDK Manager e AVD Manager con AGP 7.0 e versioni successive, devi passare alle nuove versioni degli strumenti nel pacchetto degli strumenti a riga di comando dell'SDK Android corrente.

API Variant stabile

La nuova API Variant è ora stabile. Consulta le nuove interfacce nel pacchetto com.android.build.api.variant ed esempi nel progetto GitHub gradle-recipes. Nell'ambito della nuova API Variant, abbiamo reso disponibili una serie di file intermedi, chiamati elementi, tramite l'interfaccia Artifacts. Questi elementi, come il manifest unito, possono essere ottenuti e personalizzati in sicurezza utilizzando codice e plug-in di terze parti.

Continueremo ad estendere l'API Variant aggiungendo nuove funzionalità e aumentando il numero di elementi intermedi che rendiamo disponibili per la personalizzazione.

Modifiche al comportamento di Lint

Questa sezione descrive diverse modifiche al comportamento di Lint nel plug-in Android per Gradle 7.0.0.

È stato migliorato il lint per le dipendenze delle librerie

L'esecuzione di lint con checkDependencies = true è ora più rapida rispetto a prima. Per i progetti Android costituiti da un'app con dipendenze dalle librerie, è consigliabile impostare checkDependencies su true come mostrato di seguito ed eseguire lint tramite ./gradlew :app:lint, che analizzerà tutti i moduli delle dipendenze in parallelo e produrrà un singolo report che include i problemi dell'app e di tutte le sue dipendenze.

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

Ora le attività di lint possono essere UP-TO-DATE

Se le origini e le risorse di un modulo non sono cambiate, non è necessario eseguire di nuovo l'attività di analisi lint per il modulo. In questo caso, l'esecuzione dell'attività viene visualizzata come "AGGIORNATA" nell'output di Gradle. Con questa modifica, quando esegui lint su un modulo dell'applicazione con checkDependencies = true, solo i moduli modificati dovranno eseguire l'analisi. Di conseguenza, Lint può funzionare ancora più velocemente.

Inoltre, l'attività di generazione del report Lint non deve essere eseguita se gli input non sono stati modificati. Un problema noto correlato è che non viene stampato alcun output di testo di lint su stdout quando l'attività di lint è AGGIORNATA (problema 191897708).

Eseguire lint sui moduli di funzionalità dinamiche

AGP non supporta più l'esecuzione di lint dai moduli di funzionalità dinamiche. L'esecuzione di lint dal modulo dell'applicazione corrispondente eseguirà lint sui suoi moduli di funzionalità dinamiche e includerà tutti i problemi nel report lint dell'app. Un problema noto correlato è che, quando esegui lint con checkDependencies = true da un modulo dell'app, le dipendenze delle librerie di funzionalità dinamiche non vengono controllate, a meno che non siano anche dipendenze dell'app (problema #191977888).

Eseguire lint solo sulla variante predefinita

L'esecuzione di ./gradlew :app:lint ora esegue lint solo per la variante predefinita. Nelle versioni precedenti di AGP, veniva eseguito lint per tutte le varianti.

Avvisi di classi mancanti nello shrinker R8

R8 gestisce in modo più preciso e coerente le classi mancanti e l'opzione -dontwarn. Pertanto, dovresti iniziare a valutare gli avvisi mancanti relativi alla classe emessi da R8.

Quando R8 rileva un riferimento a una classe non definito nell'app o in una delle sue dipendenze, emette un avviso visualizzato nell'output della compilazione. Ad esempio:

R8: Missing class: java.lang.instrument.ClassFileTransformer

Questo avviso indica che non è stato possibile trovare la definizione della classejava.lang.instrument.ClassFileTransformer durante l'analisi del codice dell'app. Sebbene in genere indichi la presenza di un errore, è possibile che tu voglia ignorare questo avviso. Ecco due motivi comuni per ignorare l'avviso:

1. Le librerie che hanno come target la JVM e la classe mancante sono di tipo JVM (come nell'esempio precedente).

2. Una delle dipendenze utilizza un'API solo in fase di compilazione.

Puoi ignorare un avviso relativo a una classe mancante aggiungendo una regola -dontwarn al file proguard-rules.pro. Ad esempio:

-dontwarn java.lang.instrument.ClassFileTransformer

Per comodità, AGP genererà un file contenente tutte le regole potenzialmente mancanti, scrivendole in un percorso file come il seguente: app/build/outputs/mapping/release/missing_rules.txt. Aggiungi le regole al file proguard-rules.pro per ignorare gli avvisi.

In AGP 7.0, i messaggi di classe mancanti vengono visualizzati come avvisi e puoi trasformarli in errori impostando android.r8.failOnMissingClasses = true in gradle.properties. In AGP 8.0, questi avvisi diventeranno errori che interrompono la build. È possibile mantenere il comportamento di AGP 7.0 aggiungendo l'opzione -ignorewarnings al file proguard-rules.pro, ma questa operazione non è consigliata.

La cache di compilazione del plug-in Android per Gradle è stata rimossa

La cache di compilazione AGP è stata rimossa in AGP 4.1. Precedentemente introdotta in AGP 2.3 per integrare la cache di compilazione di Gradle, la cache di compilazione di AGP è stata sostituita completamente dalla cache di compilazione di Gradle in AGP 4.1. Questa modifica non influisce sul tempo di compilazione.

In AGP 7.0, la proprietà android.enableBuildCache, la proprietà android.buildCacheDir e l'attività cleanBuildCache sono state rimosse.

Utilizzare il codice sorgente Java 11 nel progetto

Ora puoi compilare fino al codice sorgente Java 11 nel progetto della tua app, il che ti consente di utilizzare le funzionalità di linguaggio più recenti, come i metodi di interfaccia privati, l'operatore diamante per le classi anonime e la sintassi delle variabili locali per i parametri lambda.

Per attivare questa funzionalità, imposta compileOptions sulla versione Java che preferisci e compileSdkVersion su 30 o versioni successive:

// build.gradle
android {
  compileSdkVersion 30
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_11
    targetCompatibility JavaVersion.VERSION_11
  }
  // For Kotlin projects
  kotlinOptions {
    jvmTarget = "11"
  }
}

// build.gradle.kts
android {
  compileSdkVersion(30)
  compileOptions {
    sourceCompatibility(JavaVersion.VERSION_11)
    targetCompatibility(JavaVersion.VERSION_11)
  }
  kotlinOptions {
    jvmTarget = "11"
  }
}

Configurazioni delle dipendenze rimosse

In AGP 7.0, le seguenti configurazioni (o ambiti di dipendenza) sono state rimosse:

• compile
  In base al caso d'uso, è stato sostituito da api o implementation.
  Si applica anche alle varianti *Compile, ad esempio: debugCompile.
• provided
  Questo valore è stato sostituito da compileOnly.
  Si applica anche alle varianti *Fornite, ad esempio: releaseProvided.
• apk
  Questo valore è stato sostituito da runtimeOnly.
• publish
  Questo valore è stato sostituito da runtimeOnly.

Nella maggior parte dei casi, l'Assistente per l'upgrade di AGP eseguirà automaticamente la migrazione del progetto alle nuove configurazioni.

Modifica del percorso di classe durante la compilazione in base al plug-in Gradle Android

Se esegui la compilazione in base al plug-in Gradle per Android, il percorso di compilazione potrebbe cambiare. Poiché ora AGP utilizza internamente le configurazioni api/implementation, alcuni elementi potrebbero essere rimossi dal classpath compilato. Se hai bisogno di una dipendenza AGP in fase di compilazione, assicurati di aggiungerla come dipendenza esplicita.

L'aggiunta di librerie native in una cartella di risorse Java non è supportata

In precedenza, potevi aggiungere una libreria nativa in una cartella delle risorse Java e registrarla utilizzando android.sourceSets.main.resources.srcDirs in modo che la libreria nativa venisse estratta e aggiunta all'APK finale. A partire da AGP 7.0, questa operazione non è supportata e le librerie native in una cartella delle risorse Java vengono ignorate. Utilizza invece il metodo DSL destinato alle librerie native, android.sourceSets.main.jniLibs.srcDirs. Per maggiori informazioni, consulta la sezione Come configurare i set di origini.

Problemi noti

Questa sezione descrive i problemi noti del plug-in Android per Gradle 7.0.0.

Incompatibilità con il plug-in Kotlin Multiplatform 1.4.x

Android Gradle Plugin 7.0.0 è compatibile con il plug-in Kotlin Multiplatform 1.5.0 e versioni successive. I progetti che utilizzano il supporto multipiattaforma di Kotlin devono eseguire l'aggiornamento a Kotlin 1.5.0 per utilizzare il plug-in Android Gradle 7.0.0. Come soluzione alternativa, puoi eseguire il downgrade del plug-in Android per Gradle alla versione 4.2.x, anche se questa operazione non è consigliata.

Per ulteriori informazioni, consulta KT-43944.

Output lint mancante

Non viene stampato alcun output di testo del lint su stdout quando l'attività di lint è aggiornata (issue #191897708). Per maggiori informazioni, consulta Modifiche al comportamento di lint. Questo problema verrà risolto nel plug-in Android per Gradle 7.1.

Non tutte le dipendenze delle librerie di funzionalità dinamiche sono sottoposte a controllo lint

Quando esegui lint con checkDependencies = true da un modulo dell'app, le dipendenze delle librerie di funzionalità dinamiche non vengono controllate, a meno che non siano anche dipendenze dell'app (issue #191977888). Come soluzione alternativa, l'attività di lint può essere eseguita su queste librerie. Per ulteriori informazioni, consulta Modifiche al comportamento di lint.