Mastering Gradle for Android: Gradle-oppgaver og Kotlin

Innhold

Utforske Gradle bygge filer
1. settings.gradle
2. build.gradle (prosjektnivå)
3. build.gradle (modulenivå)
Å erklære prosjektets avhengigheter: Lokale biblioteker
Legge til en byggeavhengighet: Fjernlager
Koble til et fjernlager
Å erklære en ekstern avhengighet
Genererer flere APK-er: Hvordan lage build-varianter
Opprette en tilpasset Gradle-oppgave
Bygg prosjektet ditt med Gradle wrapper
Hvilke andre Gradle-oppgaver er tilgjengelige?
Få mer ut av Gradle: Legge til plugins
The Gradle Kotlin DSL
Innpakking

I stedet for Java, XML eller Kotlin, bruker disse Gradle build-filene det Groovy-baserte domenespesifikke språket (DSL). Hvis du ikke er kjent med Groovy, tar vi en titt på linje for hver av disse Gradle build-filene, så mot slutten av denne artikkelen vil du være komfortabel med å lese og skrive enkel Groovy-kode.

Gradle tar sikte på å gjøre livet ditt enklere, ved å tilby et sett med standardinnstillinger som du ofte kan bruke med minimum manuell konfigurasjon - når du er klar til å bygge et prosjekt, trykker du bare på "Android" -knappen "Run" og Gradle starter byggeprosessen. for deg.

Til tross for Gradle's "konvensjon over konfigurasjon" -tilnærming, hvis standardinnstillingene ikke helt oppfyller dine behov, kan du tilpasse, konfigurere og utvide byggeprosessen og til og med finpusse Gradle-innstillingene for å utføre helt spesifikke oppgaver.

Siden Gradle-skriptene er inneholdt i sine egne filer, kan du når som helst endre søknadens byggeprosess uten å måtte berøre programmets kildekode. I denne opplæringen skal vi endre byggeprosessen ved å bruke smaker, bygge varianter og en tilpasset Gradle-oppgave - alt uten noensinne berører applikasjonskoden vår.

Utforske Gradle bygge filer

Hver gang du oppretter et prosjekt, vil Android Studio generere den samme samlingen av Gradle build-filer. Selv om du importerer et eksisterende prosjekt til Android Studio, vil det fortsatt lag nøyaktig de samme Gradle-filene, og legg dem til prosjektet ditt.

For å begynne å få en bedre forståelse av Gradle og Groovy-syntaks, la oss se litt etter en linje på hver av Android's Gradle build-filer.

1. settings.gradle

Settings.gradle-filen er der du vil definere alle programmets moduler med navn ved å bruke søkeordet "include". Hvis du for eksempel hadde et prosjekt bestående av en "app" og en "secondModule", ville innstillingene.gradelfilen din se slik ut:

inkluderer: app,: secondmodule rootProject.name = MyProject

Avhengig av størrelsen på prosjektet ditt, kan denne filen være betydelig lenger.

Under byggeprosessen vil Gradle undersøke innholdet i prosjektets settings.gradle-fil og identifisere alle modulene som den trenger å inkludere i byggeprosessen.

2. build.gradle (prosjektnivå)

Build.gradle-filen på prosjektnivå er lokalisert i prosjektets rotkatalog og inneholder innstillinger som vil bli brukt på alle modulene dine (også kalt “prosjekter” av Gradle).

Du bør bruke denne filen til å definere eventuelle plugins, depoter, avhengigheter og konfigurasjonsalternativer som gjelder for hver modul i hele Android-prosjektet ditt. Merk at hvis du definerer noen Gradle-oppgaver i build.gradle-filen på prosjektnivå, er det fortsatt mulig å overstyre eller utvide disse oppgavene for individuelle moduler ved å redigere de tilsvarende modulnivå build.gradle-fil.

En typisk build.gradle-fil på prosjektnivå vil se slik ut:

