Mastering Gradle til Android: Gradle-opgaver og Kotlin

Indhold

Udforskning af Gradle build-filer
1. settings.gradle
2. build.gradle (projektniveau)
3. build.gradle (modulniveau)
Erklæring om dit projekt afhængighed: Lokale biblioteker
Tilføjelse af en build-afhængighed: Fjernlagre
Opretter forbindelse til et fjernlager
At erklære en fjernafhængighed
Generering af flere APK'er: Sådan oprettes buildvarianter
Oprettelse af en tilpasset Gradle-opgave
Byg dit projekt med Gradle-indpakningen
Hvilke andre Gradle-opgaver er tilgængelige?
Få mere ud af Gradle: Tilføjelse af plugins
The Gradle Kotlin DSL
Afslutter

I stedet for Java, XML eller Kotlin bruger disse Gradle build-filer det Groovy-baserede domænespecifikke sprog (DSL). Hvis du ikke er bekendt med Groovy, tager vi et linie for linie på hver af disse Gradle build-filer, så ved udgangen af denne artikel har du det godt med at læse og skrive enkel Groovy-kode.

Gradle sigter mod at gøre dit liv lettere ved at tilvejebringe et sæt standardindstillinger, som du ofte kan bruge med minimum manuel konfiguration - når du er klar til at opbygge dit projekt, skal du blot trykke på Android Studios “Kør” -knap, og Gradle vil starte byggeprocessen for dig.

På trods af Gradle's "konvention over konfiguration" -tilgang, hvis dens standardindstillinger ikke helt opfylder dine behov, kan du tilpasse, konfigurere og udvide byggeprocessen og endda justere Gradle-indstillingerne til at udføre meget specifikke opgaver.

Da Gradle-scripts er indeholdt i deres egne filer, kan du til enhver tid ændre din applikations opbygningsproces uden at skulle røre ved din applikations kildekode. I denne tutorial vil vi ændre buildprocessen ved hjælp af smag, buildvarianter og en tilpasset Gradle-opgave - alt uden nogensinde ved at røre ved vores programkode.

Udforskning af Gradle build-filer

Hver gang du opretter et projekt, genererer Android Studio den samme samling af Gradle build-filer. Selv hvis du importerer et eksisterende projekt til Android Studio, gør det det stadig oprette disse nøjagtige samme Gradle-filer, og tilføj dem til dit projekt.

For at begynde at få en bedre forståelse af Gradle og Groovy-syntaxen, lad os tage et linie-for-line kig på hver af Android's Gradle build-filer.

1. settings.gradle

Filen settings.gradle er det sted, hvor du definerer alle dine applikations moduler ved navn ved hjælp af nøgleordet "include". Hvis du f.eks. Havde et projekt bestående af en "app" og en "secondModule", så ville din settings.gradle-fil se sådan ud:

inkluderer: app,: secondmodule rootProject.name = MyProject

Afhængig af størrelsen på dit projekt kan denne fil være betydeligt længere.

Under byggeprocessen vil Gradle undersøge indholdet i dit projekt indstillinger.gradle-fil og identificere alle de moduler, det har brug for at medtage i byggeprocessen.

2. build.gradle (projektniveau)

Build.gradle-fil på projektniveau er placeret i dit projekts rodmappe og indeholder indstillinger, der vil blive anvendt på alle dine moduler (også kaldet “projekter” af Gradle).

Du skal bruge denne fil til at definere eventuelle plugins, opbevaringssteder, afhængigheder og konfigurationsindstillinger, der gælder for hvert modul i hele dit Android-projekt. Bemærk, at hvis du definerer nogen Gradle-opgaver i build.gradle-filen på projektniveau, er det stadig muligt at tilsidesætte eller udvide disse opgaver for individuelle moduler ved at redigere deres tilsvarende modulniveau build.gradle-fil.

En typisk build.gradle-fil på projektniveau vil se sådan ud:

buildscript {repositories {google () jcenter ()} afhængigheder {classpath com.android.tools.build:gradle:3.5.0-alpha06 // BEMÆRK: Anbring ikke dine applikationsafhængigheder her; de hører hjemme // i det enkelte modul build.gradle-filer}} allprojects {repositories {google () jcenter ()}} opgave ren (type: Slet) {delete rootProject.buildDir}

Denne build.gradle-fil på projektniveau er opdelt i følgende blokke:

Buildscript. Dette indeholder indstillinger, der er nødvendige for at udføre build.
Arkiver. Gradle er ansvarlig for at lokalisere dit projekt afhængigheder og gøre dem tilgængelige i din build. Imidlertid kommer ikke alle afhængigheder fra det samme lager, så du bliver nødt til at definere alle depoterne, som Gradle skal søge for at hente dit projekt afhængigheder.
Afhængigheder. Dette afsnit indeholder dine plugin-afhængigheder, som downloades og gemmes i din lokale cache. Du burde ikke definere eventuelle modulafhængigheder inden for denne blok.
Allprojects. Det er her du definerer de lagre, der skal være tilgængelige for alle af dit projekts moduler.

3. build.gradle (modulniveau)

Dette er build.gradle-filen på modulniveau, som er til stede i hvert modul i hele dit projekt. Hvis dit Android-projekt består af flere moduler, består det også af flere build.gradle-filer på modulniveau.

Hver build.gradle-fil på modulniveau indeholder dit projekts pakkenavn, versionnavn og versionskode plus minimum og mål-SDK for netop dette modul.

En build.gradle-fil på modulniveau kan også have sit eget unikke sæt buildinstruktioner og afhængigheder. Hvis du for eksempel opretter en applikation med en Wear OS-komponent, består dit Android Studio-projekt af et separat smartphone / tablet-modul og et Wear-modul - da de er målrettet mod helt forskellige enheder, har disse moduler drastisk forskellige afhængigheder!

En grundlæggende build.gradle-fil på modulniveau vil typisk se sådan ud:

anvende plugin: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.Runner progr. getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} afhængigheder {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}

Lad os se nærmere på hver af disse sektioner:

Anvend plugin. Dette er en liste over de plugins, der kræves for at opbygge dette modul. Com.android.application-plugin er nødvendigt for at konfigurere den Android-specifikke build-proces, så denne tilføjes automatisk.
android. Det er her du skal placere alle modulets platformspecifikke indstillinger.
compileSdkVersion. Dette er det API-niveau, som dette modul er kompileret med. Du kan ikke bruge funktioner fra et API, der er højere end denne værdi.
buildToolsVersion. Dette viser versionen af kompilatoren. I Gradle 3.0.0 og nyere er buildToolsVersion valgfri; Hvis du ikke angiver en buildToolsVersion-værdi, vil Android Studio som standard være den nyeste version af Build Tools.
defaultConfig. Dette indeholder indstillinger, der vil blive anvendt på alle build-versioner af din app, såsom din debug og release builds.
applicationId. Dette er din applikations unikke id.
minSdkVersion. Denne parameter definerer det laveste API-niveau, som dette modul understøtter.
targetSdkVersion. Dette er det maksimale API-niveau, som din applikation er testet mod. Ideelt set bør du teste din ansøgning ved hjælp af den nyeste API, hvilket betyder, at targetSdkVersion-værdien altid vil være lig med compileSdkVersion-værdien.
versionCode. Dette er en numerisk værdi for din applikationsversion.
Versionsnavnet. Dette er en brugervenlig streng, der repræsenterer din applikationsversion.
buildTypes. Som standard understøtter Android to buildtyper: debug og release. Du kan bruge blokke "debug" og "release" til at specificere din applikations typespecifikke indstillinger.
afhængigheder. Det er her du definerer de biblioteker, som dette modul afhænger af.

Erklæring om dit projekt afhængighed: Lokale biblioteker

Du kan stille yderligere funktionalitet til rådighed for dine Android-projekter ved at tilføje en eller flere projektafhængigheder. Disse afhængigheder kan være lokale, eller de kan gemmes i et fjernlager.

For at erklære en afhængighed af en lokal JAR-fil, skal du tilføje den JAR til dit projekts "libs" -mappe.

Du kan derefter ændre modul-niveau build.gradle-filen for at erklære en afhængighed af denne fil. For eksempel erklærer vi her en afhængighed af en "mylibrary" JAR.

implementeringsfiler (libs / mylibrary.jar)

Alternativt, hvis din “libs” -mappe indeholdt flere JAR'er, kan det være lettere at blot oplyse, at dit projekt afhænger af alle de filer, der findes i “libs” -mappen, for eksempel:

implementeringsfilTree (dir: libs, inkluderer:)

Tilføjelse af en build-afhængighed: Fjernlagre

Hvis et bibliotek er placeret i et fjernlager, skal du udføre følgende trin:

Definer depotet, hvor denne afhængighed er placeret.
Angiv den individuelle afhængighed.

Opretter forbindelse til et fjernlager

Det første trin er at fortælle Gradle, hvilket depot (eller depot) det skal kontrolleres for at hente alle dit projekt afhængigheder. For eksempel:

depoter {google () jcenter ()}}

