Plug-in Android Gradle 4.1.0 (agosto 2020)

Compatibilità

Questa versione del plug-in Android richiede quanto segue:

• Gradle 6.5. Per scoprire di più, consulta la sezione sull'aggiornamento di Gradle.

• SDK Build Tools 29.0.2 o versioni successive.

La versione predefinita di NDK in questa release è la 21.1.6352462. Per installare una versione di NDK diversa, consulta l'articolo Installare una versione specifica di NDK.

Nuove funzionalità

Questa versione del plug-in Android per Gradle include le seguenti nuove funzionalità.

Supporto DSL con Kotlin Script

Per migliorare l'esperienza di modifica per gli utenti di buildscript di Kotlin, le API DSL e le API del plug-in Android Gradle 4.1 sono ora definite in un set di interfacce Kotlin separatamente dalle relative classi di implementazione. Ciò significa che:

• I valori null e mutabilità sono ora dichiarati esplicitamente nei tipi Kotlin.
• La documentazione generata da queste interfacce è pubblicata nella pagina Riferimento API Kotlin.
• La superficie API del plug-in Android per Gradle è chiaramente definita, in modo che l'estensione di Android crei meno problemi in futuro.

Importante: se hai già adottato gli script di build KTS o utilizzi Kotlin in buildSrc, ciò potrebbe causare interruzioni della compatibilità dell'origine per alcuni errori che si sarebbero manifestati come errori di runtime nelle release precedenti.

I tipi di raccolta progettati per essere modificati in DSL ora vengono definiti in modo uniforme come:

val collection: MutableCollectionType

Ciò significa che non è più possibile scrivere quanto segue negli script Kotlin per alcune raccolte che in precedenza lo supportavano:

collection = collectionTypeOf(...)

Tuttavia, la modifica della raccolta è supportata in modo uniforme, quindi collection += … e collection.add(...) ora dovrebbero funzionare ovunque.

Se riscontri problemi durante l'upgrade di un progetto che utilizza le API Kotlin e DSL del plug-in Android per Gradle, segnala un bug.

Esporta le dipendenze C/C++ da AAR

Il plug-in Android Gradle 4.0 ha aggiunto la possibilità di importare pacchetti prefabbricati nelle dipendenze AAR. In AGP 4.1, ora è possibile esportare le librerie dalla build nativa esterna in un AAR per un progetto della libreria Android.

Per esportare le librerie native, aggiungi quanto segue al blocco android del file build.gradle del tuo progetto di libreria:

buildFeatures {
    prefabPublishing true
}


