Android Gradle Plugin 4.0.0 (aprile 2020)

Questa versione del plug-in Android richiede i seguenti requisiti:

• Gradle 6.1.1. Per saperne di più, leggi la sezione sull'aggiornamento di Gradle.

• SDK Build Tools 29.0.2 o versioni successive.

Nuove funzionalità

Questa versione del plug-in Android per Gradle include le nuove funzionalità riportate di seguito.

Supporto per Android Studio Build Analyzer

La finestra Strumento di analisi Crea ti consente di comprendere e diagnosticare i problemi relativi al tuo di un processo di compilazione, ad esempio le ottimizzazioni disattivate e le attività non configurate correttamente. Questa funzionalità è disponibile se utilizzi Android Studio 4.0 e versioni successive con Plug-in Android per Gradle 4.0.0 e versioni successive. Puoi aprire lo Strumento di analisi build da Android Studio, nel seguente modo:

1. Se non l'hai ancora fatto, crea la tua app selezionando Crea > Marca Project dalla barra dei menu.
2. Seleziona Visualizza > Finestre degli strumenti > Crea sulla barra dei menu.
3. Nella finestra Crea, apri la finestra Analizzatore build in una delle nei seguenti modi:
   .
   • Dopo che Android Studio ha completato la creazione del tuo progetto, fai clic sul pulsante Crea Strumento di analisi.
   • Al termine della creazione del progetto in Android Studio, fai clic sul link sul lato destro della finestra Output build.

La finestra Analizzatore build organizza i possibili problemi di build in una struttura ad albero nella rimanenti. Puoi esaminare e fare clic su ciascun problema per esaminarne i dettagli nel riquadro sulla destra. Quando Android Studio analizza la build, calcola il set di attività che hanno determinato la durata della build e fornisce una visualizzazione ti aiutano a comprendere l'impatto di ciascuna di queste attività. Puoi anche ottenere dettagli sugli avvisi espandendo il nodo Warnings.

Per saperne di più, consulta Identificare le regressioni della velocità di compilazione.

Desugaring della libreria Java 8 in D8 e R8

Il plug-in Android per Gradle ora supporta l'utilizzo di una serie di Java 8 API senza richiedere un livello API minimo per la tua app.

Attraverso una procedura chiamata desugaring, il compilatore DEX D8 in Android Studio La versione 3.0 e successive fornivano già un supporto sostanziale per le funzionalità del linguaggio Java 8 (ad esempio espressioni lambda, metodi di interfaccia predefiniti, test con risorse e altro ancora). In Android Studio 4.0, il motore di desugaring è stato esteso per consentire per eliminare le API del linguaggio Java. Ciò significa che ora puoi includere API di linguaggio disponibili solo nelle release recenti di Android (come java.util.streams) nelle app che supportano versioni precedenti di Android.

In questa release è supportato il seguente set di API:

• Stream sequenziali (java.util.stream)
• Un sottoinsieme di java.time
• java.util.function
• Aggiunte recenti a java.util.{Map,Collection,Comparator}
• Facoltativo (java.util.Optional, java.util.OptionalInt e java.util.OptionalDouble) e alcuni altri nuovi corsi utili con quanto indicato sopra API
• Alcune aggiunte a java.util.concurrent.atomic (nuovi metodi su AtomicInteger, AtomicLong e AtomicReference)
• ConcurrentHashMap (con correzioni di bug per Android 5.0)

Per supportare queste API di linguaggio, D8 compila un file DEX di libreria separato che contiene un'implementazione delle API mancanti e la include nella tua app. La il processo di desugaring riscrive il codice della tua app per usare questa libreria all'indirizzo runtime.

Per abilitare il supporto di queste API dei linguaggi, includi quanto segue nel File build.gradle di modulo app:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }


compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled true
    // Sets Java compatibility to Java 8
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4'
}

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }


compileOptions {
    // Flag to enable support for the new language APIs
    isCoreLibraryDesugaringEnabled = true
    // Sets Java compatibility to Java 8
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4")
}

Tieni presente che potrebbe essere necessario includere anche lo snippet di codice riportato sopra in una file build.gradle del modulo libreria se

