Plug-in Android Gradle 3.0.0 (ottobre 2017)

Il plug-in Android Gradle 3.0.0 include una serie di modifiche volte a risolvere i problemi di prestazioni dei progetti di grandi dimensioni.

Ad esempio, in un progetto scheletro di esempio con circa 130 moduli e un numero elevato di dipendenze esterne (ma senza codice o risorse), puoi riscontrare miglioramenti delle prestazioni simili a quanto segue:

Alcune di queste modifiche danneggiano le build esistenti. Dovresti quindi valutare l'
sforzo della migrazione del progetto prima di utilizzare il nuovo plug-in.

Se non riscontri i miglioramenti delle prestazioni descritti sopra, segnala un bug e includi una traccia della tua build utilizzando Gradle Profiler.

Questa versione del plug-in Android richiede quanto segue:

• Gradle 4.1 o superiore. Per scoprire di più, consulta la sezione sull'aggiornamento di Gradle.
• Build Tools 26.0.2 o versioni successive. Con questo aggiornamento, non è più necessario specificare una versione per gli strumenti di compilazione, poiché per impostazione predefinita il plug-in utilizza la versione minima richiesta. Pertanto, ora puoi rimuovere la proprietà android.buildToolsVersion.

Ottimizzazioni

• Migliorare il parallelismo per i progetti multi-modulo tramite un grafico delle attività granulare.
• Quando si apportano modifiche alla dipendenza, Gradle esegue build più rapide perché non ricompila i moduli che non hanno accesso all'API di quella dipendenza. Dovresti limitare le dipendenze ad altri moduli utilizzando le nuove configurazioni delle dipendenze di Gradle: implementation, api, compileOnly e runtimeOnly.
• Velocità di build incrementale più rapida grazie al dexing di ogni classe. Ogni classe viene ora compilata in file DEX separati e solo le classi modificate vengono modificate. Dovresti inoltre aspettarti velocità di build migliorate per le app che impostano minSdkVersion su 20 o un valore inferiore e utilizzano multi-dex legacy.
• Velocità di build migliorate mediante l'ottimizzazione di determinate attività in modo da utilizzare output con problemi. Per trarre vantaggio da questa ottimizzazione, devi prima abilitare la cache di build Gradle.
• È stata migliorata l'elaborazione incrementale delle risorse utilizzando AAPT2, che ora è abilitato per impostazione predefinita. Se riscontri problemi durante l'utilizzo di AAPT2, segnala un bug. Puoi anche disabilitare AAPT2 impostando android.enableAapt2=false nel file gradle.properties e riavviando il daemon Gradle eseguendo ./gradlew --stop dalla riga di comando.

Nuove funzionalità

• Gestione delle dipendenze sensibile alle varianti. Quando crei una determinata variante di un modulo, il plug-in ora abbina automaticamente le varianti delle dipendenze del modulo della libreria locale alla variante del modulo che stai creando.
• Include un nuovo plug-in per il modulo delle funzionalità per supportare le app istantanee Android e l'SDK delle app istantanee Android (che puoi scaricare utilizzando SDK Manager). Per scoprire di più sulla creazione di moduli delle funzionalità con il nuovo plug-in, consulta Struttura di un'app istantanea con più funzionalità.
• Supporto integrato per l'utilizzo di alcune funzionalità del linguaggio Java 8 e delle librerie Java 8. Jack è ora deprecato e non è più obbligatorio. Devi prima disabilitare Jack per utilizzare il supporto migliorato di Java 8 integrato nella toolchain predefinita. Per maggiori informazioni, consulta la pagina Utilizzare le funzionalità del linguaggio Java 8.

• Aggiunto il supporto per l'esecuzione di test con Android Test Orchestrator, che consente di eseguire ogni test dell'app all'interno della propria chiamata a Instrumentation. Poiché ogni test viene eseguito nella propria istanza di strumentazione, gli stati condivisi tra i test non si accumulano sulla CPU o sulla memoria del dispositivo. Inoltre, anche se un test si arresta in modo anomalo, rimuove solo la propria istanza di Instrumentation, quindi gli altri test continuano a essere eseguiti.

  • È stato aggiunto testOptions.execution per determinare se utilizzare l'orchestrazione dei test sul dispositivo. Se vuoi utilizzare Android Test Orchestrator, devi specificare ANDROID_TEST_ORCHESTRATOR, come mostrato di seguito. Per impostazione predefinita, questa proprietà è impostata su HOST, il che disattiva l'orchestrazione on-device ed è il metodo standard per l'esecuzione dei test.

  trendy

          android {
            testOptions {
              execution 'ANDROID_TEST_ORCHESTRATOR'
            }
          }
          

  Kotlin

          android {
            testOptions {
              execution = "ANDROID_TEST_ORCHESTRATOR"
            }
          }
          

