Mastering Gradle for Android: Gradle-uppgifter och Kotlin

Innehåll

Utforska Gradle build-filer
1. settings.gradle
2. build.gradle (projektnivå)
3. build.gradle (modulenivå)
Förklara projektets beroende: Lokala bibliotek
Lägga till ett byggberoende: Fjärrlager
Ansluter till ett fjärrlager
Förklarar ett beroende på avstånd
Generera flera APK: hur man skapar byggvarianter
Skapa en anpassad Gradle-uppgift
Bygg ditt projekt med Gradle wrapper
Vilka andra Gradle-uppgifter finns tillgängliga?
Få ut mer av Gradle: Lägga till plugins
The Gradle Kotlin DSL
Avslutar

I stället för Java, XML eller Kotlin använder dessa Gradle build-filer det Groovy-baserade domänspecifika språket (DSL). Om du inte känner till Groovy kommer vi att titta en rad för rad på var och en av dessa Gradle build-filer, så i slutet av den här artikeln kommer du att vara bekväm med att läsa och skriva enkel Groovy-kod.

Gradle syftar till att göra ditt liv enklare genom att tillhandahålla en uppsättning standardinställningar som du ofta kan använda med minimal manuell konfiguration - när du är redo att bygga ditt projekt trycker du bara på "Android" -knappen "Run" och Gradle startar byggprocessen till dig.

Trots Gradle: s "konvention över konfiguration" -metod, om standardinställningarna inte helt uppfyller dina behov, kan du anpassa, konfigurera och förlänga byggprocessen och till och med justera Gradle-inställningarna för att utföra mycket specifika uppgifter.

Eftersom Gradle-skript finns i sina egna filer kan du ändra din applikations byggprocess när som helst, utan att behöva röra din applikations källkod. I den här tutorialen kommer vi att ändra byggprocessen med smaker, byggvarianter och en anpassad Gradle-uppgift - allt utan någonsin vidröra vår applikationskod.

Utforska Gradle build-filer

Varje gång du skapar ett projekt genererar Android Studio samma samling Gradle build-filer. Även om du importerar ett befintligt projekt till Android Studio kommer det fortfarande skapa exakt samma Gradle-filer och lägg till dem i ditt projekt.

För att få en bättre förståelse av Gradle och Groovy-syntaxen, låt oss ta en rad-för-rad titt på var och en av Android: s Gradle build-filer.

1. settings.gradle

Filen settings.gradle är där du definierar alla programmets moduler med namn med hjälp av sökordet "inkludera". Om du till exempel hade ett projekt bestående av en "app" och en "secondModule", så skulle din inställningar.gradle-fil se ut så här:

inkludera: app,: secondmodule rootProject.name = MyProject

Beroende på projektets storlek kan den här filen vara betydligt längre.

Under byggprocessen kommer Gradle att undersöka innehållet i projektets inställningar.gradle-fil och identifiera alla moduler som den behöver inkludera i byggprocessen.

2. build.gradle (projektnivå)

Build.gradle-filen på projektnivå finns i ditt projekt rotkatalog och innehåller inställningar som kommer att tillämpas på Allt dina moduler (även kallad “projekt” av Gradle).

Du bör använda den här filen för att definiera eventuella plugins, förvar, beroenden och konfigurationsalternativ som gäller för varje modul i hela ditt Android-projekt. Observera att om du definierar några Gradle-uppgifter i build.gradle-filen på projektnivå, är det fortfarande möjligt att åsidosätta eller utöka dessa uppgifter för enskilda moduler genom att redigera deras motsvarande modulnivå build.gradle-fil.

En typisk build.gradle-fil på projektnivå ser ut så här:

buildscript {repositories {google () jcenter ()} beroenden {classpath com.android.tools.build:gradle:3.5.0-alpha06 // OBS: Placera inte dina applikationsberoenden här; de tillhör // i den enskilda modulen build.gradle-filer}} allprojects {repositories {google () jcenter ()}} uppgift ren (typ: Delete) {delete rootProject.buildDir}

Denna build.gradle-fil på projektnivå är indelad i följande block:

Buildscript. Detta innehåller inställningar som krävs för att utföra byggandet.
Arkiv. Gradle ansvarar för att hitta ditt projekt beroende och göra dem tillgängliga i din build. Men inte alla beroenden kommer från samma förvar, så du måste definiera alla förvar som Gradle ska söka efter för att hämta projektets beroenden.
Beroenden. Det här avsnittet innehåller dina pluginberoende, som laddas ner och lagras i din lokala cache. Du borde inte definiera eventuella modulberoenden inom detta block.
Allprojects. Det är här du definierar de förvar som borde vara tillgängliga för Allt av projektets moduler.

3. build.gradle (modulenivå)

Detta är build.gradle-filen på modulnivå, som finns i varje modul under hela ditt projekt. Om ditt Android-projekt består av flera moduler kommer det också att bestå av flera build.gradle-filer på modulnivå.

Varje modulnivå build.gradle-fil innehåller ditt projekt paketnamn, versionnamn och versionskod, plus minimum- och mål-SDK för just denna modul.

En build.gradle-fil på modulnivå kan också ha sin egen unika uppsättning bygginstruktioner och beroenden. Om du till exempel skapar en applikation med en Wear OS-komponent kommer ditt Android Studio-projekt att bestå av en separat smartphone / surfplatta-modul och en Wear-modul - eftersom de riktar sig mot helt olika enheter har dessa moduler drastiskt olika beroenden!

En grundläggande build.gradle-fil på modulnivå ser normalt ut så här:

applicera 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.prod. getDefaultProguardFile (proguard-android-optimize.txt), proguard-rules.pro}}} beroenden {implementeringsfilTree (dir: libs, inkluderar:) 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}

Låt oss titta närmare på vart och ett av dessa avsnitt:

applicera plugin. Detta är en lista över de plugins som krävs för att bygga den här modulen. Com.android.application-plugin är nödvändigt för att ställa in den Android-specifika byggprocessen, så den läggs till automatiskt.
android. Det är här du ska placera alla modulens plattformspecifika alternativ.
compileSdkVersion. Detta är API-nivån som den här modulen är kompilerad med. Du kan inte använda funktioner från ett API som är högre än detta värde.
buildToolsVersion. Detta indikerar versionen av kompilatorn. I Gradle 3.0.0 och högre är buildToolsVersion valfritt; om du inte anger ett buildToolsVersion-värde kommer Android Studio som standard till den senaste versionen av Build Tools.
defaultConfig. Detta innehåller alternativ som kommer att tillämpas på alla build-versioner av din app, till exempel din felsökning och release-build.
ansöknings-ID. Det här är din applikations unika identifierare.
minSdkVersion. Denna parameter definierar den lägsta API-nivån som den här modulen stöder.
targetSdkVersion. Detta är den maximala API-nivån som din ansökan har testats mot. Helst bör du testa din applikation med det senaste API: et, vilket innebär att targetSdkVersion-värdet alltid kommer att vara lika med compileSdkVersion-värdet.
version. Detta är ett numeriskt värde för din applikationsversion.
version. Detta är en användarvänlig sträng som representerar din applikationsversion.
buildTypes. Som standard stöder Android två buildtyper: felsökning och release. Du kan använda "felsökning" och "släpp" -blocken för att ange applikationens typspecifika inställningar.
beroenden. Det är här du definierar alla bibliotek som den här modulen beror på.

Förklara projektets beroende: Lokala bibliotek

Du kan göra ytterligare funktionalitet tillgänglig för dina Android-projekt genom att lägga till ett eller flera projektberoende. Dessa beroenden kan vara lokala, eller de kan lagras i ett fjärrlager.

