Many Android Developers find that Eclipse provides all the build environment they need. However, developers who require complicated external dependencies (often involving enterprise apps) will be familiar with the Ant build system.

Ant is the build system used by default in Eclipse and is hugely popular with Java developers. Ant addressed a number of issues seen with more traditional build systems such as Make. For example, Make uses a unique syntax and builds projects using platform-specific commands. Ant uses XML as its base syntax and is platform independent – making it a better build system for a platform independent language such as Java. Furthermore, Ant comes with a host of predefined “tasks” that help customise your build. Compiling, installing, patching and much, much more is supported. But Ant also has limitations. Using XML as the base syntax for Ant makes verbose build files. And Ant lacks native support for accessing Maven or Ivy dependencies.


Enter the Gradle build engine. The Gradle build system addresses issues like these. Gradle was designed with Java developers in mind, and the first thing a developer will notice is the system’s syntax. Gradle’s build scripts are written in a Gradle DSL (Domain Specific Language) based on Groovy.  Groovy is essentially a scripting language with Java syntax.

The Gradle DSL also allows build files to be substantially less verbose than Ant’s XML based files. In addition to all that, Gradle builds in support for Maven repositories. Adding a Maven dependency (for example on Google’s Guava project) is only a couple of lines of code. With all these benefits, Gradle is quickly gaining developer interest. Gradle has already been adopted by Hibernate, EADS and many more.

There is another important factor in Gradle’s emergence that is specific to mobile App developers. Gradle is the build system used by Android Studio. And Android Studio is the preferred IDE of the Android development team.  Android Studio is currently under development, and destined to become the official Android IDE once it is completed. The beta version can be downloaded from

Since Gradle is the future of Android build scripts, let’s walk through a basic example. I created the most basic project I could in Android Studio. A mobile app with one blank activity. The project structure that Android Studio generated contained two build files – both named build.gradle. Don’t be alarmed, this is perfectly normal. We just need to make sure we are clear about which build.gradle file we are discussing at all times.

The build.gradle file in the top level of your project structure (the project level file) contains settings for all the sub-projects in the project. In Android Studio these sub-project’s are referred to as modules – a project would be your App but the modules could be the mobile, wear or TV implementation or even a library. The build.gradle file in the “mobile” sub-project (the module level file) contains settings for the mobile app module. Let’s look at this project level file first.


There are two main tasks in the project level build.gradle file, buildscript and allprojects. The buildscript task is used to configure the build – that is what will be used to build our project. The repositories sub-task calls the method “jCenter()” which provides access to Bintray’s Maven repository. The dependencies sub-task sets a classpath dependency on a Maven artifact. Specifically, the library that contains the Android plugin for Gradle version 0.12.2. We’ll discuss more about Gradle plugins a little later. It is perhaps worth noting that, depending on the version of Android Studio you are using, your build.gradle file may reference a different version of Gradle.

The allprojects task sets some configuration for all sub-projects in the build – that is configuration for the sub-projects that will be built. In this task the repositories sub-task is again used to provide access to Bintray’s Maven repository.

Next let’s consider our example’s module level build script.


The first line in our module level build.gradle file applies the Android plugin. Recall we set a classpath dependency in the project level build.gradle file so that this plugin could be loaded. But we’ve yet to discuss what Gradle plugin’s are.

Like all build systems, without instructions Gradle won’t do very much. Your build scripts will require some instructions on how to build your Android application. All Android applications will share a base set of tasks. For example, they all need to be compiled and bundled into an APK. Instead of requiring you to write this base set for all applications, Gradle uses plugins to define this common build behaviour. The Android plugin for Gradle defines the common build tasks required for Android. There are other plugins as well, including a plugin for non-Android Java projects.

The first main task in the module level build.gradle file is the android task. This task is used to configure the Android build. The only required fields are the compileSdkVersion and buildToolsVersion parameters. They set the SDK version that the build is compiled and linked with, and the build tools version that will be used respectively. The defaultConfig and buildTypes sub-tasks are strictly optional but are added by default when Android Studio creates the build files.

The defaultConfig task allows configuration of the build manifest. The applicationId parameter actually sets the packageName. The remaining parameters are more self explanatory.

The buildTypes task configures rules for the builds. In the example, there are rules for release builds only. The “runProguard false” directive instructs Gradle not to run ProGuard on the release build. The proguardFiles parameter (although redundant given that ProGuard has been disabled) sets the ProGuard files to be used.

The last task is the dependencies task. Within it, a compile time dependency on all jar files included in the libs directory of the project is set. You may not have any jar’s in your libs directory yet but if you add any this rule will automatically link them.

And that’s all there is to it. Well that’s all there is to this simple example project. As with other build environments there is so much that can be done with Gradle.

Stay tuned because next up we’ll be discussing integrating Golgi into your Gradle build.

In the meantime here are a few resources to help you get started with Android Studio and Gradle. Enjoy!

Back to Articles

Leave a Reply