Understanding The Gradle Build Tool in Android Development
To create an android app, take a cup of SDK, a teaspoon of your code and resources then add a sprinkle of libraries, mix thoroughly and bake in Gradle Build.
Do you know that you can actually write native android apps without using the Android Studio IDE?, all you need is a text editor, a command line and the Gradle build tool, yes it’s possible, but it’s more work/time and life is too short for that. “Why do android developers use Android Studio then?”… you might ask…using Android Studio for android development saves time, is easier and gives you less buggy apps as Android Studio provides a graphical
interface to Gradle, and also to other tools for creating layouts, reading logs, and debugging.
For those with a programming background (java programming), you might want to compare the Gradle build tool with the Apache ANT build tool which is a software tool for automating software build process that originated from the Apache Tomcat project in early 2000, it was a replacement for the Make build tool of Unix. You are quite correct, they are both similar, but Gradle is much more powerful than ANT, yes I said it. Gradle can compile and
deploy code, just like ANT, but it also uses Maven to download any third-party libraries your code needs. Unlike other XML-based build tools like Maven or
ANT, Gradle is written in a procedural, scripting language — Groovy, which is used for both configuring a build and adding extra functionality, that means you can easily create quite complex builds with Gradle…I hope you get the point on why I initially said: “Gradle is much more Powerful than ANT”.
Android Studio is a special version of IntelliJ IDEA that interfaces with the Android Software Development Kit (SDK) and the Gradle build system. It uses the Gradle build system to compile and deploy apps. When you click the run button in Android Studio, most of the actual work is done by the external build tool called Gradle.
When I was developing my first android app to be released to the Google Play store, I had a lot of questions and confusions about the Gradle build tool and how to use it in android studio. In this article, I will be answering some common questions which will help you in understanding the Gradle build tool better.
Why all the noise about Gradle, and what does it do for me?
Here are some of the things that Gradle does:
- Locates and downloads the correct versions of any third-party libraries you need.
- Calls the correct build tools in the correct sequence to turn all of your source code and resources into a deployable app.
- Installs and runs your app on an Android device.
- A whole bunch of other stuff, like running tests and checking the quality of your code.
It’s hard to list all of the things that Gradle does because it’s designed to
be easily extensible.
Every time I create a new project, Android Studio creates two files called “build.gradle”, what do they do?
One of these files is in your project folder (Myproject/build.gradle), and contains a small amount of information that specifies the basic settings of your app, such as what version of Gradle to use, and which online repository:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath ‘com.android.tools.build:gradle:3.2.1’
}
}
allprojects {
repositories {
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}You will normally only need to change the code in this file if you want to install a third-party plug-in, or need to specify another place that contains downloadable libraries.
The second “build.gradle” file lives inside the app folder within your
project (Myproject/app/build.gradle). This file tells Gradle how to build all of the code in your main Android module. It’s where the majority of your application’s properties are set, such as the level of the API that you’re targeting, and the specifics of which external libraries your app will need:
apply plugin: ‘com.android.application’
android {
compileSdkVersion 28
buildToolsVersion “28.0.1”defaultConfig {
applicationId “com.ovosoftware.example”
minSdkVersion 15
targetSdkVersion 28
versionCode 1
versionName “1.0”
testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner”
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
}
}
}
dependencies {
implementation fileTree(dir: ‘libs’, include: [‘*.jar’])
testImplementation ‘junit:junit:4.12’ implementation 'androidx.appcompat:appcompat:1.1.0-alpha05'
implementation 'androidx.constraintlayout:constraintlayout:1.1.2'
}
What about the “settings.gradle” file, is it part of Gradle too?
Android projects are multi-project Gradle builds. The “settings.gradle” file shows which sub-directories hold their own sub-projects. The default file contents is;
include ‘:app’The include statement indicates that the app sub-directory is the only additional sub-project. If you add an Android Library project, it too will be added to this file.
Also in my project folder, I see two strange files; gradlew and gradlew.bat, what are they?
Every time you create a new application, Android Studio includes an install of the Gradle build tool. If you look in the project directory, you will see two files called gradlew and gradlew.bat. These files contains scripts that allow you to build and deploy your app from the command line.To get more familiar with Gradle, open a command prompt or terminal on your development machine and change into the top-level directory of your project (that is where the gradlew and gradlew.bat are located). Then run one of the gradlew scripts with the parameter tasks. Gradle will tell you some of the tasks that it can perform for you. Let’s quickly brush through some of the most useful ones;
- The Check Task: The check task performs static analysis on the source code in your application. Think of it as your coding friend, who scoots through your files looking for coding errors. By default, the check task uses the lint tool to look for common Android programming errors. It
will generate a report in app/build/reports/lint-results.html - The clean installDebug Task: This task will do a complete compile and install of your application on your connected device. You can obviously do this from the IDE, but it can be useful to do this from the command line if, for example, you want to automatically build your application on an Integration Server.
- The androidDependencies Task: This task, automatically pull down any libraries your application requires, and some of those libraries will automatically pull down other libraries, which might pull down other libraries and…well, you get the idea.
Even though your app/build.gradle file might only mention a couple of libraries, your application might need to install many dependent libraries for your app. So it’s sometimes useful to see which libraries your application requires, and why. That’s what the androidDependencies task is for: it displays a tree of all of the libraries in your app.
What are the common edits done on these gradle files?
You can specify the minimum and target Android SDK versions and other default properties. The gradle file contains blocks and properties. Each block has a specified set of properties which can be edited. All you need do is change the value of the property, some common properties and their specified blocks include;
- In the top level build.gradle file(Myproject/build.gradle)
The Gradle distribution does not include Android functionality by default. Google provides an Android plug-in for Gradle, which allows easy configuration of Android projects. The buildscript block in the top-level build file tells Gradle where to download that plug-in. As you can see, by default the plug-in is downloaded from jcenter, which means the Bintray JCenter Artifactory repository. Other repositories are supported (especially mavenCentral(), the default Maven repository), but JCenter is now the default.
The allprojects block indicates that the top-level project and any subprojects all default to using the jcenter() repository to resolve any Java library dependencies.
The clean task has been added to the top-level build. The type: Delete part indicates that the new task is a customized instance of the built-in Delete task from Gradle. In this case, the task removes the build directory from the root project, which defaults to a build folder at the top level.
- In the Gradle build file for the app subproject (Myproject/app/build.gradle)
The apply property in Gradle adds the Android plug-in to the build system,
which enables the android block Domain Specific Language (DSL) configuration.
The android block is the entry point for the Android DSL. Here you must specify the compilation target using compileSdkVersion and the build tools version via buildToolsVersion. Both of these values should be assigned to the most recent available version, as they are backward compatible and include all current bug fixes.
The defaultConfig block inside android shows several properties:
applicationId
The “package” name of the application, which must be unique in the Google Play store. This value can never change during the life of your app; changing it will result in your app being treated as a brand new application, and existing users will not see changes as an update. Prior to the move to Gradle, this was the pack age attribute of the root element of the Android Manifest. The two can now be decoupled.minSdkVersion
The minimum Android SDK version supported by this application. Devices earlier than this will not see this application when accessing the Google Play store.targetSdkVersion
The version of Android intended for this application. Android Studio will issue a warning if this is anything other than the latest version, but you’re free to use any version you like.versionCode
An integer representing this version of your app relative to others. Apps normally use this during the upgrade process.versionName
A string representing the release version of your app, shown to users. Normally in the form of a<major>.<minor>.<version>string.
The dependencies block consists of three lines. The first, fileTree dependency, means that all files ending in .jar in the libs folder are added to the compile classpath. The second line tells Gradle to download version 4.12 of JUnit and add it to the “test compile” phase, meaning that JUnit classes will be available in the src/androidTest/java source tree, as well as the (optional) src/test/java tree, which can be added for pure unit tests (i.e., those that do not involve the Android API). The full syntax for a dependency calls out the group, name, and version numbers explicitly
If Gradle can easily be extended, can I write my own custom task (with Groovy) or from other developers in the form of plug-ins?
Sure!, as well as writing your own tasks, you can also install Gradle plugins.
A plug-in can greatly extend your build environment. Want to write Android code in Clojure? Want your build to automatically interact with source control systems like Git? How about spinning up entire servers in Docker and then testing your application on them? You can do these things, and many, many more by using Gradle plug-ins. For details on what plug-ins are available, see here.
I really do hope you now understand the basic concepts of Gradle build tool and how to use it. If you have any more questions outside the these, you can drop me a mail, I will do my best to give you an answer and update this article. Don’t forget to clap too if you really enjoyed the article.
