Gradle For Android Developers

As developers, we spend most of our time writing clean, memory-efficient code, but the end-user only sees the final application build that is installed on the device. So, how come our code and XML files are used to generate a build? Gradle in Android Studio allows for this. So, instead of the usual coding standards, we discuss as developers, let’s learn about Gradle in this article for a change! In this article, we will learn:

1. What exactly is Gradle?
2. What is Gradle’s role in Android development?
3. Gradle for Android is a Gradle plugin for Android.
4. What exactly are Gradle Plugins?
5. Why is there more than one build.gradle file in an Android project?
6. What do the various fields in the project-level build.gradle file mean?
7. What exactly is a Gradle task? How do I make my own Gradle Task?
8. How can we use the command line to build Gradle?

The gradle build running

Gradle

Gradle is an open-source build automation tool that focuses on flexibility and performance. So, to put it simply, it is an automation tool that creates the application build. Gradle is Android’s official build tool.

Gradle’s Function in Android Development

We can see the process of “Gradle Build Running” in our IDEs whenever we try to run the developed code into an emulator or an actual device via USB.

Gradle Plugin for Android

Neither Android Studio nor Gradle knows how to compile the Java and Kotlin code into an APK. Yes, that’s right! So, how can Gradle assist us in the building process? 

GeekTip: The Android plugin for Gradle interacts with the build toolkit to provide processes and configurable settings for building and testing Android applications.

Plugins for Gradle

Gradle cannot automate much of the build process on its own. That is why, if we return to our section where we discussed Gradle’s definition, it is focused on “Flexibility.” As Android Developers, we should remember that third-party libraries that must be used in our project should be added as dependencies in our app-level Gradle file, and we can only access their classes after syncing the Gradle with the project. Gradle’s flexibility is achieved by including a “Plug-in” feature. You can browse all of the Gradle plugins that are available for download.

An Android project may contain multiple build.gradle files

When we start a new Android project, we see two different build.gradle files. One is at the project level, while the other is at the app level. So, what exactly is the “app” here? The term “app” refers to a project module. What exactly is a module? According to the documentation for Android Developers. A module is a set of source files and build settings that allow you to divide your project into discrete functional units. Your project may contain one or more modules, and one module may rely on another module. Each module can be built, tested, and debugged independently.

The project level gradle file

We should understand three fields (areas) from the project level build.gradle file:

1. The repositories from which the project’s dependencies will be downloaded (google and jcenter in this case)
2. The dependencies that must be met at the project level (useful for all the sub-projects or modules). We can see that the Gradle and Kotlin dependencies are used throughout the project, so they are declared here (at the project level).
3. The repositories from which all sub-projects/modules should be downloaded (google and jcenter in this case)

Understanding the gradle structure on board

1. We include the necessary plugins, such as the Android Gradle plugin and the Kotlin plugins.
2. This is the android block, which contains a list of all the requirements. This is only possible because we used the Android Gradle plugin in Step 1.
3. The various build types must be included in accordance with the requirements. More information on build types can be found here.
4. Finally, all third-party dependencies required for this module or sub-project are listed.

What happens when the build process in Android Studio begins?

Now that we understand why we have different build.gradle files and what the different fields in the Gradle file mean, let’s look at what happens when we click the run button.

In some simpler terms:

1. Compilers transform your source code into DEX (Dalvik Executable) files, which contain the bytecode that runs on Android devices, and everything else into compiled resources.
2. The DEX files and compiled resources are combined into a single APK by the APK Packager. The APK must be signed before it can be installed and deployed on an Android device.
3. The APK Packager uses either the debug or release Keystore to sign your APK.
4. If you are creating a debug version of your app, that is, an app that will only be used for testing and profiling, the packager will sign it with the debug Keystore. Android Studio creates a debug Keystore for new projects by default.
5. If you are creating a release version of your app for external distribution, the packager signs it with the release Keystore.
6. Read about signing your app in Android Studio to create a release Keystore.
7. Before generating your final APK, the packager optimizes your app to use less memory when running on a device with the zipalign tool.
8. You will have either a debug APK or a release APK of your app at the end of the build process, which you can use to deploy, test, or release to external users.

Gradle Process

Gradle Task is an action that Gradle performs. When you press the run button in Android Studio, for example, a Gradle task is launched.

The gradle tasks

If we keep the build window open from the bottom navigation bar and click on the run icon, we can see a list of Gradle tasks on the console.

Using the command line to run Gradle tasks

Can we replicate the behavior described in the Gradle tasks section using the command line? Yes, we can use the bottom navigation bar to open the terminal and type:

./gradlew assembleDebug --console plain

We can see that these are the same tasks that we saw when we clicked the run button in Android Studio. As a result, the task triggered by clicking the run button here is “assembleDebug.” Here’s a description of the command we used;

./gradlew tasks

Instructs the Gradle Wrapper to be used. It is strongly advised to always use the Wrapper version. More information about the Gradle Wrapper can be found here assemble. The task we just asked it to run is called debug.

—console simply instructs Gradle to print the build log exactly as it appears in Android Studio. It is entirely optional to mention this. We can also see that the list of tasks displayed by running the command from the terminal matches the list of tasks available in the Gradle console at the top right corner.

Creating unique tasks

We’ve seen and comprehended how to run the “assembleDebug” task from the command line. What if we want to create our own task: Assume we want to clean up the project by creating a custom task. This task can be added to the project’s build.gradle file:

task clean(type: Delete) {
    delete rootProject.buildDir
}

This runs the clean command, which deletes the build directory according to the command specified in the task declaration. The same result can be obtained by selecting “Clean Project” from the “Build” menu. However, if we wanted to customize our task, this is how we could do it.

Gradle now provides this task as a default in the project-level build.gradle file. Consider one of the most common use cases. Assume that after we build our apk using the assembleDebug process, we want to copy the apk to the Desktop and rename it to something other than ‘app-debug.apk.’ How are we going to do it?

Conclusion

‘getDebugAppInDesktopFolder’ is the name of our task, and ‘assembleDebug’ is the task on which our current Gradle task is dependent. (assembleDebug is the task that generates our ‘app-debug.apk’ file.) Finally, in our doLast block, we get the user name from the System properties so that it can be dynamic, and we copy the apk file to the desktop if it already exists. This saves us from having to locate the ‘app-debug.apk’ file, copy it to our desktop, and then rename it. That’s all! That’s all we wanted to cover in this blog post about Gradle for Android Developers.