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.
7.0.1 (agosto 2021)
Questo aggiornamento minore include varie correzioni di bug. Per visualizzare un elenco delle principali correzioni di bug, leggi il post correlato nella Blog degli aggiornamenti delle release.
Compatibilità
Versione minima | Versione predefinita | Note | |
---|---|---|---|
Gradle | 7.0.2 | 7.0.2 | Per scoprire di più, consulta la sezione sull'aggiornamento di Gradle. |
Strumenti di creazione SDK | 30.0.2 | 30.0.2 | Installa o configura gli strumenti di creazione dell'SDK. |
ND | N/D | 21,4.7075529 | Installa o configura una versione diversa dell'NDK. |
JDK | 11 | 11 | Per scoprire di più, consulta la sezione sull'impostazione della versione JDK. |
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.
Alla moda
// build.gradle
android {
...
lintOptions {
checkDependencies true
}
}
Kotlin
// 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:
-
Le librerie che hanno come target la JVM e la classe mancante sono di JVM di libreria (come nell'esempio sopra).
-
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 daapi
oimplementation
.
Si applica anche alle varianti di *Compilazione, ad esempio:debugCompile
. -
provided
Questo campo è stato sostituito dacompileOnly
.
Si applica anche alle varianti *Fornito, ad esempio:releaseProvided
. -
apk
Questo campo è stato sostituito daruntimeOnly
. -
publish
Questo campo è stato sostituito daruntimeOnly
.
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.