Plug-in Android Gradle 7.1.0 (gennaio 2022)

Il plug-in Android per Gradle 7.1.0 è una release principale che include una serie di nuove funzionalità e miglioramenti.

Compatibilità

	Versione minima	Versione predefinita
Gradle	7,2	7,2
Strumenti di creazione dell'SDK	30,0,3	30,0,3
NDK	N/A	21.4.7075529
JDK	11	11

L'attività di analisi dei lint è ora memorizzabile nella cache

AndroidLintAnalysisTask è ora compatibile con la cache di build di Gradle. Se abiliti la cache della build impostando org.gradle.caching=true nel file gradle.properties, l'attività di analisi lint riceverà il proprio output dalla cache della build, se possibile.

L'attività di analisi lint è spesso il collo di bottiglia maggiore durante l'esecuzione di lint con il plug-in Android per Gradle, quindi l'attivazione della cache della build migliora la velocità della build in molte situazioni l'esecuzione di lint. Dovresti notare un notevole miglioramento delle prestazioni, ad esempio se hai un progetto multimodulo e pulisci la directory di build prima di eseguire lint sul server CI.

I moduli C/C++ possono ora fare riferimento ad altri moduli C/C++ nello stesso progetto

Ora è possibile configurare un modulo Gradle Android con codice C/C++ per fare riferimento ai file di intestazione e al codice della libreria in un altro modulo Gradle. Il protocollo Prefab viene utilizzato per comunicare le intestazioni e le librerie tra i moduli Gradle.

Requisiti

• Il modulo in uso deve essere CMake e non ndk-build. Il supporto di ndk-build richiederà un futuro aggiornamento NDK. Il modulo di publishing potrebbe essere CMake o ndk-build.

• Il modulo in uso deve abilitare prefab nel file build.gradle.

android {
  buildFeatures {
    prefab true
  }
}

• Il modulo publishing deve abilitare prefabPublishing nel file build.gradle.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• Il modulo consumer deve fare riferimento al modulo publishing aggiungendo una riga nel blocco dependencies del file build.gradle. Ecco alcuni esempi:

dependencies {
  implementation project(':mylibrary')
}

• Il modulo publishing deve esporre un pacchetto utilizzando una sezione prefab. Ecco alcuni esempi:

android {
  prefab {
    mylibrary {
      libraryName "libmylibrary"
      headers "src/main/cpp/include"
    }
  }
}

• Il file CMakeLists.txt del modulo in uso potrebbe utilizzare find_package() per individuare il pacchetto pubblicato dal modulo di produzione. Ecco alcuni esempi:

find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
  myapplication
  mylibrary::mylibrary)

• Deve essere presente un solo codice STL per l'intera richiesta. Quindi, ad esempio, sia i moduli di consumo sia quelli di pubblicazione possono utilizzare STL condiviso C++.

   android {
      defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

Per ulteriori spiegazioni su come configurare consumer e producer AAR nativi con AGP, consulta Dipendenze native con AGP.

Impostazioni del repository nel file settings.gradle

Quando viene creato un nuovo progetto in Android Studio Bumblebee, il file build.gradle di primo livello contiene il blocco plugins, seguito dal codice per pulire la directory della build:

plugins {
    id 'com.android.application' version '7.1.0-beta02' apply false
    id 'com.android.library' version '7.1.0-beta02' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
  delete rootProject.buildDir
}

Le impostazioni del repository che in precedenza si trovavano nel file build.gradle di primo livello ora si trovano nel file settings.gradle:

pluginManagement {
  repositories {
    gradlePluginPortal()
    google()
    mavenCentral()
  }
}
dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
    google()
    mavenCentral()
  }
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'

Il file build.gradle a livello di modulo non è stato modificato. Quindi, utilizza il file build.gradle di primo livello e il file settings.gradle per definire le configurazioni di build da applicare a tutti i moduli del progetto oppure i repository e le dipendenze applicabili a Gradle stesso; usa il file build.gradle a livello di modulo per definire configurazioni di build specifiche per un determinato modulo all'interno del progetto.

Riduzione delle risorse migliorata

Android Studio Bumblebee include uno strumento di riduzione delle risorse migliorato che aiuta a ridurre le dimensioni dell'app.

Supporto per le app con funzionalità dinamiche

L'implementazione predefinita dello strumento di riduzione delle risorse Android è stata aggiornata nel plug-in per Android per Gradle 7.1.0-alpha09. La nuova implementazione supporta la riduzione delle app con funzionalità dinamiche.

Ulteriori riduzioni sperimentali delle dimensioni dell'app

La nuova implementazione dello strumento di riduzione delle risorse può ridurre ulteriormente le dimensioni dell'app ridotta modificando la tabella delle risorse per rimuovere le risorse di valore e i riferimenti a risorse file inutilizzate. Il nuovo shinker delle risorse può eliminare completamente le risorse file inutilizzate, riducendo ulteriormente le dimensioni dell'app. Questo comportamento non è ancora attivo per impostazione predefinita, ma puoi provarlo aggiungendo l'opzione sperimentale android.experimental.enableNewResourceShrinker.preciseShrinking=true al file gradle.properties del tuo progetto.