prefab {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }
<var>myotherlibrary</var> {
    headers "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
     
buildFeatures {
    prefabPublishing = true
}


prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }
create("<var>myotherlibrary</var>") {
    headers = "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      

In questo esempio, le librerie mylibrary e myotherlibrary di ndk-build o di build nativa esterna CMake verranno pacchettizzate nell'AAR prodotto dalla tua build e ciascuna esporterà le intestazioni dalla directory specificata ai rispettivi dipendenti.

Nota: per gli utenti del plug-in Android per Gradle 4.0 e versioni successive, le impostazioni di configurazione per l'importazione delle librerie native predefinite sono cambiate. Per ulteriori informazioni, consulta le note di rilascio 4.0.

Supporto R8 per i metadati Kotlin

Kotlin utilizza metadati personalizzati nei file di classi Java per identificare i costrutti del linguaggio Kotlin. R8 ora supporta la gestione e la riscrittura dei metadati Kotlin in modo da supportare completamente la riduzione delle librerie e delle applicazioni Kotlin utilizzando kotlin-reflect.

Per mantenere i metadati Kotlin, aggiungi le seguenti regole di Keep:

-keep class kotlin.Metadata { *; }


-keepattributes RuntimeVisibleAnnotations

In questo modo indichi a R8 di mantenere i metadati Kotlin per tutte le classi direttamente conservate.

Per ulteriori informazioni, vedi Shrinking Kotlin Library and Applications using Kotlin riflessione con R8{:.external} su Medium.

Asserzioni nelle build di debug

Quando crei la versione di debug della tua app utilizzando il plug-in Android Gradle 4.1.0 e versioni successive, il compilatore integrato (D8) riscrive il codice dell'app per abilitare le asserzioni in fase di compilazione, in modo che i controlli delle asserzioni siano sempre attivi.

Modifiche del comportamento

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, questa 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.

L'attività cleanBuildCache e le proprietà android.enableBuildCache e android.buildCacheDir sono deprecate e verranno rimosse in AGP 7.0. Al momento la proprietà android.enableBuildCache non ha alcun effetto, mentre la proprietà android.buildCacheDir e l'attività cleanBuildCache funzioneranno fino ad AGP 7.0 per l'eliminazione di eventuali contenuti esistenti della cache delle build AGP.

Dimensioni notevolmente ridotte per quelle che utilizzano la riduzione del codice

A partire da questa release, i campi delle classi R non vengono più conservati per impostazione predefinita, il che potrebbe comportare riduzioni significative delle dimensioni degli APK per le app che consentono la riduzione del codice. Ciò non dovrebbe comportare un cambiamento del comportamento, a meno che tu non acceda alle classi R tramite riflessione, nel qual caso è necessario aggiungere regole di Keep per quelle classi R.

Proprietà android.namespacedRClass rinominata in android.nonTransitiveRClass

Il flag sperimentale android.namespacedRClass è stato rinominato in android.nonTransitiveRClass.

Impostato nel file gradle.properties, questo flag consente il pacing dei nomi della classe R di ogni libreria in modo che la classe R includa solo le risorse dichiarate nella libreria stessa e nessuna nelle dipendenze della libreria, riducendo così le dimensioni della classe R per quella libreria.

Kotlin DSL: coreLibraryDesugaringEnabled rinominato

L'opzione di compilazione DSL di Kotlin coreLibraryDesugaringEnabled è stata modificata in isCoreLibraryDesugaringEnabled. Per maggiori informazioni su questo flag, consulta la pagina relativa al supporto del desugaring dell'API Java 8 e versioni successive (plug-in Android Gradle 4.0.0 e versioni successive).

Proprietà della versione rimosse dalla classe BuildConfig nei progetti della libreria

Solo per i progetti di libreria, le proprietà BuildConfig.VERSION_NAME e BuildConfig.VERSION_CODE sono state rimosse dalla classe BuildConfig generata perché questi valori statici non riflettevano i valori finali del nome e del codice versione dell'applicazione e, di conseguenza, erano fuorvianti. Inoltre, questi valori sono stati ignorati durante l'unione del manifest.

In una versione futura del plug-in Android Gradle, anche le proprietà versionName e versionCode verranno rimosse dalla DSL per le librerie. Al momento non è possibile accedere automaticamente al codice/nome della versione dell'app da un sottoprogetto di libreria.

Per i moduli dell'applicazione, non sono previste modifiche, puoi comunque assegnare valori a versionCode e versionName nel DSL; questi valori verranno propagati al file manifest dell'app e ai campi BuildConfig.

Imposta percorso NDK

Puoi impostare il percorso dell'installazione NDK locale utilizzando la proprietà android.ndkPath nel file build.gradle del modulo.

android {
  ndkPath "your-custom-ndk-path"
}

android {
  ndkPath = "your-custom-ndk-path"
}

Se utilizzi questa proprietà insieme alla proprietà android.ndkVersion, il percorso deve contenere una versione NDK corrispondente a android.ndkVersion.

Modifiche al comportamento del test delle unità della libreria

Abbiamo modificato il comportamento della compilazione e dell'esecuzione dei test delle unità di libreria. I test delle unità di una libreria vengono ora compilati ed eseguiti rispetto alle classi di compilazione/runtime della libreria stessa, quindi il test delle unità utilizza la libreria allo stesso modo dei sottoprogetti esterni. Questa configurazione di solito comporta test migliori.

In alcuni casi, i test delle unità della libreria che utilizzano l'associazione di dati potrebbero presentare l'assenza delle classi DataBindingComponent o BR. Questi test devono essere trasferiti a un test strumentato nel progetto androidTest, poiché la compilazione e l'esecuzione su queste classi in un test delle unità potrebbero produrre un output non corretto.

Plug-in io.fabric Gradle deprecato

Il plug-in Gradle io.fabric è deprecato e non è compatibile con la versione 4.1 del plug-in Android per Gradle. Per saperne di più sull'SDK Fabric deprecato e sulla migrazione all'SDK Firebase Crashlytics, consulta la pagina Eseguire l'upgrade all'SDK Firebase Crashlytics.