• I test strumenti del modulo libreria utilizzano queste API dei linguaggi ( direttamente o tramite il modulo della libreria o le sue dipendenze). Questo avviene di modo le API mancanti sono fornite per l'APK di test instrumentato.

• Vuoi eseguire lint sul modulo della libreria in modo isolato. Per aiutarti lint riconosce gli utilizzi validi delle API del linguaggio ed evita di segnalare i falsi positivi avvisi.

Nuove opzioni per abilitare o disabilitare le funzionalità della build

Il plug-in Android per Gradle 4.0.0 introduce un nuovo modo per controllare quali funzionalità di sviluppo da attivare e disattivare, come Associazione vista e Associazione dati. Quando vengono aggiunte nuove funzionalità, queste vengono disattivate per impostazione predefinita. Puoi puoi usare il blocco buildFeatures per attivare solo le funzionalità che vuoi. ti aiuta a ottimizzare le prestazioni della build per il tuo progetto. Puoi impostare opzioni per ciascun modulo nel file build.gradle a livello di modulo, come segue:

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

Puoi anche specificare l'impostazione predefinita per queste funzionalità in tutti i moduli in un progetto includendo uno o più dei seguenti elementi nella gradle.properties, come mostrato di seguito. Tieni presente che puoi sempre utilizzare buildFeatures blocco nel file build.gradle a livello di modulo per eseguire l'override di questi impostazioni predefinite a livello di progetto.

android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true

Dipendenze feature-on-feature

Nelle versioni precedenti del plug-in Android Gradle, tutti i moduli delle funzionalità potrebbe dipendere solo dal modulo di base dell'app. Quando si utilizza il plug-in Android Gradle 4.0.0, ora è possibile includere un modulo di funzionalità che dipende da un'altra funzionalità in maggior dettaglio più avanti in questo modulo. Ciò significa che una funzionalità :video può dipendere da Funzionalità :camera, che dipende dal modulo di base, come mostrato come mostrato nella figura seguente.

Il modulo della funzionalità :video dipende dalla funzionalità :camera, che dipende dal modulo :app di base.

Ciò significa che quando la tua app richiede il download di un modulo di funzionalità, scarica anche altri moduli di funzionalità da cui dipende. Dopo creazione moduli delle funzionalità per la tua app, puoi dichiarare una dipendenza tra funzionalità build.gradle file. Ad esempio, il modulo :video dichiara una dipendenza :camera come segue:

// In the build.gradle file of the ':video' module.
dependencies {
  // All feature modules must declare a dependency
  // on the base module.
  implementation project(':app')
  // Declares that this module also depends on the 'camera'
  // feature module.
  implementation project(':camera')
  ...
}

// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation(project(":camera"))
    ...
}

Inoltre, devi abilitare la funzione di dipendenza di funzionalità Android Studio (per supportare la funzionalità durante la modifica della configurazione di esecuzione, ad esempio) facendo clic su Guida > Modifica le opzioni VM personalizzate dalla barra dei menu e tra cui:

-Drundebug.feature.on.feature=true

Metadati delle dipendenze

Quando crei la tua app utilizzando il plug-in Android Gradle 4.0.0 e versioni successive, il plug-in include i metadati che descrivono le dipendenze compilate dell'app. Durante il caricamento dell'app, Play Console controlla questi metadati per fornire che ti offre i seguenti vantaggi:

• Ricevi avvisi per problemi noti relativi agli SDK e alle dipendenze utilizzate dalla tua app
• Ricevi feedback utili per risolvere questi problemi

I dati sono compressi, criptati da una chiave di firma di Google Play e archiviati in il blocco di firma della release dell'app. Tuttavia, puoi esaminare i metadati nei file di build intermedi locali nella directory seguente: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

Se preferisci non condividere queste informazioni, puoi disattivarle includendo il nel file build.gradle del tuo modulo:

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}

Importa librerie native dalle dipendenze AAR

Ora puoi importare le librerie C/C++ dalle dipendenze AAR dell'app. Quando segui i passaggi di configurazione descritte di seguito, Gradle rende automaticamente disponibili queste librerie native con il tuo sistema di compilazione nativo esterno, come CMake. Tieni presente che solo Gradle rende disponibili queste librerie per la tua build; devi comunque configurare creare script per utilizzarli.