Segnala eventuali problemi riscontrati con il nuovo strumento di riduzione delle risorse o con il flag sperimentale. Per diagnosticare più facilmente i problemi o come soluzione alternativa temporanea, puoi tornare all'implementazione precedente aggiungendo android.enableNewResourceShrinker=false a gradle.properties del progetto. Il nuovo strumento di riduzione delle risorse sostituisce le risorse basate su file inutilizzate con file minimi leggermente diversi rispetto allo strumento di riduzione delle risorse precedente, ma non si prevede alcun impatto sul runtime.

La vecchia implementazione dovrebbe essere rimossa nel plug-in Android Gradle 8.0.0.

Pubblicazione delle varianti di creazione

Il plug-in Android Gradle 7.1.0 e versioni successive consente di configurare quali varianti di build pubblicare in un repository Apache Maven. AGP crea un componente con una o più varianti di build in base al nuovo DSL di pubblicazione, che puoi utilizzare per personalizzare una pubblicazione in un Repository Maven. Rispetto alle versioni precedenti, questo evita anche il lavoro superfluo, poiché per impostazione predefinita non verrà creato alcun componente. Per ulteriori informazioni, consulta l'esempio di codice per la pubblicazione.

Pubblica JAR Javadoc

AGP 7.1.0 e versioni successive consentono di generare Javadoc da origini Java e Kotlin e pubblicare file JAR Javadoc oltre ad AAR per progetti di librerie. Il Javadoc viene aggiunto ai file POM e Gradle Module Metadata{:.external}. Attiva questa funzionalità aggiungendo withJavadocJar() nel blocco di pubblicazione singleVariant o multipleVariants. Per scoprire di più, consulta l'esempio di codice per le opzioni di pubblicazione.

Pubblica JAR origini

AGP 7.1.0 e versioni successive consentono di pubblicare file JAR di origine Java e Kotlin oltre ad AAR per progetti di librerie. Le origini vengono aggiunte ai file POM e Metadati del modulo Gradle{:.external}. Puoi abilitare questa funzionalità aggiungendo withSourcesJar() nel blocco di pubblicazione singleVariant o multipleVariants. Per scoprire di più, consulta l'esempio di codice per le opzioni di pubblicazione.

Modifica della semantica del blocco di lint

Tutti i metodi lint che sostituiscono il livello di gravità specificato di un problema (enable, disable/ignore, informational, warning, error, fatal) ora rispettano l'ordine di configurazione. Ad esempio, l'impostazione di un problema come irreversibile in finalizeDsl() ora sostituisce la relativa disattivazione nella DSL principale. Per maggiori informazioni, consulta i documenti di riferimento sul blocco lint{} e i punti di estensione e flusso delle build Android.

Compatibilità con Navigazione sicura con Args

Le API AGP da cui dipende il plug-in Navigazione sicura Args Gradle sono state rimosse. AGP 7.1 non funziona con le versioni 2.4.0-rc1 o 2.4.0 di Navigation Safe Args, ma con le versioni 2.5.0-alpha01 e 2.4.1. Nel frattempo, come soluzione alternativa, puoi utilizzare AGP 7.1 con una build di snapshot di Navigation Safe Args, Navigation 2.5.0-SNAPSHOT. Per utilizzare la build dello snapshot, segui le istruzioni dello snapshot con l'ID build n. 8054565.

Inoltre, le versioni 2.4.1 e 2.5.0 di Navigation Safe Args non funzioneranno più con AGP 4.2. Per utilizzare queste versioni di Safe Args, devi utilizzare AGP 7.0 e versioni successive.

Disattiva la creazione automatica dei componenti

A partire da AGP 8.0, la creazione automatica dei componenti sarà disattivata per impostazione predefinita. Attualmente, AGP 7.1 crea automaticamente un componente per ogni variante di build, che ha lo stesso nome della variante di build, e un componente all contenente tutte le varianti di build. La creazione automatica di componenti verrà disattivata. Per passare al nuovo comportamento, devi disattivare manualmente la creazione automatica dei componenti impostando android.disableAutomaticComponentCreation su true. Per maggiori informazioni, consulta Utilizzare il plug-in Maven Pubblica.

Compatibilità con Firebase Performance Monitoring

AGP 7.1 non è compatibile con la versione 1.4.0 e precedenti del plug-in per Gradle di Firebase Performance Monitoring. AGP Upgrade Assistant non aggiornerà automaticamente il plug-in alla versione 1.4.1, quindi se utilizzi firebase-perf e vuoi eseguire l'upgrade di AGP alla 7.1, dovrai eseguire manualmente questo upgrade specifico.

Problemi noti

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

Problemi relativi al test delle unità di un progetto di app che utilizza il plug-in Hilt

Il classpath test delle unità contiene le classi di app non strumentate, il che significa che Hilt non permette alle classi dell'app di gestire l'inserimento delle dipendenze durante l'esecuzione dei test delle unità.

Questo problema verrà risolto con la release 7.1.1, consulta il problema n. 213534628.