Mastering Gradle per Android: attività Gradle e Kotlin

Contenuto

Esplorazione dei file di build Gradle
1. settings.gradle
2. build.gradle (livello di progetto)
3. build.gradle (livello modulo)
Dichiarare le dipendenze del progetto: biblioteche locali
Aggiunta di una dipendenza build: repository remoti
Connessione a un repository remoto
Dichiarazione di una dipendenza remota
Generazione di più APK: come creare varianti di build
Creazione di un'attività Gradle personalizzata
Costruisci il tuo progetto con il wrapper Gradle
Quali altre attività di Gradle sono disponibili?
Ottenere di più da Gradle: aggiungere plugin
The Gradle Kotlin DSL
Avvolgendo

Invece di Java, XML o Kotlin, questi file di build Gradle utilizzano il linguaggio specifico di dominio (DSL) basato su Groovy. Se non hai familiarità con Groovy, daremo uno sguardo riga per riga a ciascuno di questi file di build Gradle, quindi alla fine di questo articolo ti sentirai a tuo agio con la lettura e la scrittura di un semplice codice Groovy.

Gradle mira a semplificarti la vita, fornendo una serie di impostazioni predefinite che puoi spesso utilizzare con una configurazione manuale minima: quando sei pronto per costruire il tuo progetto, premi semplicemente il pulsante "Esegui" di Android Studio e Gradle inizierà il processo di creazione per te.

Nonostante l'approccio "convenzione sulla configurazione" di Gradle, se le sue impostazioni predefinite non soddisfano pienamente le tue esigenze, puoi personalizzare, configurare ed estendere il processo di compilazione e persino modificare le impostazioni di Gradle per eseguire attività molto specifiche.

Poiché gli script Gradle sono contenuti nei propri file, è possibile modificare il processo di creazione dell'applicazione in qualsiasi momento, senza dover toccare il codice sorgente dell'applicazione. In questo tutorial, modificheremo il processo di compilazione utilizzando sapori, varianti di build e un'attività Gradle personalizzata, il tutto senza mai toccando il nostro codice dell'applicazione.

Esplorazione dei file di build Gradle

Ogni volta che crei un progetto, Android Studio genererà la stessa raccolta di file di build Gradle. Anche se importi un progetto esistente in Android Studio, lo farà ancora crea questi stessi file Gradle e aggiungili al tuo progetto.

Per iniziare a comprendere meglio Gradle e la sintassi Groovy, diamo un'occhiata riga per riga a ciascuno dei file di build Gradle di Android.

1. settings.gradle

Il file settings.gradle è il punto in cui definirai tutti i moduli dell'applicazione in base al nome, utilizzando la parola chiave "include". Ad esempio, se avessi un progetto costituito da una "app" e un "secondModule", il tuo file settings.gradle sarebbe simile a questo:

include: app,: secondmodule rootProject.name = MyProject

A seconda delle dimensioni del progetto, questo file potrebbe essere notevolmente più lungo.

Durante il processo di compilazione, Gradle esaminerà i contenuti del file settings.gradle del progetto e identificherà tutti i moduli che deve includere nel processo di compilazione.

2. build.gradle (livello di progetto)

Il file build.gradle a livello di progetto si trova nella directory principale del progetto e contiene le impostazioni a cui verrà applicato tutti i tuoi moduli (detti anche "progetti" di Gradle).

È necessario utilizzare questo file per definire eventuali plug-in, repository, dipendenze e opzioni di configurazione applicabili a tutti i moduli del progetto Android. Si noti che se si definiscono attività Gradle all'interno del file build.gradle a livello di progetto, è ancora possibile sovrascrivere o estendere queste attività per i singoli moduli, modificando le corrispondenti a livello di modulo file build.gradle.

Un tipico file build.gradle a livello di progetto sarà simile al seguente:

buildscript {repository {google () jcenter ()} dipendenze {classpath com.android.tools.build:gradle:3.5.0-alpha06 // NOTA: non inserire qui le dipendenze dell'applicazione; appartengono // nel singolo modulo build.gradle files}} allprojects {repository {google () jcenter ()}} task clean (tipo: Delete) {delete rootProject.buildDir}

Questo file build.gradle a livello di progetto è diviso nei seguenti blocchi:

Buildscript. Questo contiene le impostazioni necessarie per eseguire la compilazione.
Repository. Gradle è responsabile di individuare le dipendenze del progetto e renderle disponibili nella build. Tuttavia, non tutte le dipendenze provengono dallo stesso repository, quindi dovrai definire tutti i repository che Gradle dovrebbe cercare, al fine di recuperare le dipendenze del tuo progetto.
Dipendenze. Questa sezione contiene le dipendenze del plug-in, che vengono scaricate e archiviate nella cache locale. Dovresti non definire eventuali dipendenze del modulo all'interno di questo blocco.
Allprojects. Qui è dove definirai i repository che dovrebbero essere disponibili tutti dei moduli del tuo progetto.

3. build.gradle (livello modulo)

Questo è il file build.gradle a livello di modulo, che è presente in ogni modulo del progetto. Se il tuo progetto Android è costituito da più moduli, sarà composto anche da più file build.gradle a livello di modulo.

Ogni file build.gradle a livello di modulo contiene il nome del pacchetto del progetto, il nome della versione e il codice della versione, oltre all'SDK minimo e di destinazione per questo particolare modulo.

Un file build.gradle a livello di modulo può anche avere un proprio set univoco di istruzioni di compilazione e dipendenze. Ad esempio, se stai creando un'applicazione con un componente Wear OS, il tuo progetto Android Studio consisterà in un modulo smartphone / tablet separato e un modulo Wear - poiché sono destinati a dispositivi completamente diversi, questi moduli hanno drasticamente diversi dipendenze!

Un file build.gradle di base a livello di modulo avrà in genere un aspetto simile al seguente:

applica plug-in: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCodice 1 versioneName "1.0" testInstrumentationRunner "androidx.test.prn" getDefaultProguardFile (proguard-android-optimise.txt), proguard-rules.pro}}} dipendenze {implementazione fileTree (dir: libs, include:) implementazione androidx.appcompat: appcompat: 1.0.2 implementazione androidx.constraintlayout: limitativo: 1.1. 3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Diamo un'occhiata più da vicino a ciascuna di queste sezioni:

applica plugin. Questo è un elenco dei plugin richiesti per compilare questo modulo. Il plug-in com.android.application è necessario per configurare il processo di generazione specifico di Android, quindi viene aggiunto automaticamente.
Android. Qui è dove dovresti posizionare tutte le opzioni specifiche della piattaforma del modulo.
compileSdkVersion. Questo è il livello API con cui viene compilato questo modulo. Non è possibile utilizzare funzionalità di un'API superiore a questo valore.
buildToolsVersion. Questo indica la versione del compilatore. In Gradle 3.0.0 e versioni successive, buildToolsVersion è facoltativo; se non specifichi un valore buildToolsVersion, Android Studio passerà automaticamente alla versione più recente di Build Tools.
defaultconfig. Questo contiene opzioni che verranno applicate a tutte le versioni di build dell'app, come il debug e le versioni di rilascio.
ID applicazione. Questo è l'identificatore univoco dell'applicazione.
minSdkVersion. Questo parametro definisce il livello API più basso supportato da questo modulo.
targetSdkVersion. Questo è il livello API massimo per il quale l'applicazione è stata testata. Idealmente, è necessario testare l'applicazione utilizzando l'API più recente, il che significa che il valore targetSdkVersion sarà sempre uguale al valore compileSdkVersion.
versionCode. Questo è un valore numerico per la versione dell'applicazione.
versionName. Questa è una stringa intuitiva, che rappresenta la versione dell'applicazione.
buildTypes. Per impostazione predefinita, Android supporta due tipi di build: debug e rilascio. Puoi utilizzare i blocchi "debug" e "release" per specificare le impostazioni specifiche del tipo di applicazione.
dipendenze. Qui è dove definirai qualsiasi libreria da cui dipende questo modulo.

Dichiarare le dipendenze del progetto: biblioteche locali

Puoi rendere disponibili funzionalità aggiuntive per i tuoi progetti Android, aggiungendo una o più dipendenze di progetto. Queste dipendenze possono essere locali o possono essere archiviate in un repository remoto.

Per dichiarare una dipendenza da un file JAR locale, dovrai aggiungere quel JAR alla directory "libs" del tuo progetto.

È quindi possibile modificare il file build.gradle a livello di modulo per dichiarare una dipendenza da questo file. Ad esempio, qui stiamo dichiarando una dipendenza da un JAR "mylibrary".

file di implementazione (libs / mylibrary.jar)

In alternativa, se la cartella "libs" conteneva diversi JAR, potrebbe essere più semplice affermare semplicemente che il progetto dipende da tutti i file presenti nella cartella "libs", ad esempio:

fileTree di implementazione (dir: libs, include:)

Aggiunta di una dipendenza build: repository remoti

Se una libreria si trova in un repository remoto, dovrai completare i seguenti passaggi:

Definire il repository in cui si trova questa dipendenza.
Dichiarare la dipendenza individuale.

Connessione a un repository remoto

Il primo passo è dire a Gradle quale repository (o repository) deve controllare, al fine di recuperare tutte le dipendenze del progetto. Per esempio:

repository {google () jcenter ()}}