buildscript {repositories {google () jcenter ()} avhengigheter {classpath com.android.tools.build:gradle:3.5.0-alpha06 // MERK: Ikke plasser søknadsavhengighetene dine her; de hører hjemme // i den enkelte modul build.gradle-filer}} allprojects {repositories {google () jcenter ()}} oppgavens rene (type: Delete) {delete rootProject.buildDir}

Denne build.gradle-filen på prosjektnivå er delt inn i følgende blokker:

Buildscript. Denne inneholder innstillinger som er nødvendige for å utføre byggingen.
Repositories. Gradle er ansvarlig for å finne prosjektets avhengigheter og gjøre dem tilgjengelige i byggingen. Imidlertid kommer ikke alle avhengigheter fra det samme depot, så du må definere alle depotene som Gradle skal søke for å hente prosjektets avhengigheter.
Avhengigheter. Denne delen inneholder pluginavhengighetene dine, som lastes ned og lagres i din lokale cache. Du burde ikke definere eventuelle modulavhengigheter i denne blokken.
Allprojects. Det er her du definerer depotene som skal være tilgjengelige alle av prosjektets moduler.

3. build.gradle (modulenivå)

Dette er build.gradle-filen på modulnivå, som er til stede i hver modul gjennom hele prosjektet ditt. Hvis Android-prosjektet ditt består av flere moduler, vil det også bestå av flere build.gradle-filer på modulnivå.

Hver build.gradle-fil på modulnivå inneholder prosjektets pakkenavn, versjonsnavn og versjonskode, pluss minimum og SDK for denne modulen.

En build.gradle-fil på modulnivå kan også ha sitt eget unike sett med bygginstruksjoner og avhengigheter. Hvis du for eksempel oppretter en applikasjon med en Wear OS-komponent, vil Android Studio-prosjektet bestå av en egen smarttelefon / nettbrettmodul og en Wear-modul - siden de er målrettet mot helt forskjellige enheter, har disse modulene drastisk forskjellige avhengigheter!

En grunnleggende build.gradle-fil på modulnivå vil vanligvis se slik ut:

bruke plugin: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versjonName "1.0" testInstrumentationRunner "androidx.test.runner.Runner release getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} avhengigheter {implementeringsfilTree (dir: libs, inkluderer:) implementering androidx.appcompat: appcompat: 1.0.2 implementering androidx.constraintlayout: constraintlayout: 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}

La oss se nærmere på hver av disse seksjonene:

bruke plugin. Dette er en liste over plugins som kreves for å bygge denne modulen. Com.android.application-pluginen er nødvendig for å konfigurere den Android-spesifikke byggeprosessen, så denne legges til automatisk.
android. Det er her du bør plassere alle modulens plattformspesifikke alternativer.
compileSdkVersion. Dette er API-nivået som denne modulen er satt sammen med. Du kan ikke bruke funksjoner fra et API som er høyere enn denne verdien.
buildToolsVersion. Dette indikerer versjonen av kompilatoren. I Gradle 3.0.0 og nyere er buildToolsVersion valgfritt; Hvis du ikke spesifiserer en buildToolsVersion-verdi, vil Android Studio som standard være den nyeste versjonen av Build Tools.
defaultConfig. Dette inneholder alternativer som vil bli brukt på alle build-versjoner av appen din, for eksempel debug og release-builds.
applicationlD. Dette er applikasjonens unike identifikator.
minSdkVersion. Denne parameteren definerer det laveste API-nivået som denne modulen støtter.
targetSdkVersion. Dette er det maksimale API-nivået som applikasjonen din er testet mot. Ideelt sett bør du teste søknaden din ved å bruke den nyeste API-en, noe som betyr at targetSdkVersion-verdien alltid vil være lik compileSdkVersion-verdien.
version. Dette er en numerisk verdi for applikasjonsversjonen.
Versjons. Dette er en brukervennlig streng som representerer applikasjonsversjonen din.
buildTypes. Som standard støtter Android to buildtyper: feilsøking og utgivelse. Du kan bruke "feilsøking" og "utgivelse" -blokkene for å spesifisere applikasjonens typespesifikke innstillinger.
avhengigheter. Det er her du definerer biblioteker som denne modulen er avhengig av.

Å erklære prosjektets avhengigheter: Lokale biblioteker

Du kan gjøre ekstra funksjonalitet tilgjengelig for Android-prosjektene dine ved å legge til en eller flere prosjektavhengigheter. Disse avhengighetene kan være lokale, eller de kan lagres i et fjernlager.

For å erklære en avhengighet av en lokal JAR-fil, må du legge den JAR til prosjektets "libs" -katalog.

Du kan deretter endre modulenivå build.gradle-filen for å erklære en avhengighet av denne filen. For eksempel erklærer vi her en avhengighet av en "mylibrary" JAR.

implementeringsfiler (libs / mylibrary.jar)

Alternativt, hvis “libs” -mappen din inneholdt flere JAR-er, kan det være enklere å bare oppgi at prosjektet avhenger av alle filene som ligger i “libs” -mappen, for eksempel:

implementeringsfilTree (dir: libs, inkluderer:)

Legge til en byggeavhengighet: Fjernlager

Hvis et bibliotek ligger i et eksternt lagringssted, må du fullføre følgende trinn:

Definer depotet der denne avhengigheten er lokalisert.
Erklære den enkelte avhengighet.

Koble til et fjernlager

Det første trinnet er å fortelle Gradle hvilket depot (eller depot) det må kontrolleres for å hente alle prosjektets avhengigheter. For eksempel:

depoter {google () jcenter ()}}

Her sikrer linjen “jcenter ()” at Gradle vil sjekke JCenter-depotet, som er et gratis, offentlig depot som er vert på bintray.

Alternativt, hvis du eller organisasjonen din opprettholder et personlig lagringssted, bør du legge nettadressen til depotet til avhengighetserklæringen. Hvis depotet er passordbeskyttet, må du også oppgi innloggingsinformasjonen din, for eksempel:

repositories {mavenCentral () maven {// Konfigurer mål-URL // url "http://repo.mycompany.com/myprivaterepo"} maven {legitimasjon {brukernavn mitt brukernavn passord myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Hvis en avhengighet er til stede i flere lagre, vil Gradle velge den "beste" versjonen av denne avhengigheten, basert på faktorer som alderen til hvert repository og den statiske versjonen.

Å erklære en ekstern avhengighet

Neste trinn er å erklære avhengigheten i build.gradle-filen på modulnivå. Du legger til denne informasjonen i "avhengigheter" -blokken ved å bruke ett av følgende:

Gjennomføring. Dette er en normal avhengighet du trenger når du bygger prosjektet. En "implementering" avhengighet vil være til stede på tvers alle dine bygger.
Testimplementation. Dette er en avhengighet som kreves for å kompilere applikasjonens testkilde og kjøre JVM-baserte tester. Når du markerer en avhengighet som "Testimplementation", vil Gradle vite at den ikke trenger å kjøre oppgaver for denne avhengigheten under en normal bygging, noe som kan bidra til å redusere byggetiden.
Androidtestimplementation. Dette er en avhengighet som kreves når du kjører tester på en enhet, for eksempel er Espresso-rammeverket en vanlig "Androidtestimplementation."

Vi definerer en ekstern avhengighet, ved hjelp av et av de ovennevnte nøkkelordene, etterfulgt av avhengighetens gruppe, navn og versjonsattributter, f.eks.

avhengigheter {implementeringsfilTree (dir: libs, inkluderer:) implementering androidx.appcompat: appcompat: 1.0.2 implementering androidx.constraintlayout: constraintlayout: 1.1.3 testImplementering junit: junit: 4.12 androidTestImplementation androidx.test.ext: junit: 1.1.0 androidTestImplementering androidx.test.espresso: espresso-core: 3.1.1}

Genererer flere APK-er: Hvordan lage build-varianter

Noen ganger kan det hende du må lage flere versjoner av applikasjonen din. Det kan for eksempel være lurt å gi ut en gratis versjon og en betalt versjon, som inkluderer noen tilleggsfunksjoner.

Dette er en byggeoppgave som Gradle kan hjelpe deg med, så la oss se på hvordan du vil endre byggeprosessen for å lage flere APK-er fra et enkelt prosjekt:

Åpne strings.xml-filen og slett den opprinnelige applikasjonsnavnstrengen.
Deretter definerer du navnene på hver produktsmak du vil lage; i dette tilfellet bruker jeg:

Min gratis app Min betalte app

Åpne filen din AndroidManifest.xml og erstatt android: label = ”@ string / app_name” med:

android: label = "$ {} AppName"

Åpne modulenivå build.gradle-filen og legg til følgende i "android" -blokken:

flavourDimensions "mode" productFlavours {gratis {dimensjon "modus" applicationIdSuffix ".free" manifestPlaceholders =} betalt {dimensjon "modus" applicationIdSuffix ".paid" manifestPlaceholders =}}}

La oss fordele hva som skjer her:

flavorDimensions. Android-pluginen lager byggvarianter ved å kombinere smaker fra forskjellige dimensjoner. Her lager vi en smaksdimensjon som består av "gratis" og "betalte" versjoner av appen vår. Basert på koden over vil Gradle generere fire build-varianter: paysDebug, paysRelease, freeDebug og freeRelease.
productFlavors. Dette spesifiserer en liste over smaker og deres innstillinger, som i koden ovenfor er "betalt" og "gratis."
Gratis / betalt. Dette er navnene på de to produktsmakene våre.
Dimensjon. Vi må spesifisere en "dimensjon" -parameterverdi; i dette tilfellet bruker jeg "modus."
applicationIdSuffix. Siden vi ønsker å lage flere versjoner av appen vår, må vi gi hver APK en unik appidentifikator.
manifestPlaceholders. Hvert prosjekt har en enkelt Manifest-fil som inneholder viktig informasjon om prosjektets konfigurasjon. Når du oppretter flere byggevarianter, vil du vanligvis endre noen av disse Manifest-egenskapene på byggetidspunktet. Du kan bruke Gradle build-filene til å spesifisere unike Manifest-oppføringer for hver build-variant, som deretter blir satt inn i manifestet ditt på byggetidspunktet. I koden ovenfor endrer vi verdien "appName" avhengig av om Gradle bygger den gratis eller den betalte versjonen av appen vår.

Opprette en tilpasset Gradle-oppgave

Noen ganger kan det hende du må tilpasse byggeprosessen ved å bruke Gradle oppgaver.

En oppgave er en navngitt samling av handlinger som Gradle vil utføre når den utfører en bygging, for eksempel å generere en Javadoc. Gradle støtter mange oppgaver som standard, men du kan også lage tilpassede oppgaver, som kan komme til nytte hvis du har et veldig spesifikt sett med instruksjoner for bygging.

I denne delen oppretter vi en tilpasset Gradle-oppgave som vil itereere gjennom alle prosjektets byggvarianter (betaltDebug, betaltRelease, gratisDebug og gratisRelease), opprette et dato- og tidsstempel og deretter legge til denne informasjonen til hver genererte APK.

Åpne build.gradle-filen på modulnivå og legg til følgende:

oppgave addDateAndTime () {// Iterere gjennom alle output build-varianter // android.applicationVariants.all {variant -> // Iterate gjennom alle APK-filene // variant.outputs.all {output -> // Opprett en forekomst av gjeldende dato og klokkeslett, i formatet spesifisert // def dateAndTime = new Date (). format ("yyyy-MM-dd: HH-mm") // Legg denne informasjonen til APKs filnavn // def fileName = variant. name + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

Deretter må vi fortelle Gradle når den skal utføre denne oppgaven. Under en bygging identifiserer Gradle alt den trenger å laste ned og alle oppgavene den har å utføre, og ordner dem i en Directed Acyclic Graph (DAG). Gradle vil da utføre alle disse oppgavene, i henhold til rekkefølgen som er definert i dens DAG.

For appen min skal jeg bruke “WhenReady” -metoden, som sikrer at oppgaven vår blir kalt når DAG har blitt befolket, og Gradle er klar til å begynne å utføre oppgavene sine.

Legg til følgende i build.gradle-filen på modulnivå:

// Utfør denne oppgaven // gradle.taskGraph.whenReady {addDateAndTime}

La oss legge den tilpassede oppgaven vår og vår build-variantkode til testen, ved å bygge dette prosjektet ved hjelp av en Gradle-kommando.

Bygg prosjektet ditt med Gradle wrapper

Du gir Gradle-kommandoer ved hjelp av Gradle wrapper (“gradlew”). Dette skriptet er den foretrukne måten å starte en Gradle build på, ettersom det gjør utførelsen av builden uavhengig av din versjon av Gradle. Denne separasjonen kan være nyttig hvis du samarbeider med andre som ikke nødvendigvis har den samme versjonen av Gradle installert.

Når du utsteder Gradle wrapper-kommandoene dine, bruker du "gradlew" for Unix-lignende operativsystemer, inkludert macOS, og "gradlew.bat" for Windows. Jeg har en Mac, så jeg bruker "gradlew" -kommandoer.

Du kan gi Gradle-kommandoer fra Android Studio:

I verktøylinjen til Android Studio velger du "Vis> Verktøy Windows> Terminal." Dette åpner et terminalpanel nederst i IDE-vinduet.
Skriv inn følgende kommando i terminalen:

./gradlew build

Android Studio skal se slik ut:

Trykk "Enter" -tasten på tastaturet. Gradle vil nå bygge prosjektet ditt.

Gradle lagrer alle de genererte APK-ene i prosjektets app / build / output / apk-katalog, så naviger til denne katalogen. APK-mappen skal inneholde flere mapper og undermapper; sørg for at Gradle har generert en APK for hver av dine byggvarianter, og at riktig dato og klokkeslettinformasjon er lagt til hver fil.

Hvilke andre Gradle-oppgaver er tilgjengelige?

I tillegg til alle tilpassede oppgaver du kan opprette, støtter Gradle en liste med forhåndsdefinerte oppgaver uten sidestykke. Hvis du er nysgjerrig på å se nøyaktig hvilke oppgaver som er tilgjengelige, så:

Åpne Android Studios terminalvindu, hvis det ikke allerede er åpent (ved å velge "Vis> Verktøy Windows> Terminal" fra Android Studio verktøylinje).
Skriv inn følgende i terminalen:

./gradlew -q oppgaver

Trykk "Enter" -tasten på tastaturet.

Denne "oppgaver" -oppgaven vil nå kjøres, og etter noen øyeblikk vil terminalen vise en liste over alle oppgavene som er tilgjengelige for dette prosjektet, komplett med en kort beskrivelse av hver oppgave.

Få mer ut av Gradle: Legge til plugins

Gradle skip med et antall plugins forhåndsinstallert, men du kan utvide Gradle ytterligere ved å legge til nye plugins. Disse plugin-ene gjør nye oppgaver tilgjengelige for Android-prosjektene dine, for eksempel inkluderer Java-plugin-oppgaver som lar deg kompilere Java-kildekode, kjøre enhetstester og opprette en JAR-fil, for eksempel “compileJava,” “compileText,” “jar,” "Javadoc," og "clean."

Hvis du vil bruke en plugin, legger du til "Apply plugin" -deklarasjonen i build.gradle-filen på modulnivå, etterfulgt av navnet på plugin-modulen. Her bruker vi for eksempel Java-plugin:

bruk plugin: java

Hvis du er nysgjerrig på å se hvilke plugins som er tilgjengelige, kan du sjekke Gradle Plugin-søk, som gir et omfattende register over Gradle-plugins.

The Gradle Kotlin DSL

Som standard skriver du Gradle build-skriptene dine ved hjelp av Groovy DSL, men hvis du er en av de mange utviklerne som har tatt i bruk Kotlin for Android-utvikling, kan det hende du foretrekker å skrive build-skriptene dine i Kotlin i stedet.

I motsetning til Groovy, er Kotlin et statisk typisk programmeringsspråk, så hvis du bytter, vil byggefilene dine være kompatible med Android Studios autofullførings- og kildekodenavigeringsfunksjoner. I tillegg betyr det å flytte fra Groovy til Kotlin at du vil bruke det samme programmeringsspråket på tvers av prosjektet ditt, noe som kan gjøre utviklingen mer oversiktlig - spesielt hvis du ikke er altfor kjent med Groovy!

Hvis du vil begynne å skrive byggelogikken din i Kotlin, må du konfigurere Gradle Kotlin DSL og følge instruksjonene i migreringsguiden.

Innpakking

I denne artikkelen har vi utforsket Android Studios verktøy for å bygge automatisering og avhengighet. Vi undersøkte hvordan Gradle automatiserer byggeprosessen ut av boksen, og hvordan du kan endre byggeprosessen ved å redigere prosjektets Gradle build-filer, inkludert lage tilpassede Gradle-oppgaver og generere flere build-varianter fra et enkelt prosjekt.

Har du utvidet Gradle til å automatisere andre deler av Android-prosessen? Gi oss beskjed i kommentarene nedenfor!