Plug-in Android 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 è necessario JDK 11 per eseguire Gradle. Android Studio Arctic Fox integra JDK 11 e configura Gradle per l'utilizzo per impostazione predefinita, il che significa che la maggior parte degli utenti di Android Studio non deve apportare alcuna modifica alla configurazione dei propri progetti.

Se devi impostare manualmente la versione JDK utilizzata da AGP all'interno di Android Studio, devi utilizzare JDK 11 o versioni successive.

Se utilizzi AGP indipendente da Android Studio, esegui l'upgrade della versione JDK impostando la variabile di ambiente JAVA_HOME o l'opzione della riga di comando -Dorg.gradle.java.home sulla tua 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 nell'attuale pacchetto di strumenti a riga di comando dell'SDK Android.

API variante stabile

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

Continueremo a estendere l'API Variant aggiungendo nuove funzionalità e aumentando il numero di artefatti intermedi che mettiamo a disposizione per la personalizzazione.

Modifiche del comportamento dei lint

In questa sezione vengono descritte più modifiche del comportamento dei lint nel plug-in Android Gradle 7.0.0.

Lint migliorato per le dipendenze di libreria

L'esecuzione di lint con checkDependencies = true ora è più veloce di prima. Per i progetti Android composti da un'app con dipendenze di libreria, è 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 genererà un singolo report che include i problemi dell'app e tutte le sue dipendenze.

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

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

Le attività lint possono ora essere AGGIORNATE

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

Inoltre, non è necessario eseguire l'attività di report lint se gli input non sono cambiati. Un problema noto correlato è che non è presente alcun output di testo lint stampato su stdout quando l'attività lint è AGGIORNATA (problema n. 191897708).

Esecuzione di lint su moduli di funzionalità dinamiche

AGP non supporta più l'esecuzione di lint da moduli a funzionalità dinamica. L'esecuzione di lint dal modulo dell'applicazione corrispondente eseguirà il lint sui relativi moduli di funzionalità dinamiche e includerà tutti i problemi nel report lint dell'app. Un problema noto correlato è che, quando si esegue 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).

Esecuzione 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 classe 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 di classe mancanti emessi da R8.

Quando R8 rileva un riferimento di classe che non è definito nell'app o in una delle sue dipendenze, emette un avviso visualizzato nell'output della build. Ecco alcuni esempi:

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

Questo avviso indica che non è stato possibile trovare la definizione della classe java.lang.instrument.ClassFileTransformer durante l'analisi del codice della tua app. Anche se questo di solito indica un errore, è possibile che tu voglia ignorare questo avviso. Due motivi comuni per ignorare l'avviso sono:

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

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

Puoi ignorare un avviso di classe mancante aggiungendo una regola -dontwarn al file proguard-rules.pro. Ecco alcuni esempi:

-dontwarn java.lang.instrument.ClassFileTransformer

Per praticità, 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 mancanti dei corsi vengono visualizzati come avvisi e puoi convertirli in errori impostando android.r8.failOnMissingClasses = true in gradle.properties. In AGP 8.0, questi avvisi diventeranno errori che danneggiano la build. È possibile mantenere il comportamento di AGP 7.0 aggiungendo l'opzione -ignorewarnings al file proguard-rules.pro, ma ciò è sconsigliato.

Cache della build del plug-in Android per Gradle rimossa

La cache di build AGP è stata rimossa in AGP 4.1. Precedentemente introdotta in AGP 2.3 per integrare la cache di build di Gradle, la cache di build AGP è stata completamente sostituita dalla cache di build di Gradle in AGP 4.1. Questa modifica non influisce sulla durata della build.

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

Utilizza il codice sorgente Java 11 nel progetto

Ora puoi compilare fino a codice sorgente Java 11 nel progetto della tua app, in modo da poter usare funzionalità linguistiche più recenti come i metodi di interfaccia privata, l'operatore diamante per le classi anonime e la sintassi delle variabili locali per i parametri lambda.

Per abilitare questa funzionalità, imposta compileOptions sulla versione Java desiderata e imposta compileSdkVersion su 30 o un numero successivo:

// 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 sono state rimosse le seguenti configurazioni (o ambiti delle dipendenze):

• compile
  A seconda del caso d'uso, è stato sostituito da api o implementation.
  Si applica anche alle varianti *Compilazione, ad esempio: debugCompile.
• provided
  È stata sostituita da compileOnly.
  Si applica anche alle varianti *fornite, ad esempio: releaseProvided.
• apk
  È stata sostituita da runtimeOnly.
• publish
  È stata sostituita 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 classpath durante la compilazione con il plug-in Android Gradle

Se stai eseguendo la compilazione con il plug-in Android Gradle, il tuo classpath di compilazione potrebbe cambiare. Poiché AGP ora utilizza le configurazioni api/implementation internamente, alcuni artefatti potrebbero essere rimossi dal classpath di compilazione. Se dipendi da 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 di risorse Java e registrare la cartella 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, non è supportato e le librerie native in una cartella di risorse Java vengono ignorate. Utilizza invece il metodo DSL destinato alle librerie native, android.sourceSets.main.jniLibs.srcDirs. Per saperne di più, consulta Come configurare i set di origini.

Problemi noti

In questa sezione vengono descritti i problemi noti presenti nel plug-in Android Gradle 7.0.0.

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

Il plug-in Android Gradle 7.0.0 è compatibile con il plug-in Multiplatform Kotlin 1.5.0 e versioni successive. I progetti che utilizzano il supporto multipiattaforma Kotlin devono eseguire l'aggiornamento a Kotlin 1.5.0 per utilizzare il plug-in Android Gradle 7.0.0. Per risolvere il problema, puoi eseguire il downgrade del plug-in Android Gradle alla versione 4.2.x, anche se questa operazione è sconsigliata.

Per maggiori informazioni, consulta KT-43944.

Output lint mancante

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

Non tutte le dipendenze delle librerie di funzionalità dinamiche vengono controllate tramite 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 (problema n. 191977888). Come soluzione alternativa, l'attività lint può essere eseguita su queste librerie. Per maggiori informazioni, consulta la sezione Modifiche del comportamento per lint.