För att förklara ett beroende av en lokal JAR-fil måste du lägga till den JAR i projektets "libs" -katalog.

Du kan sedan modifiera filen build.gradle på modulnivå för att förklara ett beroende av den här filen. Till exempel förklarar vi här ett beroende av en "mylibrary" JAR.

implementeringsfiler (libs / mylibrary.jar)

Alternativt, om din "libs" -mapp innehåller flera JAR, kan det vara lättare att bara ange att ditt projekt beror på alla filer som finns i mappen "libs", till exempel:

implementeringsfilTree (dir: libs, inkludera:)

Lägga till ett byggberoende: Fjärrlager

Om ett bibliotek finns i ett fjärrlager, måste du utföra följande steg:

Definiera förvaret där detta beroende finns.
Förklara det enskilda beroendet.

Ansluter till ett fjärrlager

Det första steget är att berätta för Gradle vilket arkiv (eller lagrar) den behöver kontrollera för att hämta alla projektets beroenden. Till exempel:

förvar {google () jcenter ()}}

Här säkerställer linjen “jcenter ()” att Gradle kommer att kontrollera JCenter-förvaret, som är ett gratis, offentligt arkiv som finns på bintray.

Alternativt, om du eller din organisation upprätthåller ett personligt förvar, bör du lägga till detta förvarets URL till din beroendedeklaration. Om förvaret är lösenordsskyddat, måste du också ange din inloggningsinformation, till exempel:

repositories {mavenCentral () maven {// Konfigurera måladressen // url "http://repo.mycompany.com/myprivaterepo"} maven {referenser {användarnamn mitt användarnamn lösenord myPassword} url "http://repo.mycompany.com / myprivaterepo "}

Om ett beroende finns i flera förvar, väljer Gradle den "bästa" versionen av detta beroende, baserat på faktorer som ålder för varje förvar och den statiska versionen.

Förklarar ett beroende på avstånd

Nästa steg är att förklara beroendet i din build.gradle-fil på modulnivå. Du lägger till denna information i blocket "beroende" med något av följande:

Genomförande. Detta är ett normalt beroende du behöver när du bygger ditt projekt. Ett "implementerings" -beroende kommer att finnas överallt Allt dina byggs.
Testimplementation. Detta är ett beroende som krävs för att sammanställa din applikations testkälla och köra JVM-baserade tester. När du markerar ett beroende som ”Testimplementation” kommer Gradle att veta att den inte behöver köra uppgifter för detta beroende under en normal byggnad, vilket kan bidra till att minska byggtiden.
Androidtestimplementation. Detta är ett beroende som krävs när du kör tester på en enhet, till exempel Espresso-ramverket är en vanlig "Androidtestimplementation."

Vi definierar ett beroende på distans med hjälp av ett av ovanstående nyckelord, följt av beroendets grupp, namn och versionattribut, till exempel:

beroenden {implementeringsfilTree (dir: libs, inkluderar:) 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}

Generera flera APK: hur man skapar byggvarianter

Ibland kan du behöva skapa flera versioner av din applikation. Till exempel kanske du vill släppa en gratis version och en betald version, som innehåller några ytterligare funktioner.

Detta är en bygguppgift som Gradle kan hjälpa dig med, så låt oss titta på hur du skulle ändra byggprocessen för att skapa flera APK: er från ett enda projekt:

Öppna filen strings.xml och ta bort den ursprungliga strängen för applikationsnamn.
Definiera sedan namnen på varje produktsmak som du vill skapa; i det här fallet använder jag:

Min gratisapp Min betalda app

Öppna din AndroidManifest.xml-fil och ersätt android: label = ”@ string / app_name” med:

android: label = "$ {appName}"

Öppna din build.gradle-fil på modulnivå och lägg till följande i "android" -blocket:

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

Låt oss dela upp vad som händer här:

flavorDimensions. Android-plugin skapar byggvarianter genom att kombinera smaker från olika dimensioner. Här skapar vi en smakdimension som består av "gratis" och "betalda" versioner av vår app. Baserat på koden ovan kommer Gradle att generera fyra buildvarianter: betaltDebug, betaltRelease, gratisDebug och FreeRelease.
productFlavors. Detta anger en lista med smaker och deras inställningar, som i koden ovan är "betalda" och "gratis."
Gratis / betalt. Det här är namnen på våra två produktsmaker.
Dimensionera. Vi måste ange ett "dimension" -parametervärde; i det här fallet använder jag "läge."
applicationIdSuffix. Eftersom vi vill skapa flera versioner av vår app måste vi ge varje APK en unik appidentifierare.
manifestPlaceholders. Varje projekt har en enda manifestfil som innehåller viktig information om projektets konfiguration. När du skapar flera byggvarianter vill du vanligtvis ändra några av dessa Manifest-egenskaper vid byggtid. Du kan använda Gradle build-filerna för att ange unika manifestposter för varje byggvariant, som sedan infogas i ditt manifest vid byggtid. I koden ovan ändrar vi värdet ”appName” beroende på om Gradle bygger den gratis eller den betalda versionen av vår app.

Skapa en anpassad Gradle-uppgift

Ibland kan du behöva anpassa byggprocessen med Gradle uppgifter.

En uppgift är en namngiven samling åtgärder som Gradle kommer att utföra när den utför en byggnad, till exempel generera en Javadoc. Gradle stöder många uppgifter som standard, men du kan också skapa anpassade uppgifter, som kan vara praktiska om du har en mycket specifik uppsättning bygginstruktioner i åtanke.

I det här avsnittet kommer vi att skapa en anpassad Gradle-uppgift som kommer att upprepas genom alla projektets byggvarianter (betaltDebug, betaltRelease, gratisDebug och gratisRelease), skapa en datum- och tidsstämpel och sedan lägga till denna information till varje genererad APK.

Öppna din build.gradle-fil på modulnivå och lägg till följande:

uppgift addDateAndTime () {// Iterera genom alla output build-varianter // android.applicationVariants.all {variant -> // Iterate genom alla APK-filer // variant.outputs.all {output -> // Skapa en instans av aktuellt datum och tid, i det angivna formatet // def dateAndTime = nytt datum (). -format ("yyyy-MM-dd: HH-mm") // Lägg till denna information i APK: s filnamn // def-filnamn = variant. name + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

Därefter måste vi berätta för Gradle när den bör utföra denna uppgift. Under en byggnad identifierar Gradle allt den behöver för att ladda ner och alla uppgifter den har att utföra och ordnar dem i en Directed Acyclic Graph (DAG). Gradle kommer sedan att utföra alla dessa uppgifter, i enlighet med den ordning som definieras i dess DAG.

För min app kommer jag att använda metoden ”WhenReady”, som säkerställer att vår uppgift kommer att kallas när DAG har fyllts och Gradle är redo att börja utföra sina uppgifter.

Lägg till följande i din build.gradle-fil på modulnivå:

// Kör denna uppgift // gradle.taskGraph.whenReady {addDateAndTime}

Låt oss lägga vår anpassade uppgift och vår byggvariantkod till testet genom att bygga detta projekt med hjälp av ett Gradle-kommando.

Bygg ditt projekt med Gradle wrapper

Du ger Gradle-kommandon med hjälp av Gradle wrapper (“gradlew”). Det här skriptet är det föredragna sättet att starta en Gradle-konstruktion, eftersom det gör exekveringen av builden oberoende av din version av Gradle. Denna separering kan vara användbar om du samarbetar med andra som inte nödvändigtvis har samma version av Gradle installerat.

När du utfärdar dina Gradle wrapper-kommandon använder du "gradlew" för Unix-liknande operativsystem, inklusive macOS, och "gradlew.bat" för Windows. Jag har en Mac, så jag kommer att använda "gradlew" -kommandon.

Du kan utfärda Gradle-kommandon från Android Studio:

I verktygsfältet Android Studio väljer du "Visa> Verktyg Windows> Terminal." Detta öppnar en terminalpanel längst ned i IDE-fönstret.
Ange följande kommando i terminalen:

./gradlew build

Android Studio borde se ut så här:

Tryck på "Enter" på tangentbordet. Gradle bygger nu ditt projekt.

Gradle lagrar alla de genererade APK: erna i projektets app / build / output / apk-katalog, så naviger till den här katalogen. Mappen “APK” bör innehålla flera mappar och undermappar. se till att Gradle har genererat en APK för var och en av dina buildvarianter, och att korrekt datum och tidsinformation har lagts till i varje fil.

Vilka andra Gradle-uppgifter finns tillgängliga?

Utöver alla anpassade uppgifter du kan skapa, stöder Gradle en lista med fördefinierade uppgifter utanför boxen. Om du är nyfiken på att se exakt vilka uppgifter som finns tillgängliga så:

Öppna Android Studios terminalfönster om det inte redan är öppet (genom att välja "Visa> Verktyg Windows> Terminal" från verktygsfältet i Android Studio).
Skriv följande i terminalen:

./gradlew -q-uppgifter

Tryck på "Enter" på tangentbordet.

Denna "uppgifter" -uppgift kommer nu att köras, och efter några ögonblick kommer terminalen att visa en lista över alla tillgängliga uppgifter för detta projekt, komplett med en kort beskrivning av varje uppgift.

Få ut mer av Gradle: Lägga till plugins

Gradle-fartyg med ett antal plugins förinstallerade, men du kan ytterligare utöka Gradle genom att lägga till nya plugins. Dessa plugins gör nya uppgifter tillgängliga för dina Android-projekt, till exempel innehåller Java-plugin-uppgifter som gör att du kan kompilera Java-källkod, köra enhetstester och skapa en JAR-fil, till exempel "compileJava," "compileText," "jar," "Javadoc," och "ren."

För att tillämpa ett plugin lägger du till "applicera plugin" -deklarationen i din build-gradel-fil på modulnivå, följt av namnet på plugin-programmet. Här tillämpar vi till exempel Java-plugin:

applicera plugin: java

Om du är nyfiken på att se vilka plugins som finns tillgängliga kan du kolla in Gradle Plugin-sökningen, som ger ett omfattande register över Gradle-plugins.

The Gradle Kotlin DSL

Som standard skriver du dina Gradle build-skript med hjälp av Groovy DSL, men om du är en av de många utvecklarna som har antagit Kotlin för Android-utveckling kan du föredra att skriva dina build-skript i Kotlin istället.

Till skillnad från Groovy, är Kotlin ett statiskt skrivet programmeringsspråk, så om du gör omkopplaren kommer dina build-filer att vara kompatibla med Android Studios autofullförande och källkodsnavigeringsfunktioner. Dessutom innebär att du flyttar från Groovy till Kotlin att du kommer att använda samma programmeringsspråk i hela ditt projekt, vilket kan göra utvecklingen mer enkel - särskilt om du inte känner till alltför Groovy!

Om du vill börja skriva din bygglogik i Kotlin, måste du ställa in Gradle Kotlin DSL och följa anvisningarna i migreringsguiden.

Avslutar

I den här artikeln utforskade vi Android Studios verktyg för att bygga automatisering och beroende. Vi undersökte hur Gradle automatiserar byggprocessen utanför boxen och hur du kan ändra byggprocessen genom att redigera projektets Gradle build-filer, inklusive skapa anpassade Gradle-uppgifter och generera flera buildvarianter från ett enda projekt.

Har du utökat Gradle för att automatisera andra delar av Android-byggprocessen? Låt oss veta i kommentarerna nedan!