Le librerie vengono esportate utilizzando il formato del pacchetto Prefab.

Ogni dipendenza può esporre al massimo un pacchetto Prefab, che comprende uno o più moduli. Un modulo Prefab è una singola libreria, che può essere una una libreria condivisa, statica o con solo intestazioni.

In genere, il nome del pacchetto corrisponde al nome dell'artefatto Maven e al nome del modulo corrisponde al nome della libreria, ma non è sempre così. Perché devi sapere il nome del pacchetto e del modulo delle librerie, potresti dover consultare documentazione delle dipendenze per determinare quali sono questi nomi.

Configura il tuo sistema di compilazione nativo esterno

Per vedere i passaggi da seguire, segui la procedura per il sistema di compilazione nativo esterno che intendi utilizzare.

Ognuna delle dipendenze AAR dell'app che include il codice nativo espone una Android.mk che devi importare nel progetto ndk-build. Importi questo file utilizzando il comando import&endash;module, che cerca i percorsi specifica utilizzando la proprietà import&endash;add&endash;path nel progetto ndk-build. Per Ad esempio, se la tua applicazione definisce libapp.so e utilizza curl, deve includere quanto segue nel file Android.mk:

1. Per CMake:

   add_library(app SHARED app.cpp)
   
   
   # Add these two lines.
   find_package(curl REQUIRED CONFIG)
   target_link_libraries(app curl::curl)

2. Per ndk-build:

   include $(CLEAR_VARS)
   LOCAL_MODULE := libapp
   LOCAL_SRC_FILES := app.cpp
   # Link libcurl from the curl AAR.
   LOCAL_SHARED_LIBRARIES := curl
   include $(BUILD_SHARED_LIBRARY)
   
   
   # If you don't expect that your project will be built using versions of the NDK
   # older than r21, you can omit this block.
   ifneq ($(call ndk-major-at-least,21),true)
       $(call import-add-path,$(NDK_GRADLE_INJECTED_IMPORT_PATH))
   endif
   
   # Import all modules that are included in the curl AAR.
   $(call import-module,prefab/curl)

Le dipendenze native incluse in un AAR sono esposte al progetto CMake tramite CMake_FIND_ROOT_PATH{: .external}. Questo valore verrà impostato automaticamente da Gradle quando CMake è richiamato, quindi se il tuo sistema di compilazione modifica questa variabile, assicurati di aggiungere piuttosto che assegnarle.

Ogni dipendenza espone un pacchetto-file di configurazione{: .external} alla tua build CMake, che puoi importalo con il comando find_package{: .external}. Questo comando cerca il file di configurazione pacchetti che corrispondono al nome e alla versione del pacchetto specificati e ne mostrano le destinazioni da utilizzare nella build. Ad esempio, se la tua applicazione definisce libapp.so e utilizza curl, devi includere quanto segue nella CMakeLists.txt file:

add_library(app SHARED app.cpp)


# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)

Ora puoi specificare #include "curl/curl.h" in app.cpp. Quando crei il progetto, il sistema di compilazione nativo esterno collega automaticamente libapp.so rispetto a libcurl.so e ai pacchetti libcurl.so nell'APK o nell'app bundle. Per per ulteriori informazioni, consulta l'esempio di prefab curl{:.external}.

Cambiamenti del comportamento

Quando utilizzi questa versione del plug-in, potresti riscontrare le seguenti modifiche il loro comportamento.

Aggiornamenti della configurazione della firma v1/v2

Il comportamento per le configurazioni della firma dell'app nel blocco signingConfig è modificato nel seguente modo:

firma v1

• Se v1SigningEnabled è abilitato esplicitamente, AGP esegue la firma dell'app v1.
• Se v1SigningEnabled viene disattivato esplicitamente dall'utente, la firma dell'app v1 viene non eseguito.
• Se l'utente non ha abilitato esplicitamente la firma v1, la firma può essere eseguita automaticamente disattivata in base a minSdk e targetSdk.

firma v2

