Android Gradle Plugin 7.0.0 (luglio 2021)

Il plug-in Android per Gradle 7.0.0 è una versione principale che include una serie di nuove funzioni e miglioramenti.

Compatibilità

JDK 11 necessario per eseguire AGP 7.0

Quando usate il plug-in Android Gradle 7.0 per creare la vostra app, ora JDK 11 è richiesta per eseguire Gradle. Arctic Fox di Android Studio raggruppa JDK 11 e configura Gradle in modo che lo utilizzi per impostazione predefinita, il che significa che la maggior parte di Android Studio e gli utenti non devono apportare alcun modifiche alla configurazione dei loro progetti.

Se devi impostare manualmente il valore Versione JDK utilizzata da AGP in Android Studio, devi usare JDK 11 o superiore.

Se utilizzi AGP indipendente da Android Studio, esegui l'upgrade della versione JDK entro il giorno Impostare la variabile di ambiente JAVA_HOME o -Dorg.gradle.java.home l'opzione a riga di comando alla directory di installazione di JDK 11.

Tieni presente che SDK Manager e AVD Manager nel pacchetto SDK Tools 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 in attuale Strumenti a riga di comando dell'SDK per Android pacchetto.

Stabile dell'API Variant

La nuova API Variant ora è stabile. Scopri le nuove interfacce nella com.android.build.api.variant ed esempi nel Progetto GitHub gradle-recipes. Nell'ambito del nuovo Variant API, abbiamo reso disponibili una serie di file intermedi, gli artefatti Artefatti a riga di comando. Questi artefatti, come il manifest unito, possono essere ottenuti in sicurezza e personalizzati mediante plug-in e codice di terze parti.

Continueremo a estendere l'API Variant aggiungendo nuove funzionalità e l'aumento del numero di elementi intermedi che mettiamo a disposizione personalizzazione.

Modifiche del comportamento per Lint

Questa sezione descrive le diverse modifiche del comportamento Lint in Android Gradle plugin 7.0.0.

Lint migliorato per le dipendenze della libreria

L'esecuzione del lint con checkDependencies = true è ora più veloce rispetto a prima. Per i progetti Android costituiti da un'app con libreria di dipendenze, si consiglia di impostare checkDependencies su true come mostrato di seguito e per eseguire lint tramite ./gradlew :app:lint, che analizzerà tutte le dipendenze moduli in parallelo e produrre un unico report che includa i problemi e tutte le sue dipendenze.

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

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

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

Se le origini e le risorse di un modulo non sono cambiate, l'analisi dei lint per il modulo non deve essere eseguita di nuovo. In questi casi, dell'attività viene visualizzato come "UP-TO-DATE" nel Gradle come output. Con questa modifica, quando esegui lint su un modulo dell'applicazione con checkDependencies = true, solo i moduli che sono stati modificati verranno per eseguire la propria analisi. Di conseguenza, Lint può funzionare ancora più velocemente.

Non è necessario eseguire nemmeno l'attività di report Lint se i relativi input non sono stati è cambiato. Un problema noto correlato è l'assenza di pelucchi. output di testo stampato su stdout quando l'attività lint è UP-TO-DATE (problema n. 191897708).

Esecuzione lint sui moduli di funzionalità dinamiche

AGP non supporta più l'esecuzione di lint dai moduli di funzionalità dinamiche. L'esecuzione del lint dal modulo dell'applicazione corrispondente comporterà l'esecuzione del lint su ai suoi moduli di funzionalità dinamiche e includere tutti i problemi nel lint dell'app report. Un problema noto correlato è che, quando viene eseguito l'intuitivo, con checkDependencies = true di un modulo dell'app, le dipendenze della libreria di funzionalità dinamiche non vengono controllate a meno che non siano anche app (problema #191977888).

Lint in esecuzione solo sulla variante predefinita

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

Avvisi di classe mancanti nello shrinker R8

R8 in modo più preciso gestisce costantemente le classi mancanti e l'opzione -dontwarn. Di conseguenza, dovresti iniziare a valutare gli avvisi relativi alle classi mancanti emessi di R8.

Quando R8 rileva un riferimento di classe non definito nella tua app o una delle sue dipendenze, emetterà un avviso visualizzato nella build come output. Ad esempio:

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

Questo avviso indica che la definizione della classe Impossibile trovare java.lang.instrument.ClassFileTransformer quando analizzi il codice della tua app. Anche se di solito questo significa che c'è un errore, è possibile che tu voglia ignorare questo avviso. Due motivi comuni per ignorare gli avvisi sono:

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

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

Puoi ignorare un avviso relativo alla classe mancante aggiungendo un -dontwarn al tuo file proguard-rules.pro. Ad esempio:

-dontwarn java.lang.instrument.ClassFileTransformer

Per praticità, AGP genera un file che contiene tutte le di regole mancanti, scrivendole in un percorso file come il seguente: app/build/outputs/mapping/release/missing_rules.txt. Aggiungi il parametro regole al tuo file proguard-rules.pro per ignorare gli avvisi.

In AGP 7.0, i messaggi mancanti delle classi verranno visualizzati come avvisi e potrai convertirli in errori impostando android.r8.failOnMissingClasses = true pollici gradle.properties. In AGP 8.0, questi avvisi che interrompono la build. È possibile mantenere il comportamento di AGP 7.0 aggiungendo l'opzione -ignorewarnings al tuo proguard-rules.pro file, ma non è consigliabile.

Cache di build del plug-in Android per Gradle rimossa

La cache build AGP è stata rimossa in AGP 4.1. Introdotto in precedenza in AGP 2.3 per integrare la cache di build Gradle, la cache di build AGP è stata sostituita interamente dalla cache build di Gradle in AGP 4.1. Questa modifica non influisce in fase di creazione.

In AGP 7.0, la proprietà android.enableBuildCache, android.buildCacheDir e la proprietà L'attività cleanBuildCache è stata rimossa.

Usa il codice sorgente Java 11 nel progetto

Ora puoi compilare fino a codice sorgente Java 11 nel progetto della tua app, abilitando di utilizzare caratteristiche linguistiche più recenti, come i metodi di interfaccia privata, il rombo l'operatore per le classi anonime e la sintassi delle variabili locali per i parametri lambda.

Per attivare questa funzionalità, imposta compileOptions sul valore desiderato Versione Java e imposta compileSdkVersion su 30 o successiva:

// 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 di dipendenza rimosse

In AGP 7.0, le seguenti configurazioni (o ambiti delle dipendenze) sono state rimosso:

• compile
  A seconda del caso d'uso, è stato sostituito da api o implementation.
  Si applica anche alle varianti di *Compilazione, ad esempio: debugCompile.
• provided
  Questo campo è stato sostituito da compileOnly.
  Si applica anche alle varianti *Fornito, ad esempio: releaseProvided.
• apk
  Questo campo è stato sostituito da runtimeOnly.
• publish
  Questo campo è stato sostituito da runtimeOnly.

Nella maggior parte dei casi, l'AGP L'Assistente per l'upgrade eseguirà automaticamente la migrazione del tuo progetto alla nuova configurazioni.

Modifica del percorso della classe durante la compilazione su Android Plug-in Gradle

Se esegui la compilazione in base al plug-in Android Gradle, la compilazione classpath potrebbe cambiare. Perché AGP ora utilizza api/implementation configurazioni interne, alcuni artefatti potrebbero essere rimossi dalla compilazione classpath. Se dipendi da una dipendenza AGP al momento della compilazione, come dipendenza esplicita.

Aggiunta di librerie native in una risorsa Java cartella non supportata

In precedenza, potevi aggiungere una libreria nativa in una cartella di risorse Java e registra la cartella utilizzando android.sourceSets.main.resources.srcDirs , in modo che la libreria nativa venga estratta e aggiunta al file . A partire da AGP 7.0, questa funzionalità non è supportata e le librerie native in un La cartella delle risorse Java viene ignorata. Utilizza invece il metodo DSL destinato librerie native, android.sourceSets.main.jniLibs.srcDirs. Per ulteriori informazioni, vedi come configurare di origini dati.

Problemi noti

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

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

Android Gradle Plugin 7.0.0 è compatibile con Kotlin Plug-in multipiattaforma 1.5.0 e versioni successive. Progetti che utilizzano il software Kotlin Il supporto multipiattaforma richiede l'aggiornamento a Kotlin 1.5.0 per poter usare Android Gradle Plug-in 7.0.0. Come soluzione alternativa, puoi eseguire il downgrade del plug-in Android Gradle alla versione 4.2.x, anche se è sconsigliato.

Per ulteriori informazioni, vedi KT-43944.

Output lint mancante

Nessun output di testo lint stampato su stdout quando l'attività lint è aggiornato (problema n. 191897708). Per ulteriori informazioni, vedi Modifiche del comportamento per il lint. Questo problema verrà corretto nel plug-in Android Gradle 7.1.

Non tutte le dipendenze della libreria di funzionalità dinamiche sono controllate da lint

Quando esegui il lint con checkDependencies = true da un modulo dell'app, le dipendenze della libreria di funzionalità dinamiche non vengono controllate a meno che sono anche dipendenze dell'app (problema n. 191977888). Come soluzione alternativa, l'attività lint può essere eseguita su queste librerie. Per maggiore contesto, consulta Modifiche del comportamento per lint.