Qui, la linea "jcenter ()" assicura che Gradle controllerà il repository JCenter, che è un repository pubblico gratuito ospitato su bintray.

In alternativa, se tu o la tua organizzazione gestite un repository personale, allora dovreste aggiungere l'URL di questo repository alla vostra dichiarazione di dipendenza. Se il repository è protetto da password, dovrai fornire anche le informazioni di accesso, ad esempio:

repository {mavenCentral () maven {// Configura l'URL di destinazione // url "http://repo.mycompany.com/myprivaterepo"} maven {credenziali {username myUsername password myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Se una dipendenza è presente all'interno di più repository, Gradle selezionerà la versione "migliore" di questa dipendenza, in base a fattori quali l'età di ciascun repository e la versione statica.

Dichiarazione di una dipendenza remota

Il passaggio successivo è dichiarare la dipendenza nel file build.gradle a livello di modulo. Aggiungi queste informazioni al blocco "dipendenze", usando uno dei seguenti:

Implementazione. Questa è una dipendenza normale che ti serve ogni volta che costruisci il tuo progetto. Una dipendenza di "implementazione" sarà presente in tutto tutti le tue build.
Testimplementation. Questa è una dipendenza necessaria per compilare l'origine del test dell'applicazione ed eseguire test basati su JVM. Quando si contrassegna una dipendenza come "Testimplementation" Gradle saprà che non è necessario eseguire attività per questa dipendenza durante una generazione normale, il che può aiutare a ridurre i tempi di compilazione.
Androidtestimplementation. Questa è una dipendenza che è richiesta quando si eseguono test su un dispositivo, ad esempio il framework Espresso è una "implementazione di test Android" comune.

Definiamo una dipendenza remota, utilizzando una delle parole chiave sopra, seguita dal gruppo di dipendenza, dal nome e dagli attributi della versione, ad esempio:

dipendenze {implementazione fileTree (dir: libs, include:) implementazione androidx.appcompat: appcompat: 1.0.2 implementazione androidx.constraintlayout: limitintlayout: 1.1.3 testImplementation junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Generazione di più APK: come creare varianti di build

A volte, potrebbe essere necessario creare più versioni dell'applicazione. Ad esempio, potresti voler rilasciare una versione gratuita e una versione a pagamento, che include alcune funzionalità aggiuntive.

Questa è un'attività di compilazione che Gradle può aiutarti, quindi vediamo come modificare il processo di compilazione per creare più APK da un singolo progetto:

Apri il tuo file strings.xml ed elimina la stringa del nome dell'applicazione originale.
Successivamente, definire i nomi di ogni sapore del prodotto che si desidera creare; in questo caso, sto usando:

La mia app gratuita La mia app a pagamento

Apri il tuo file AndroidManifest.xml e sostituisci android: label = "@ string / app_name" con:

android: label = "$ {} appName"

Apri il tuo file build.gradle a livello di modulo e aggiungi quanto segue al blocco "android":

flavourDimensioni "mode" productFlavors {modalità {dimensione "gratuita" applicationIdSuffix ".free" manifestPlaceholders =} pagato {dimensione "modalità" applicationIdSuffix ".paid" manifestPlaceholders =}}}

Analizziamo cosa sta succedendo qui:

flavorDimensions. Il plug-in Android crea varianti di build combinando sapori di dimensioni diverse. Qui stiamo creando una dimensione di sapore composta da versioni "gratuite" e "a pagamento" della nostra app. Sulla base del codice sopra, Gradle genererà quattro varianti di build: paidDebug, paidRelease, freeDebug e freeRelease.
productFlavors. Questo specifica un elenco di sapori e relative impostazioni, che nel codice sopra riportato sono "a pagamento" e "gratuiti".
Gratuito / a pagamento. Questi sono i nomi dei nostri due gusti di prodotto.
Dimensione. Dobbiamo specificare un valore di parametro "dimensione"; in questo caso, sto usando "mode".
applicationIdSuffix. Poiché desideriamo creare più versioni della nostra app, dobbiamo assegnare a ciascun APK un identificatore univoco dell'app.
manifestPlaceholders. Ogni progetto ha un singolo file manifest contenente informazioni importanti sulla configurazione del progetto. Quando crei più varianti di build, in genere vorrai modificare alcune di queste proprietà manifest al momento della creazione. È possibile utilizzare i file di build Gradle per specificare voci manifest uniche per ciascuna variante di build, che verranno quindi inserite nel manifest in fase di compilazione. Nel codice sopra, stiamo modificando il valore di "appName" a seconda che Gradle stia creando la versione gratuita o a pagamento della nostra app.

Creazione di un'attività Gradle personalizzata

A volte potrebbe essere necessario personalizzare il processo di generazione, usando Gradle compiti.

Un'attività è una raccolta denominata di azioni che Gradle eseguirà mentre esegue una build, ad esempio la generazione di un Javadoc. Gradle supporta molte attività per impostazione predefinita, ma puoi anche creare attività personalizzate, che possono tornare utili se hai in mente un set molto specifico di istruzioni per la creazione.

In questa sezione, creeremo un'attività Gradle personalizzata che eseguirà l'iterazione di tutte le varianti di build del nostro progetto (paidDebug, paidRelease, freeDebug e freeRelease), creeremo una data e un timestamp, quindi aggiungere queste informazioni a ciascun APK generato.

Apri il tuo file build.gradle a livello di modulo e aggiungi quanto segue:

task addDateAndTime () {// Scorrere tutte le varianti di build dell'output // android.applicationVariants.all {variant -> // Scorrere tutti i file APK // variant.outputs.all {output -> // Creare un'istanza di la data e l'ora correnti, nel formato specificato // def dateAndTime = new Date (). format ("yyyy-MM-dd: HH-mm") // Aggiungi queste informazioni al nome file dell'APK // def fileName = variant. name + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

Quindi, dobbiamo dirlo a Gradle quando dovrebbe eseguire questa attività. Durante una build, Gradle identifica tutto ciò di cui ha bisogno per scaricare e tutte le attività che deve eseguire e le organizza in un Directed Acyclic Graph (DAG). Gradle eseguirà quindi tutte queste attività, secondo l'ordine definito nel suo DAG.

Per la mia app, userò il metodo "whenReady", che assicura che la nostra attività verrà chiamata una volta che il DAG è stato popolato e Gradle è pronto per iniziare a eseguire le sue attività.

Aggiungi quanto segue al tuo file build.gradle a livello di modulo:

// Esegui questa attività // gradle.taskGraph.whenReady {addDateAndTime}

Mettiamo il nostro compito personalizzato e il nostro codice di variante build per il test, costruendo questo progetto usando un comando Gradle.

Costruisci il tuo progetto con il wrapper Gradle

Emetti i comandi Gradle usando il wrapper Gradle ("gradlew"). Questo script è il modo preferito per avviare una build Gradle, in quanto rende l'esecuzione della build indipendente dalla tua versione di Gradle. Questa separazione può essere utile se stai collaborando con altri che potrebbero non avere necessariamente la stessa versione di Gradle installata.

Quando si emettono i comandi del wrapper Gradle, si utilizzerà "gradlew" per sistemi operativi simili a Unix, inclusi macOS, e "gradlew.bat" per Windows. Ho un Mac, quindi userò i comandi "gradlew".

Puoi eseguire i comandi Gradle dall'interno di Android Studio:

Nella barra degli strumenti di Android Studio, seleziona "Visualizza> Strumenti Windows> Terminale". Questo apre un pannello Terminale nella parte inferiore della finestra IDE.
Immettere il seguente comando nel Terminale:

./gradlew build

Android Studio dovrebbe assomigliare a questo:

Premi il tasto "Invio" sulla tastiera. Gradle ora costruirà il tuo progetto.

Gradle memorizza tutti gli APK generati nella directory app / build / output / apk del tuo progetto, quindi vai a questa directory. La cartella "APK" dovrebbe contenere diverse cartelle e sottocartelle; assicurarsi che Gradle abbia generato un APK per ciascuna delle varianti di build e che le informazioni di data e ora siano state aggiunte a ciascun file.

Quali altre attività di Gradle sono disponibili?

Oltre alle attività personalizzate che è possibile creare, Gradle supporta un elenco di attività predefinite immediatamente disponibili. Se sei curioso di vedere esattamente quali attività sono disponibili, allora:

Apri la finestra Terminale di Android Studio, se non è già aperta (selezionando "Visualizza> Strumenti Windows> Terminale" dalla barra degli strumenti di Android Studio).
Digitare quanto segue nel Terminale:

./gradlew -q task

Premi il tasto "Invio" sulla tastiera.

Questa attività "attività" verrà ora eseguita e dopo alcuni istanti il Terminale mostrerà un elenco di tutte le attività disponibili per questo progetto, completo di una breve descrizione di ciascuna attività.

Ottenere di più da Gradle: aggiungere plugin

Gradle viene fornito con un numero di plug-in preinstallati, ma è possibile estendere ulteriormente Gradle aggiungendo nuovi plug-in. Questi plugin rendono disponibili nuove attività per i tuoi progetti Android, ad esempio il plug-in Java include attività che ti consentono di compilare il codice sorgente Java, eseguire unit test e creare un file JAR, come "compileJava", "compileText", "jar" "Javadoc" e "pulito".

Per applicare un plugin, aggiungi la dichiarazione "applica plugin" al tuo file build.gradle a livello di modulo, seguito dal nome del plugin. Ad esempio, qui stiamo applicando il plug-in Java:

applica plugin: java

Se sei curioso di vedere quali plug-in sono disponibili, dai un'occhiata alla ricerca dei plug-in Gradle, che fornisce un registro completo dei plug-in Gradle.

The Gradle Kotlin DSL

Per impostazione predefinita, scriverai i tuoi script di build Gradle utilizzando Groovy DSL, ma se sei uno dei tanti sviluppatori che hanno adottato Kotlin per lo sviluppo Android, potresti preferire invece scrivere i tuoi script di build in Kotlin.

A differenza di Groovy, Kotlin è un linguaggio di programmazione tipicamente statico, quindi se si effettua il passaggio, i file di compilazione saranno compatibili con le funzioni di completamento automatico e di navigazione del codice sorgente di Android Studio. Inoltre, passare da Groovy a Kotlin significa che utilizzerai lo stesso linguaggio di programmazione nel tuo progetto, il che può rendere lo sviluppo più semplice, in particolare se non conosci troppo Groovy!

Se vuoi iniziare a scrivere la tua logica di costruzione in Kotlin, dovrai impostare il DSL Gradle Kotlin e seguire le istruzioni nella guida alla migrazione.

Avvolgendo

In questo articolo, abbiamo esplorato lo strumento di gestione dell'automazione e della dipendenza di Android Studio. Abbiamo esaminato il modo in cui Gradle automatizza il processo di compilazione e come è possibile modificarlo modificando i file di compilazione del progetto, inclusa la creazione di attività Gradle personalizzate e la generazione di più varianti di compilazione da un singolo progetto.

Hai esteso Gradle per automatizzare altre parti del processo di generazione di Android? Fateci sapere nei commenti qui sotto!