Inhoud

• De Gradle-buildbestanden verkennen
• 1. instellingen. Gradle
• 2. build.gradle (projectniveau)
• 3. build.gradle (moduleniveau)
• De afhankelijkheden van uw project verklaren: Lokale bibliotheken
• Een build-afhankelijkheid toevoegen: Remote repositories
• Verbinding maken met een externe repository
• Afhankelijkheid op afstand verklaren
• Meerdere APK's genereren: hoe buildvarianten te maken
• Een aangepaste Gradle-taak maken
• Bouw uw project met de Gradle-wrapper
• Welke andere Gradle-taken zijn beschikbaar?
• Meer uit Gradle halen: plug-ins toevoegen
• De Gradle Kotlin DSL
• Afsluiten

In plaats van Java, XML of Kotlin gebruiken deze Gradle-buildbestanden de Groovy-gebaseerde domeinspecifieke taal (DSL). Als je niet bekend bent met Groovy, zullen we elk van deze Gradle build-bestanden lijn voor lijn bekijken, dus aan het einde van dit artikel kun je eenvoudige Groovy-code lezen en schrijven.

Gradle heeft als doel uw leven gemakkelijker te maken, door een aantal standaardinstellingen te bieden die u vaak kunt gebruiken met minimale handmatige configuratie - wanneer u klaar bent om uw project te bouwen, drukt u eenvoudig op de knop "Uitvoeren" van Android Studio en Gradle start het bouwproces voor jou.

Ondanks de "conventie over configuratie" -benadering van Gradle, als de standaardinstellingen niet helemaal voldoen aan uw behoeften, kunt u het bouwproces aanpassen, configureren en uitbreiden en zelfs de Gradle-instellingen aanpassen om zeer specifieke taken uit te voeren.

Omdat de Gradle-scripts zich in hun eigen bestanden bevinden, kunt u het buildproces van uw applicatie op elk gewenst moment wijzigen, zonder de broncode van uw applicatie aan te raken. In deze tutorial zullen we het bouwproces aanpassen met behulp van smaken, bouwvarianten en een aangepaste Gradle-taak - allemaal zonder ooit raakt onze applicatiecode aan.

De Gradle-buildbestanden verkennen

Telkens wanneer u een project maakt, genereert Android Studio dezelfde verzameling Gradle-buildbestanden. Zelfs als u een bestaand project in Android Studio importeert, is dit het geval nog steeds maak exact dezelfde Gradle-bestanden en voeg ze toe aan uw project.

Laten we, om een ​​beter begrip van Gradle en de Groovy-syntaxis te krijgen, regel voor regel kijken naar elk van de Gradle-buildbestanden van Android.

1. instellingen. Gradle

In het bestand settings.gradle definieert u alle modules van uw toepassing op naam, met behulp van het trefwoord 'include'. Als u bijvoorbeeld een project had bestaande uit een "app" en een "secondModule", zou uw bestand settings.gradle er ongeveer zo uitzien:

include: app,: secondmodule rootProject.name = MyProject

Afhankelijk van de grootte van uw project kan dit bestand aanzienlijk langer zijn.

Tijdens het bouwproces onderzoekt Gradle de inhoud van de instellingen van uw project. Gradle-bestand en identificeert alle modules die het moet opnemen in het bouwproces.

2. build.gradle (projectniveau)

Het build.gradle-bestand op projectniveau bevindt zich in de hoofdmap van uw project en bevat instellingen die worden toegepast alle uw modules (door Gradle ook "projecten" genoemd).

Gebruik dit bestand om plug-ins, repositories, afhankelijkheden en configuratie-opties te definiëren die van toepassing zijn op elke module in uw Android-project. Merk op dat als u Gradle-taken definieert binnen het build.gradle-bestand op projectniveau, het nog steeds mogelijk is om deze taken voor individuele modules te vervangen of uit te breiden, door hun overeenkomstige moduleniveau build.gradle-bestand.

Een typisch build.gradle-bestand op projectniveau ziet er ongeveer zo uit:

buildscript {repositories {google () jcenter ()} afhankelijkheden {classpath com.android.tools.build:gradle:3.5.0-alpha06 // OPMERKING: plaats uw toepassingsafhankelijkheden hier niet; ze horen // in de afzonderlijke module build.gradle-bestanden}} alleprojecten {repositories {google () jcenter ()}} taak opschonen (type: Verwijderen) {delete rootProject.buildDir}

Dit build.gradle-bestand op projectniveau is verdeeld in de volgende blokken:

• Buildscript. Dit bevat instellingen die nodig zijn om de build uit te voeren.
• Repositories. Gradle is verantwoordelijk voor het lokaliseren van de afhankelijkheden van uw project en deze beschikbaar te maken in uw build. Niet alle afhankelijkheden komen echter uit dezelfde repository, dus u moet alle repositories definiëren die Gradle moet doorzoeken om de afhankelijkheden van uw project op te halen.
• Afhankelijkheden. Deze sectie bevat uw plug-inafhankelijkheden, die worden gedownload en opgeslagen in uw lokale cache. Je zou moeten niet definieer eventuele module-afhankelijkheden binnen dit blok.
• Allprojects. Hier definieert u de opslagplaatsen die beschikbaar moeten zijn alle van de modules van uw project.

3. build.gradle (moduleniveau)

Dit is het build.gradle-bestand op moduleniveau, dat aanwezig is in elke module gedurende uw project. Als uw Android-project uit meerdere modules bestaat, bestaat het ook uit meerdere build.gradle-bestanden op moduleniveau.

Elk build.gradle-bestand op moduleniveau bevat de pakketnaam, versienaam en versiecode van uw project, plus de minimum- en doel-SDK voor deze specifieke module.

Een build.gradle-bestand op moduleniveau kan ook zijn eigen unieke set buildinstructies en afhankelijkheden hebben. Als u bijvoorbeeld een applicatie met een Wear OS-component maakt, bestaat uw Android Studio-project uit een afzonderlijke smartphone / tablet-module en een Wear-module - aangezien ze zich volledig op verschillende apparaten richten, hebben deze modules drastisch verschillende afhankelijkheden!

Een eenvoudig build.gradle-bestand op moduleniveau ziet er ongeveer zo uit:

plug-in toepassen: com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.nest.runner.accessure {ndroid_programmeernl getDefaultProguardFile (proguard-android-optimal.txt), proguard-rules.pro}}} afhankelijkheden {implementatie fileTree (dir: libs, include:) implementatie androidx.appcompat: appcompat: 1.0.2 implementatie 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}

Laten we elk van deze secties nader bekijken:

• plug-in toepassen. Dit is een lijst met plug-ins die nodig zijn om deze module te bouwen. De plug-in com.android.application is nodig om het Android-specifieke build-proces in te stellen, dus dit wordt automatisch toegevoegd.
• android. Hier moet u alle platformspecifieke opties van de module plaatsen.
• compileSdkVersion. Dit is het API-niveau waarmee deze module is gecompileerd. U kunt geen functies van een API gebruiken die hoger zijn dan deze waarde.
• buildToolsVersion. Dit geeft de versie van de compiler aan. In Gradle 3.0.0 en hoger is buildToolsVersion optioneel; als u geen buildToolsVersion-waarde opgeeft, gebruikt Android Studio standaard de meest recente versie van Build Tools.
• defaultConfig. Dit bevat opties die worden toegepast op alle buildversies van uw app, zoals uw debug- en release-builds.
• Applicatie ID. Dit is de unieke identificatie van uw applicatie.
• minSdkVersion. Deze parameter definieert het laagste API-niveau dat deze module ondersteunt.
• targetSdkVersion. Dit is het maximale API-niveau waarop uw applicatie is getest. Idealiter zou u uw toepassing moeten testen met de nieuwste API, wat betekent dat de waarde targetSdkVersion altijd gelijk zal zijn aan de waarde compileSdkVersion.
• versionCode. Dit is een numerieke waarde voor uw applicatieversie.
• versionName. Dit is een gebruikersvriendelijke tekenreeks die uw applicatieversie vertegenwoordigt.
• buildTypes. Android ondersteunt standaard twee buildtypen: debug en release. U kunt de blokken "debug" en "release" gebruiken om de typespecifieke instellingen van uw toepassing op te geven.
• afhankelijkheden. Hier definieert u bibliotheken waarvan deze module afhankelijk is.

De afhankelijkheden van uw project verklaren: Lokale bibliotheken

U kunt extra functionaliteit beschikbaar maken voor uw Android-projecten door een of meer projectafhankelijkheden toe te voegen. Deze afhankelijkheden kunnen lokaal zijn, of ze kunnen worden opgeslagen in een externe repository.

Om een ​​afhankelijkheid van een lokaal JAR-bestand aan te geven, moet u die JAR toevoegen aan de directory 'libs' van uw project.