• Se v2SigningEnabled è abilitato esplicitamente, AGP esegue la firma dell'app v2.
• Se v2SigningEnabled viene disattivato esplicitamente dall'utente, la firma dell'app v2 viene non eseguito.
• Se l'utente non ha abilitato esplicitamente la firma v2, può essere eseguito automaticamente disattivata in base a targetSdk.

Queste modifiche consentono ad AGP di ottimizzare le build disattivando il meccanismo di firma a seconda che l'utente abbia abilitato esplicitamente questi flag. Prima di questa è stato possibile disabilitare v1Signing anche quando in modo esplicito attivati, il che potrebbe generare confusione.

Plug-in Android per Gradle feature e instantapp rimossi

Il plug-in Android Gradle 3.6.0 ha deprecato il plug-in Feature (com.android.feature) e il plug-in dell'app istantanea (com.android.instantapp) in preferisce usare il plug-in Dynamic Feature (com.android.dynamic-feature) per creare e pacchettizzare app istantanee con Android App Bundle.

Nel plug-in Android per Gradle 4.0.0 e versioni successive, questi plug-in ritirati sono rimosso completamente. Quindi, per utilizzare il plug-in Android Gradle più recente, dovete eseguire la migrazione l'app istantanea per supportare l'app per Android Pacchetti. Se esegui la migrazione delle app istantanee, puoi sfruttare i vantaggi dell'app bundle e semplificare la struttura modulare dell'app la progettazione.

Nota: per aprire i progetti che utilizzano i plug-in rimossi in Android Studio 4.0 e versioni successive, il progetto deve utilizzare il plug-in Android Gradle 3.6.0 o versioni precedenti.

Funzionalità di elaborazione delle annotazioni separata rimossa

La possibilità di separare l'elaborazione delle annotazioni in un'attività dedicata è rimosso. Questa opzione era utilizzata per mantenere la compilazione Java incrementale quando i processori di annotazione non incrementali vengono utilizzata in progetti solo Java; è stato attivato impostando Da android.enableSeparateAnnotationProcessing a true nel gradle.properties, che non funziona più.

Devi invece eseguire la migrazione all'utilizzo dell'annotazione incrementale processori per migliorare per creare le prestazioni.

Il campo includeCompileClasspath è deprecato

Il plug-in Android per Gradle non controlla più o non include più processori di annotazione che hai dichiarato nel classpath di compilazione annotationProcessorOptions.includeCompileClasspath proprietà DSL non ha più qualsiasi effetto. Se includi processori di annotazione nel classpath di compilazione, potrebbe visualizzare il seguente errore:

Error: Annotation processors must be explicitly declared now.

Per risolvere il problema, devi includere processori di annotazione nel tuo build.gradle file che utilizzano la configurazione delle dipendenze annotationProcessor. Per saperne di più, consulta Aggiungere un'annotazione processori.

Pacchettizzazione automatica delle dipendenze predefinite utilizzato da CMake

Le versioni precedenti del plug-in Android Gradle richiedevano esplicitamente creare pacchetti delle librerie predefinite utilizzate dalla build nativa esterna di CMake utilizzando jniLibs. Potrebbero essere presenti librerie src/main/jniLibs del modulo o, se possibile, in alcune altra directory configurata nel tuo file build.gradle:

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.srcDirs = ['libs']
  }
}

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.setSrcDirs(listOf("libs"))
  }
}

Con il plug-in Android Gradle 4.0, la configurazione descritta sopra non è più necessaria e darà luogo a un errore della build:

* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
  > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
    > More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

La build nativa esterna ora pacchettizza automaticamente librerie, quindi, se pacchettizza in modo esplicito la libreria con jniLibs, viene generato duplicati. Per evitare l'errore di generazione, sposta la libreria predefinita in una posizione esterno a jniLibs o rimuovi la configurazione jniLibs da build.gradle .

Problemi noti

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

Condizione della gara nel meccanismo worker Gradle

Alcune modifiche al plug-in Android per Gradle 4.0 possono attivare una condizione di gara in Gradle quando viene eseguito con &endash;&endash;no&endash;daemon e versioni di Gradle 6.3 o versioni precedenti, con conseguente il blocco delle build al termine della build.

Questo problema verrà risolto in Gradle 6.4.