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 richiesto per eseguire AGP 7.0

Quando utilizzi Android Gradle Plugin 7.0 per creare la tua app, ora è necessario 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 di 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'-Dorg.gradle.java.home opzione della riga di comando 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 Android SDK Command-Line Tools 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 artefatti, tramite l'interfaccia Artefatti. Questi artefatti, come il manifest unito, possono essere ottenuti e personalizzati in modo sicuro 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 rendiamo disponibili per la personalizzazione.

Modifiche al comportamento per Lint

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

Lint migliorato per le dipendenze della libreria

L'esecuzione di lint con checkDependencies = true ora è più veloce rispetto a prima. Per i progetti Android costituiti da un'app con dipendenze dalla 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 produrrà un unico report che include i problemi dell'app e di tutte le relative dipendenze.

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

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

Le attività di linting ora possono essere AGGIORNATE

Se le origini e le risorse di un modulo non sono cambiate, l'attività di analisi lint per il modulo non deve essere eseguita di nuovo. In questo caso, l'esecuzione dell'attività viene visualizzata come "UP-TO-DATE" 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ò essere eseguito ancora più velocemente.

Inoltre, l'attività del report Lint non deve essere eseguita se i relativi input non sono cambiati. Un problema noto correlato è che non viene stampato alcun output di testo lint su stdout quando l'attività lint è UP-TO-DATE (problema n. 191897708).

Esecuzione di lint sui moduli di funzionalità dinamiche

AGP non supporta più l'esecuzione di lint dai moduli delle funzionalità dinamiche. L'esecuzione di lint dal modulo dell'applicazione corrispondente eseguirà lint sui relativi moduli delle 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 della libreria di funzionalità dinamiche non vengono controllate a meno che non siano anche dipendenze dell'app (problema #191977888).

Esecuzione di lint solo sulla variante predefinita

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

Avvisi di classe mancante in R8 shrinker

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

Quando R8 rileva un riferimento di classe non definito nella tua app o in una delle sue dipendenze, emette un avviso che viene visualizzato nell'output della build. Ad esempio:

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

Questo avviso indica che la definizione della classe java.lang.instrument.ClassFileTransformer non è stata trovata durante l'analisi del codice dell'app. Anche se di solito questo significa che si è verificato 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 JVM (come nell'esempio precedente).

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

Puoi ignorare l'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 relativi alle classi 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 non è consigliabile.

Cache di compilazione del plug-in Android per Gradle rimossa

La cache di build AGP è stata rimossa in AGP 4.1. Introdotta in precedenza in AGP 2.3 per integrare la cache di build Gradle, la cache di build AGP è stata sostituita completamente dalla cache di build 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 funzionalità del 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 di Java desiderata e compileSdkVersion su 30 o un valore superiore:

// 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 delle dipendenze) sono state rimosse:

• compile
  A seconda del caso d'uso, è stato sostituito da api o implementation.
  Valido anche per le varianti *Compile, ad esempio: debugCompile.
• provided
  Questo valore è stato sostituito da compileOnly.
  Valido anche per le varianti *Fornito, ad esempio: releaseProvided.
• apk
  Questo valore è stato sostituito da runtimeOnly.
• publish
  Questo valore è stato sostituito da runtimeOnly.

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

Modifica del classpath durante la compilazione rispetto al plug-in Android Gradle

Se stai compilando in base al plug-in Android Gradle, il classpath di compilazione potrebbe cambiare. Poiché AGP ora utilizza internamente le configurazioni api/implementation, 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, questa operazione non è supportata e le librerie native in una cartella di risorse Java vengono ignorate. Utilizza invece il metodo DSL previsto per le librerie native, android.sourceSets.main.jniLibs.srcDirs. Per maggiori informazioni, vedi come configurare i set di origini.

Problemi noti

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

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

Il plug-in Android per Gradle 7.0.0 è compatibile con il plug-in Kotlin Multiplatform 1.5.0 e versioni successive. I progetti che utilizzano il supporto multipiattaforma Kotlin devono essere aggiornati a Kotlin 1.5.0 per utilizzare il plug-in Android per Gradle 7.0.0. Come soluzione alternativa, puoi eseguire il downgrade del plug-in Android per Gradle alla versione 4.2.x, anche se non è consigliabile.

Per ulteriori informazioni, vedi KT-43944.

Output di lint mancante

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

Non tutte le dipendenze della libreria delle funzionalità dinamiche vengono controllate con Lint

Quando esegui lint con checkDependencies = true da un modulo dell'app, le dipendenze della libreria di funzionalità dinamiche non vengono controllate a meno che non siano anche dipendenze dell'app (problema n. 191977888). Per risolvere il problema, è possibile eseguire l'attività di lint su queste librerie. Per maggiori informazioni, consulta Modifiche del comportamento per Lint.