U kunt vervolgens het build.gradle-bestand op moduleniveau wijzigen om een ​​afhankelijkheid van dit bestand aan te geven. Hier verklaren we bijvoorbeeld een afhankelijkheid van een JAR voor 'mijn bibliotheek'.

implementatiebestanden (libs / mylibrary.jar)

Als uw map 'libs' meerdere JAR's bevat, is het misschien eenvoudiger om eenvoudig aan te geven dat uw project afhankelijk is van alle bestanden in de map 'libs', bijvoorbeeld:

implementatie fileTree (dir: libs, include:)

Een build-afhankelijkheid toevoegen: Remote repositories

Als een bibliotheek zich in een externe repository bevindt, moet u de volgende stappen uitvoeren:

• Definieer de repository waar deze afhankelijkheid zich bevindt.
• Verklaar de individuele afhankelijkheid.

Verbinding maken met een externe repository

De eerste stap is om Gradle te vertellen welke repository (of repositories) het moet controleren om alle afhankelijkheden van uw project op te halen. Bijvoorbeeld:

repositories {google () jcenter ()}}

Hier zorgt de regel “jcenter ()” ervoor dat Gradle de JCenter-repository controleert, een gratis, openbare repository die wordt gehost bij bintray.

Als u of uw organisatie een persoonlijke repository onderhoudt, moet u ook de URL van deze repository toevoegen aan uw afhankelijkheidsverklaring. Als de repository met een wachtwoord is beveiligd, moet u ook uw aanmeldingsgegevens opgeven, bijvoorbeeld:

