ATAT. Know more about THE AMAZING Gradle in Android Studio.

Once Gradle is joined Android Development, life is much easier NOW!

We will continue with the second part of our blog which is getting familiar with Gradle the building system for Android Studio. This blog is a part of Android Tips And Tricks (ATAT) for Building a Robust Android App Series.

Getting Familiar with Gradle Series :

  1. Know more about THE AMAZING Gradle in Android Studio <== HERE
  2. Gradle Structure and Tasks in Android Studio, Let’s Dig Deeper
  3. Some different ways of Managing Gradle Dependencies
  4. Gradle Tasks and Plugins, Something more Customized
  5. Gradle Product Flavors and Build Types

Building a Java project doesn’t seem too bad but Android applications on the other hands are beasts. That Java source is not compiled as standard Java bytecode but to custom bytecode for the Android runtime.

Android has three different types of resources that all get packaged differently like below in the image:

  • There are additional wrinkle in that the resources that you define need to be pooled together with resources coming from your included libraries.
  • And the identifiers of all those resources need to be know beforehand, before anything else get compiled.
  • Also, android applications must be cryptographically signed. When we put all together it will be something like the below image

Before Android Studio you were using Eclipse for your development purposes and you didn’t know how to build your Android APK without Eclipse. You can do this on the command line, but you have to learn what each tool (dx, aapt) does in the SDK. Eclipse saved us all from these low level but important, fundamental details by giving us their own build system.

Now, considering you might want to build both Debug and Release versions of your android application, you might also want to build Free and Paid variance. So, the point is that the process of building android application is not something we can do by hand, that’s why we need a more robust solution, that’s why we need Gradle.

So, what Gradle ?

Accelerate developer productivity.

Gradle helps teams build, automate and deliver better software. It is an open-source build automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven for declaring the project configuration. Gradle uses a directed acyclic graph (“DAG”) to determine the order in which tasks can be run, we will know more about tasks during the blog.

Gradle was designed for multi-project builds, which can grow to be quite large. It supports incremental builds by intelligently determining which parts of the build tree are up to date; any task dependent only on those parts does not need to be re-executed.

So, why Gradle ?

Why using Gradle ?

Gradle solves some the most hard problems faced by Android Developers. How to automate building and testing applications to achieve rapid productivity. How to manage dependencies and variations that allow professional developers to pump out dozens of variances of android applications with one click, or build a suite of android applications and deal officially with android apps that are very large. Other strengths of Gradle include the compact and powerful build language used to write its build scripts.

Want to know more about Gradle, here we are!

Here we go!

Gradle is an extensible domain model. At the heart of this model is the concept of tasks. A task is a self contained unit of work that Gradle can reason about. At the core of a task is its action, for example we might declare a task to compile some Java sources or to copy some files from one directory to another. A task can perform some action in isolation but it can also declare dependencies on other tasks. Gradle will ensure that all these dependencies are run and ensure all of their dependencies and so on.

Gradle has to do a significant amount of work to start up. Mainly because it requires to spin up an instance of the JVM. This start up time can be mitigated by using the Gradle Demon. A Gradle Demon is just a process that hangs around in the background of your OS, doing something useful. When Gradle’s instructed to use a demon, a demon process has started and continuously runs in the background. By default, Android Studio always uses this Gradle Demon.

Apache Groovy.

Gradle Scripts are written in a special purpose build language provided by Gradle. But it’s not a language that is developed from scratch. It sits on top of a generic scripting language called Groovy. It has a lot of syntactic sugar that look a lot more like natural language when compared to using something like Java. Groovy integrates perfectly with Java which is the language that Gradle platform is written in. The main thing we need to learn when using Gradle is the Gradle Build Language which is where the keywords like Android are coming from. The entire build script has what we call a delegate object, which exposes the Gradle Build Language to Groovy Scripting Language within the build script. The Gradle Build Language is also called The Gradle DSL (Domain Specific Language : that is finely tailored for a specific task, in this case the domain we are talking about is an Android Build).

As our builds become increasingly more complex, we want to ensure that we don’t redo any work that has already been done the last time we executed our build. This is especially important during development, when we run our builds often many times a day with some minor changes. It will be a huge impediment to the development process if our builds had to start from scratch every time. We call the idea of only doing the minimum amount of work necessary Incremental Builds.

So, don’t redo any work that has already been done the last time we executed our build. How can we do this!

Let’s consider an Android Application. Building our application requires compiling our code, generating source files and packaging static resources into the final APK. If we are going to change one of our layout files, we don’t have to compile our code again. Gradle accomplished this by tracking each tasks’ inputs and outputs. Before each task is run, Gradle saves a snapshot of the inputs used by the task. If that particular task doesn’t have any snapshots of its input yet, or if the inputs have changed, the Gradle will run the task again.

When Gradle’s invoked with a name of a task to perform, it can’t go ahead and execute that task. It first has to figure out that task dependency and those task dependencies and so on. There are actually three phases to the lifecycle of any Gradle build :

  • Initialization : is mostly concerned with setting up multi-projects builds.
  • Configuration : the build script is executing which configures all the project’s tasks since here Gradle determines which tasks need to be run, and in which order.
  • Execution : all the task actions of all the tasks that are chosen are executed in the proper order.

Android Studio is an incredibly powerful piece of software. But the one it doesn’t have is an integrated build system. Android Studio delegates the entire build process to Gradle. That’s everything that happens to turn your sources and resources into an APK that you can install in your device. Gradle itself doesn’t inherently know anything about Android. That capability is provided by Google in the form of an Android Gradle Plugin.

The next blog we will talk about Gradle Structure and Tasks in Android Studio.