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 il plug-in Android per Gradle 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 del 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 del JDK impostando la variabile di ambiente JAVA_HOME o l'opzione della riga di comando nella directory di installazione di JDK 11.-Dorg.gradle.java.home

Tieni presente che SDK Manager e Gestione AVD nel pacchetto Strumenti SDK ritirato non funzionano con JDK 11. Per continuare a utilizzare SDK Manager e Gestione AVD con AGP 7.0 e versioni successive, devi passare alle nuove versioni degli strumenti nel pacchetto Android SDK Command-Line Tools attuale.

API Variant stabile

La nuova API Variant è ora stabile. Consulta le nuove interfacce nel com.android.build.api.variant pacchetto e gli esempi nel gradle-recipes progetto GitHub. Nell'ambito della nuova API Variant, abbiamo reso disponibili una serie di file intermedi, chiamati artefatti, tramite l' interfaccia Artifacts. 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 di Lint

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

Lint migliorato per le dipendenze della libreria

L'esecuzione di Lint con checkDependencies = true è ora più veloce than before. Per i progetti Android costituiti da un'app con dipendenze della libreria, è consigliabile impostare checkDependencies su true come mostrato di seguito ed eseguire Lint tramite ./gradlew :app:lint, che analizzerà tutti i moduli di dipendenza in parallelo e genererà un singolo 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à Lint ora possono essere UP-TO-DATE

Se le origini e le risorse di un modulo non sono state modificate, 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.

L'attività del report Lint non deve essere eseguita se i relativi input non sono stati modificati. 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 dynamic-feature

AGP non supporta più l'esecuzione di Lint dai moduli dynamic-feature. L'esecuzione di Lint dal modulo dell'applicazione corrispondente eseguirà Lint sui relativi moduli dynamic-feature 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 dynamic-feature non vengono controllate a meno che non siano anche dipendenze dell'app (problema n. 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 nel riduttore R8

R8 gestisce in modo più preciso e coerente le classi mancanti e l'opzione -dontwarn. Pertanto, devi iniziare a valutare gli avvisi di classe mancante 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 non è stato possibile trovare la definizione della classe java.lang.instrument.ClassFileTransformer durante l'analisi del codice dell'app. Sebbene in genere ciò significhi 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 libreria JVM (come nell'esempio sopra riportato).

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

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

-dontwarn java.lang.instrument.ClassFileTransformer

Per comodità, AGP genererà un file contenente tutte le regole potenzialmente mancanti, scrivendole in un percorso di 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 mancante 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 interromperanno la build. È possibile mantenere il comportamento di AGP 7.0 aggiungendo l'opzione -ignorewarnings al file proguard-rules.pro ma non è consigliabile.

Cache di build 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 di Gradle, la cache di build AGP è stata completamente sostituita dalla cache di build di Gradle in AGP 4.1. Questa modifica non influisce sul tempo di compilazione.

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

Utilizzare il codice sorgente Java 11 nel progetto

Ora puoi compilare fino al codice sorgente Java 11 nel progetto dell'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 Java desiderata e imposta 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, sono state rimosse le seguenti configurazioni (o ambiti di dipendenza):

• compile
  A seconda del caso d'uso, questa è stata sostituita da api o implementation.
  Si applica anche alle varianti *Compile, ad esempio: debugCompile.
• provided
  Questa è stata sostituita da compileOnly.
  Si applica anche alle varianti *Provided, ad esempio: releaseProvided.
• apk
  Questa è stata sostituita da runtimeOnly.
• publish
  Questa è 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 rispetto al plug-in Android per Gradle

Se stai eseguendo la compilazione rispetto al plug-in Android per Gradle, il classpath di compilazione potrebbe cambiare. Poiché AGP ora utilizza api/implementation configurazioni 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, questa operazione non è supportata 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 la sezione su come configurare i set di origine.

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 Kotlin Multiplatform plugin 1.5.0 e versioni successive. I progetti che utilizzano il supporto di Kotlin Multiplatform devono essere aggiornati a Kotlin 1.5.0 per utilizzare il plug-in Android per Gradle 7.0.0. Per risolvere il problema, puoi eseguire il downgrade del plug-in Android per Gradle alla versione 4.2.x, anche se non è consigliabile.

Per saperne di più, consulta 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, consulta la sezione Modifiche al comportamento di Lint. Questo problema verrà risolto nel plug-in Android per Gradle 7.1.

Non tutte le dipendenze della libreria dynamic-feature vengono controllate da Lint

Quando esegui Lint con checkDependencies = true da un modulo dell'app, le dipendenze della libreria dynamic-feature non vengono controllate a meno che non siano anche dipendenze dell'app (problema n. 191977888). Per risolvere il problema, l'attività Lint può essere eseguita su queste librerie. Per maggiori informazioni, consulta la sezione Modifiche al comportamento di Lint.