repositories {mavenCentral () maven {// Configureer de doel-URL // url "http://repo.mycompany.com/myprivaterepo"} maven {credentials {gebruikersnaam myUsername wachtwoord myPassword} url "http://repo.mijnbedrijf.com / myprivaterepo "}

Als een afhankelijkheid aanwezig is in meerdere opslagplaatsen, selecteert Gradle de "beste" versie van deze afhankelijkheid, op basis van factoren zoals de leeftijd van elke opslagplaats en de statische versie.

Afhankelijkheid op afstand verklaren

De volgende stap is het aangeven van de afhankelijkheid in uw build.gradle-bestand op moduleniveau. U voegt deze informatie toe aan het blok "afhankelijkheden" met een van de volgende opties:

• Implementatie. Dit is een normale afhankelijkheid die u nodig hebt wanneer u uw project bouwt. Een "implementatie" afhankelijkheid zal overal aanwezig zijn alle jouw builds.
• Testimplementation. Dit is een afhankelijkheid die nodig is om de testbron van uw toepassing te compileren en op JVM gebaseerde tests uit te voeren. Wanneer u een afhankelijkheid markeert als "Testimplementatie", weet Gradle dat het geen taken voor deze afhankelijkheid hoeft uit te voeren tijdens een normale build, wat kan helpen de bouwtijd te verkorten.
• Androidtestimplementation. Dit is een afhankelijkheid die vereist is bij het uitvoeren van tests op een apparaat, bijvoorbeeld het Espresso-framework is een algemene 'Androidtestimplementation'.

We definiëren een externe afhankelijkheid, met behulp van een van de bovenstaande trefwoorden, gevolgd door de attributen van de groep, naam en versie, bijvoorbeeld:

afhankelijkheden {implementatie fileTree (dir: libs, include:) implementatie androidx.appcompat: appcompat: 1.0.2 implementatie androidx.constraintlayout: constraintlayout: 1.1.3 test Implementatie junit: junit: 4.12 androidTestImplementatie androidx.test.ext: junit: 1.1.0 androidTestImplementation androidx.test.espresso: espresso-core: 3.1.1}

Meerdere APK's genereren: hoe buildvarianten te maken

Soms moet u meerdere versies van uw toepassing maken. U wilt bijvoorbeeld een gratis versie en een betaalde versie uitbrengen, die enkele extra functies bevat.

Dit is een build-taak waar Gradle je mee kan helpen, dus laten we eens kijken hoe je het build-proces zou wijzigen om meerdere APK's van een enkel project te maken:

• Open uw strings.xml-bestand en verwijder uw oorspronkelijke applicatienaamstring.
• Definieer vervolgens de namen van elke productsmaak die u wilt maken; in dit geval gebruik ik:

Mijn gratis app Mijn betaalde app

• Open uw AndroidManifest.xml-bestand en vervang android: label = ”@ string / app_name” door:

android: label = "$ {appName}"

• Open uw build.gradle-bestand op moduleniveau en voeg het volgende toe aan het "android" -blok:

flavodimensions "mode" productFlavours {gratis {dimensie "mode" applicationIdSuffix ".free" manifestPlaceholders =} betaald {dimensie "mode" applicationIdSuffix ".paid" manifestPlaceholders =}}}

Laten we eens kijken wat er hier gebeurt:

• flavorDimensions. De Android-plug-in maakt build-varianten door smaken uit verschillende dimensies te combineren. Hier creëren we een smaakdimensie die bestaat uit "gratis" en "betaalde" versies van onze app. Op basis van de bovenstaande code genereert Gradle vier buildvarianten: paidDebug, paidRelease, freeDebug en freeRelease.
• productFlavors. Dit specificeert een lijst met smaken en hun instellingen, die in de bovenstaande code "betaald" en "gratis" zijn.
• Gratis / betaald. Dit zijn de namen van onze twee productsmaken.
• Dimensie. We moeten een parameterwaarde voor 'dimensie' opgeven; in dit geval gebruik ik de "modus".
• applicationIdSuffix. Omdat we meerdere versies van onze app willen maken, moeten we elke APK een unieke app-ID geven.
• manifestPlaceholders. Elk project heeft één manifestbestand met belangrijke informatie over de configuratie van uw project. Wanneer u meerdere buildvarianten maakt, wilt u meestal enkele van deze Manifest-eigenschappen tijdens de build aanpassen. U kunt de Gradle-buildbestanden gebruiken om unieke Manifest-vermeldingen op te geven voor elke buildvariant, die vervolgens tijdens de build in uw Manifest worden ingevoegd. In de bovenstaande code wijzigen we de waarde “appName” afhankelijk van of Gradle de gratis of de betaalde versie van onze app bouwt.

Een aangepaste Gradle-taak maken

Soms moet u het bouwproces aanpassen met Gradle taken.

Een taak is een benoemde verzameling acties die Gradle uitvoert tijdens het uitvoeren van een build, bijvoorbeeld het genereren van een Javadoc. Gradle ondersteunt standaard veel taken, maar u kunt ook aangepaste taken maken, wat handig kan zijn als u een zeer specifieke set bouwinstructies in gedachten hebt.

In dit gedeelte maken we een aangepaste Gradle-taak die alle buildvarianten van ons project doorloopt (paidDebug, paidRelease, freeDebug en freeRelease), een datum- en tijdstempel maakt en deze informatie toevoegt aan elke gegenereerde APK.

Open uw build.gradle-bestand op moduleniveau en voeg het volgende toe:

task addDateAndTime () {// Doorloop alle output build-varianten // android.applicationVariants.all {variant -> // Doorloop alle APK-bestanden // variant.outputs.all {output -> // Maak een instantie van de huidige datum en tijd, in de opgegeven indeling // def dateAndTime = new Date (). format ("jjjj-MM-dd: HH-mm") // Voeg deze informatie toe aan de APK-bestandsnaam // def fileName = variant. name + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

Vervolgens moeten we het aan Gradle vertellen wanneer het zou deze taak moeten uitvoeren. Tijdens een build identificeert Gradle alles wat het moet downloaden en alle taken die het moet uitvoeren, en rangschikt ze in een Directed Acyclic Graph (DAG). Gradle voert vervolgens al deze taken uit, in de volgorde die is gedefinieerd in de DAG.

Voor mijn app ga ik de "whenReady" -methode gebruiken, die ervoor zorgt dat onze taak wordt aangeroepen zodra de DAG is ingevuld en Gradle klaar is om zijn taken uit te voeren.

Voeg het volgende toe aan uw build.gradle-bestand op moduleniveau:

// Voer deze taak uit // gradle.taskGraph.whenReady {addDateAndTime}

Laten we onze aangepaste taak zetten en onze build-variantcode voor de test, door dit project te bouwen met een Gradle-opdracht.

Bouw uw project met de Gradle-wrapper

U geeft Gradle-opdrachten uit met de Gradle-wrapper ("gradlew"). Dit script is de geprefereerde manier om een ​​Gradle-build te starten, omdat het de uitvoering van de build onafhankelijk maakt van uw versie van Gradle. Deze scheiding kan handig zijn als u samenwerkt met anderen die misschien niet noodzakelijk dezelfde versie van Gradle hebben geïnstalleerd.

Wanneer u uw Gradle wrapper-opdrachten geeft, gebruikt u "gradlew" voor Unix-achtige besturingssystemen, inclusief macOS, en "gradlew.bat" voor Windows. Ik heb een Mac, dus ik gebruik "gradlew" -opdrachten.

U kunt Gradle-opdrachten uitvoeren vanuit Android Studio:

• Selecteer in de Android Studio-werkbalk "Beeld> Windows-hulpprogramma's> Terminal". Hiermee wordt een terminalpaneel onderaan het IDE-venster geopend.
• Voer de volgende opdracht in de terminal in:

./gradlew build

Android Studio zou er ongeveer zo uit moeten zien:

• Druk op de Enter-toets op uw toetsenbord. Gradle bouwt nu uw project.

Gradle slaat alle gegenereerde APK's op in de app / build / outputs / apk-directory van uw project, dus ga naar deze directory. De map "APK" moet verschillende mappen en submappen bevatten; zorg ervoor dat Gradle een APK heeft gegenereerd voor elk van uw buildvarianten en dat de juiste datum- en tijdinformatie aan elk bestand is toegevoegd.

Welke andere Gradle-taken zijn beschikbaar?

Naast alle aangepaste taken die u mogelijk maakt, ondersteunt Gradle een lijst met vooraf gedefinieerde taken uit de doos. Als je nieuwsgierig bent om precies te zien welke taken beschikbaar zijn, dan:

• Open het Terminal-venster van Android Studio, als dit nog niet is geopend (door "Beeld> Extra Windows> Terminal" te selecteren op de werkbalk van Android Studio).
• Typ het volgende in de Terminal:

./gradlew -q taken

• Druk op de Enter-toets op uw toetsenbord.

Deze "taken" -taak wordt nu uitgevoerd en na enkele ogenblikken geeft de Terminal een lijst weer met alle beschikbare taken voor dit project, compleet met een korte beschrijving van elke taak.

Meer uit Gradle halen: plug-ins toevoegen

Gradle wordt geleverd met een aantal vooraf geïnstalleerde plug-ins, maar u kunt Gradle verder uitbreiden door nieuwe plug-ins toe te voegen. Deze plug-ins maken nieuwe taken beschikbaar voor uw Android-projecten. De Java-plug-in bevat bijvoorbeeld taken waarmee u de Java-broncode kunt compileren, unit-tests kunt uitvoeren en een JAR-bestand kunt maken, zoals "compileJava", "compileText", "jar", 'Javadoc' en 'schoon'.

Als u een plug-in wilt toepassen, voegt u de verklaring 'plug-in toepassen' toe aan uw build.gradle-bestand op moduleniveau, gevolgd door de naam van de plug-in. Hier passen we bijvoorbeeld de Java-plug-in toe:

plugin toepassen: java

Als je nieuwsgierig bent om te zien welke plug-ins beschikbaar zijn, kijk dan eens naar Gradle Plugin search, dat een uitgebreid register van Gradle-plug-ins biedt.

De Gradle Kotlin DSL

Standaard schrijf je je Gradle build-scripts met behulp van de Groovy DSL, maar als je een van de vele ontwikkelaars bent die Kotlin voor Android-ontwikkeling hebben geadopteerd, dan kun je in plaats daarvan liever je build-scripts in Kotlin schrijven.

In tegenstelling tot Groovy is Kotlin een statisch getypte programmeertaal, dus als u de overstap maakt, zijn uw build-bestanden compatibel met de functies voor automatisch aanvullen en broncode van Android Studio. Bovendien betekent de overstap van Groovy naar Kotlin dat je dezelfde programmeertaal gebruikt in je project, wat de ontwikkeling eenvoudiger kan maken - vooral als je niet al te vertrouwd bent met Groovy!

Als u wilt beginnen met het schrijven van uw buildlogica in Kotlin, moet u de Gradle Kotlin DSL instellen en de instructies in de migratiehandleiding volgen.

Afsluiten

In dit artikel hebben we de build-tool van Android Studio voor build-automatisering en afhankelijkheid onderzocht. We hebben onderzocht hoe Gradle het bouwproces out-of-the-box automatiseert, en hoe u het bouwproces kunt wijzigen door de Gradle-buildbestanden van uw project te bewerken, inclusief het maken van aangepaste Gradle-taken en het genereren van meerdere buildvarianten van een enkel project.

Heb je Gradle uitgebreid om andere delen van het Android-buildproces te automatiseren? Laat het ons weten in de reacties hieronder!