Her sikrer linjen “jcenter ()”, at Gradle kontrollerer JCenter-arkivet, som er et gratis, offentligt arkiv, der er vært hos bintray.

Alternativt, hvis du eller din organisation opretholder et personlig lager, skal du tilføje dette repositoris URL til din afhængighedserklæring. Hvis depotet er adgangskodebeskyttet, skal du også give dine loginoplysninger, for eksempel:

repositories {mavenCentral () maven {// Konfigurer destinationswebadressen // url "http://repo.mycompany.com/myprivaterepo"} maven {legitimationsoplysninger {brugernavn myUsername password myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Hvis der er en afhængighed i flere lagre, vælger Gradle den "bedste" version af denne afhængighed, baseret på faktorer som alderen på hvert arkiv og den statiske version.

At erklære en fjernafhængighed

Det næste trin er at erklære afhængigheden i din build.gradle-fil på modulniveau. Du føjer disse oplysninger til "afhængigheder" -blokken ved hjælp af en af følgende:

Implementering. Dette er en normal afhængighed, du har brug for, når du bygger dit projekt. En "implementerings" afhængighed vil være til stede på tværs af alle dine bygger.
Testimplementation. Dette er en afhængighed, der kræves for at kompilere din applikations testkilde og køre JVM-baserede test. Når du markerer en afhængighed som "Testimplementation", vil Gradle vide, at den ikke behøver at køre opgaver til denne afhængighed under en normal opbygning, hvilket kan hjælpe med at reducere byggetiden.
Androidtestimplementation. Dette er en afhængighed, der kræves, når du kører test på en enhed, f.eks. Espresso-rammen er en almindelig "Androidtestimplementation."

Vi definerer en fjernafhængighed ved hjælp af et af ovenstående nøgleord, efterfulgt af afhængighedens gruppe, navn og version attributter, for eksempel:

afhængigheder {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}

Generering af flere APK'er: Sådan oprettes buildvarianter

Undertiden skal du muligvis oprette flere versioner af din applikation. For eksempel vil du måske frigive en gratis version og en betalt version, der indeholder nogle ekstra funktioner.

Dette er en build-opgave, som Gradle kan hjælpe dig med, så lad os se på, hvordan du ville ændre build-processen til at oprette flere APK'er fra et enkelt projekt:

Åbn din strings.xml-fil, og slet din oprindelige applikationsnavnsstreng.
Definér derefter navnene på hvert produktsmag, du vil oprette; i dette tilfælde bruger jeg:

Min gratis app Min betalte app

Åbn din AndroidManifest.xml-fil, og erstat android: label = ”@ streng / app_navn” med:

android: label = "$ {appName}"

Åbn din build.gradle-fil på modulniveau, og tilføj følgende til "android" -blokken:

flavourDimensions "mode" productFlavors {free {dimension "mode" applicationIdSuffix ".free" manifestPlaceholders =} betalt {dimension "mode" applicationIdSuffix ".paid" manifestPlaceholders =}}}

Lad os fordele hvad der sker her:

flavorDimensions. Android-plugin skaber build-varianter ved at kombinere smag fra forskellige dimensioner. Her opretter vi en smagsdimension, der består af "gratis" og "betalte" versioner af vores app. Baseret på koden ovenfor genererer Gradle fire build-varianter: paysDebug, paysRelease, freeDebug og freeRelease.
productFlavors. Dette specificerer en liste over smagsoplevelser og deres indstillinger, som i ovenstående kode er "betalt" og "gratis."
Gratis / betalt. Dette er navnene på vores to produktsmag.
Dimension. Vi er nødt til at specificere en "dimension" -parameterværdi; i dette tilfælde bruger jeg "tilstand."
applicationIdSuffix. Da vi ønsker at oprette flere versioner af vores app, er vi nødt til at give hver APK en unik app-id.
manifestPlaceholders. Hvert projekt har en enkelt Manifest-fil, der indeholder vigtige oplysninger om dit projekts konfiguration. Når du opretter flere buildvarianter, ønsker du typisk at ændre nogle af disse Manifest-egenskaber på bygningstidspunktet. Du kan bruge Gradle build-filer til at specificere unikke manifest-poster for hver build-variant, som derefter indsættes i dit manifest på byggetidspunktet. I ovenstående kode ændrer vi værdien "appName" afhængigt af om Gradle bygger den gratis eller den betalte version af vores app.

Oprettelse af en tilpasset Gradle-opgave

Undertiden skal du muligvis tilpasse byggeprocessen ved hjælp af Gradle opgaver.

En opgave er en navngivet samling af handlinger, som Gradle vil udføre, når den udfører en build, for eksempel at generere en Javadoc. Gradle understøtter masser af opgaver som standard, men du kan også oprette brugerdefinerede opgaver, som kan komme godt med, hvis du har et meget specifikt sæt bygningsinstruktioner i tankerne.

I dette afsnit opretter vi en brugerdefineret Gradle-opgave, der vil itereere gennem alle vores projekts build-varianter (betaltDebug, betalt frigivelse, gratisDebug og friudgivelse), oprette et dato- og tidsstempel og derefter føje disse oplysninger til hver genereret APK.

Åbn din build.gradle-fil på modulniveau, og tilføj følgende:

task addDateAndTime () {// Iterere gennem alle output build-varianter // android.applicationVariants.all {variant -> // Iterate gennem alle APK-filer // variant.outputs.all {output -> // Opret en forekomst af den aktuelle dato og tid i det angivne format // def dateAndTime = new Date (). format ("yyyy-MM-dd: HH-mm") // Tilføj disse oplysninger til APK's filnavn // def fileName = variant. navn + "_" + datoAndTime + ".apk" output.outputFileName = filnavn}}}

Dernæst skal vi fortælle det til Gradle hvornår det skal udføre denne opgave. Under en bygning identificerer Gradle alt, hvad den har brug for at downloade, og alle de opgaver, den har til at udføre, og arrangerer dem i en Directed Acyclic Graph (DAG). Gradle udfører derefter alle disse opgaver i henhold til den rækkefølge, der er defineret i dens DAG.

Til min app skal jeg bruge metoden “WhenReady”, som sikrer, at vores opgave kaldes, når DAG er blevet befolket, og Gradle er klar til at begynde at udføre sine opgaver.

Føj følgende til din build.gradle-fil på modulniveau:

// Udfør denne opgave // gradle.taskGraph.whenReady {addDateAndTime}

Lad os sætte vores brugerdefinerede opgave og vores build-variantkode til testen ved at opbygge dette projekt ved hjælp af en Gradle-kommando.

Byg dit projekt med Gradle-indpakningen

Du udsender Gradle-kommandoer ved hjælp af Gradle-indpakningen (“gradlew”). Dette script er den foretrukne måde at starte en Gradle build, da det gør udførelsen af builden uafhængig af din version af Gradle. Denne adskillelse kan være nyttig, hvis du samarbejder med andre, som ikke nødvendigvis har den samme version af Gradle installeret.

Når du udsteder dine Gradle wrapper-kommandoer, bruger du “gradlew” til Unix-lignende operativsystemer, herunder macOS, og “gradlew.bat” til Windows. Jeg har en Mac, så jeg bruger "gradlew" -kommandoer.

Du kan udstede Gradle-kommandoer fra Android Studio:

Vælg "Vis> Værktøjer Windows> Terminal." I Android Studio-værktøjslinjen. Dette åbner et terminalpanel langs bunden af IDE-vinduet.
Indtast følgende kommando i terminalen:

./gradlew build

Android Studio skal se sådan ud:

Tryk på "Enter" -tasten på dit tastatur. Gradle bygger nu dit projekt.

Gradle gemmer alle de genererede APK'er i dit projekts bibliotek for app / build / output / apk, så naviger til dette bibliotek. "APK" -mappen skal indeholde flere mapper og undermapper; Sørg for, at Gradle har genereret en APK for hver af dine build-varianter, og at de korrekte oplysninger om dato og tid er tilføjet til hver fil.

Hvilke andre Gradle-opgaver er tilgængelige?

Ud over alle tilpassede opgaver, du måtte oprette, understøtter Gradle en liste med foruddefinerede opgaver ude af boksen. Hvis du er nysgerrig efter at se nøjagtigt, hvilke opgaver der er tilgængelige, så:

Åbn Android Studios terminalvindue, hvis det ikke allerede er åbent (ved at vælge "Vis> Værktøjer Windows> Terminal" fra Android Studio-værktøjslinjen).
Skriv følgende i terminalen:

./gradlew -q opgaver

Tryk på "Enter" -tasten på dit tastatur.

Denne "opgaver" -opgave køres nu, og efter få øjeblikke viser terminalen en liste over alle de tilgængelige opgaver til dette projekt, komplet med en kort beskrivelse af hver opgave.

Få mere ud af Gradle: Tilføjelse af plugins

Gradle skibe med et antal plugins forudinstalleret, men du kan yderligere udvide Gradle ved at tilføje nye plugins. Disse plugins gør nye opgaver tilgængelige for dine Android-projekter, for eksempel inkluderer Java-plugin opgaver, der giver dig mulighed for at kompilere Java-kildekode, køre enhedsprøver og oprette en JAR-fil, såsom "compileJava," "compileText," "jar," "Javadoc," og "ren."

For at anvende et plugin skal du tilføje erklæringen "Apply plugin" til din build.gradle-fil på modulniveau, efterfulgt af navnet på plugin. For eksempel anvender vi her Java-plugin:

anvend plugin: java

Hvis du er nysgerrig efter at se, hvilke plugins der er tilgængelige, kan du tjekke Gradle Plugin-søgning, der indeholder et omfattende register over Gradle-plugins.

The Gradle Kotlin DSL

Som standard skriver du dine Gradle build-scripts ved hjælp af Groovy DSL, men hvis du er en af de mange udviklere, der har vedtaget Kotlin til Android-udvikling, kan du foretrække at skrive dine build-scripts i Kotlin i stedet.

I modsætning til Groovy er Kotlin et statisk typisk programmeringssprog, så hvis du skifter, vil dine build-filer være kompatible med Android Studios autofuldførelse og kildekodenavigationsfunktioner. Plus, at flytte fra Groovy til Kotlin betyder, at du bruger det samme programmeringssprog på tværs af dit projekt, hvilket kan gøre udvikling mere ligetil - især hvis du ikke er for meget bekendt med Groovy!

Hvis du vil begynde at skrive din build-logik i Kotlin, skal du konfigurere Gradle Kotlin DSL og følge instruktionerne i migreringsguiden.

Afslutter

I denne artikel udforskede vi Android Studios værktøj til opbygning af automatisering og afhængighed. Vi undersøgte, hvordan Gradle automatiserer byggeprocessen uden for boksen, og hvordan du kan ændre buildprocessen ved at redigere dit projekts Gradle build-filer, herunder oprette tilpassede Gradle-opgaver og generere flere build-varianter fra et enkelt projekt.

Har du udvidet Gradle til at automatisere andre dele af Android-build-processen? Fortæl os det i kommentarerne nedenfor!