• La nuova configurazione delle dipendenze androidTestUtil consente di installare un altro APK di supporto di test prima di eseguire i test di strumentazione, ad esempio Android Test Orchestrator:

  trendy

          dependencies {
            androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
            ...
          }
          

  Kotlin

          dependencies {
            androidTestUtil("com.android.support.test:orchestrator:1.0.0")
            ...
          }
          

• È stato aggiunto testOptions.unitTests.includeAndroidResources per supportare i test delle unità che richiedono risorse Android, ad esempio Roboelectric. Quando imposti questa proprietà su true, il plug-in esegue l'unione di risorse, asset e manifest prima di eseguire i test delle unità. I test possono quindi controllare com/android/tools/test_config.properties sul classpath per verificare la presenza delle seguenti chiavi:

  • android_merged_assets: il percorso assoluto alla directory degli asset uniti.

    Nota: per i moduli della libreria, le risorse unite non contengono gli asset delle dipendenze (vedi il problema n. 65550419).

  • android_merged_manifest: il percorso assoluto al file manifest unito.

  • android_merged_resources: il percorso assoluto alla directory delle risorse unite, che contiene tutte le risorse del modulo e tutte le sue dipendenze.

  • android_custom_package: il nome del pacchetto della classe R finale. Se modifichi l'ID applicazione in modo dinamico, il nome del pacchetto potrebbe non corrispondere all'attributo package nel file manifest dell'app.

• Supporto per i caratteri come risorse (una nuova funzionalità introdotta in Android 8.0 (livello API 26)).
• Supporto di APK specifici per lingua con SDK per app istantanee Android 1.1 e versioni successive.

• Ora puoi modificare la directory di output per il progetto di build nativo esterno, come mostrato di seguito:

  trendy

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory "./outputs/cmake"
                  }
              }
          }
          

  Kotlin

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory = "./outputs/cmake"
                  }
              }
          }
          

• Ora puoi utilizzare CMake 3.7 o versioni successive per la creazione di progetti nativi da Android Studio.

• La nuova configurazione delle dipendenze lintChecks consente di creare un JAR che definisce le regole di lint personalizzate e di pacchettizzarlo nei progetti AAR e APK.

  Le regole lint personalizzate devono appartenere a un progetto separato che restituisce un singolo JAR e include solo le dipendenze compileOnly. Altri moduli di app e librerie possono quindi dipendere dal progetto lint utilizzando la configurazione lintChecks:

  trendy

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks project(':lint-checks')
          }
          

  Kotlin

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks(project(":lint-checks"))
          }
          

Modifiche del comportamento

• Il plug-in Android 3.0.0 rimuove determinate API e, se le utilizzi, la tua build si interromperà se le utilizzi. Ad esempio, non puoi più utilizzare l'API Variants per accedere agli oggetti outputFile() o utilizzare processManifest.manifestOutputFile() per ottenere il file manifest per ogni variante. Per scoprire di più, consulta la sezione Modifiche alle API.
• Non è più necessario specificare una versione per gli strumenti di creazione (quindi, ora puoi rimuovere la proprietà android.buildToolsVersion). Per impostazione predefinita, il plug-in utilizza automaticamente la versione minima degli strumenti di creazione richiesta per la versione del plug-in Android in uso.
• Ora attivi/disattivi l'elaborazione dei contenuti PNG nel blocco buildTypes, come mostrato di seguito. Il crunching PNG è abilitato per impostazione predefinita per tutte le build, ad eccezione di quelle di debug, perché aumenta i tempi di creazione per i progetti che includono molti file PNG. Quindi, per migliorare i tempi di compilazione per altri tipi di build, devi disattivare il crunching dei file PNG o convertire le tue immagini in WebP.

  trendy

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              crunchPngs false
            }
          }
        }
        

  Kotlin

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              isCrunchPngs = false
            }
          }
        }
        

• Il plug-in Android ora crea automaticamente target eseguibili che configuri nei progetti CMake esterni.
• Ora devi aggiungere processori di annotazione al percorso della classe del processore utilizzando la configurazione delle dipendenze annotationProcessor.
• L'utilizzo della versione deprecata ndkCompile è ora più limitata. Dovresti invece eseguire la migrazione a CMake o a ndk-build per compilare il codice nativo che vuoi pacchettizzare nel tuo APK. Per scoprire di più, consulta Eseguire la migrazione da ndkcompile.