Android contains a build automation system called Gradle. This system is responsible for build, test, run and package the application. This definition is widespread. What is not so widespread, it is the following idea: do you want to be a good Android developer? If yes, so you must to study a lot of Gradle.
Why? For example, how to configure the Gradle to generate, to the final of a build process, a .apk file with its name in the following format: vX.Y.QA.Z (where X, Y, Z are numerals and QA shows that file is addressed to the Quality Assurance Team)? A good Android developer knows the answer.
However, every study on a particular topic must to begin from some point. Therefore, this post has as focus to explain the basic blocks that makes up Gradle build files of a Android project.
An Android project, by default, contains three Gradle files: one setting file, one project-level file and one module-level file. They are shown below:
This file is executed during the build boot phase. It defines what modules will be included in the build process:
In the case of this project, just the application module called “app” is included. But, in case of the project were composed of more than one module (for example, a module of application and three library modules), the setting file would contain the following code:
include ‘:app’, ‘library1’, ‘library2’, library3'
Thus, all these modules were in the build process.
This file contains settings that will be applied in all the project modules:
The buildscript block is the place where the build properties are configured. This block is made of sub-blocks. The block repositories points what is the repository which Gradle can fetch referencies to be used in the project. In this example, it is used jcenter() (that is a Maven repository). By other side, the dependencies block is responsible by configure dependencies to the own build process. On the picture above, it is defined, by default, the reference to the Android plugin for Gradle.
Finally, the allprojects block contains properties that can to be used in all other modules of the project.
This file contains settings that are just applied to the application module (app):
The command apply plugin applied the Android plugin for Gradle, so that Gradle runs necessary tasks for the build of an Android application.
The android block contains specific setting for Android. The compileSdkVersion property determines what API version is used for compile the application. And the buildToolsVersion states the tools version of build used in the process.
The defaultConfig property contains prime settings to the application. These settings can also be defined in the AndroidManifest.xml file.
The applicationId property deserves prominence, because it has influence in all the application lifecycle, since its coding, automated testing handling, until its publication in the Google Play. Exists the app package name concept, contained in the manifest file, as shown below:
The application package name, as described above, is:
And the applicationId is:
That is, are equals. Equal in this project. But cannot be in other project. The package name described in the manifest file is used as the name of the class package Resource R. And the applicationId is the unique identifier of the application interpreted by devices and for Google Play. This property will be useful when were used build variants (concept that in a future post), which can, for example, to generate different versions of a same application, but one free and the other paid.
The property minSdkVersion describes the mininum version of necessary API to run the app. The property targetSdkVersion is the API version that is used to build the application. The versionCode is the internal version of application, which will be interpreted by device that runs the app. And the versionName describes the version name of application of the way to the shown to the user. For example, the version name of the Facebook Android app is shown below:
The buildTypes block contains settings that define as build and package the application. In case of this project, the release build type is explicitly defined. But, by default, the build type debug is implicitly defined.
Lastly, the dependencies block contains all the dependencies used for an app. In this project are included dependencies for all the existing JAR files in the libs folder, for the JUnit and AppCompat libraries.
Basic concepts were explained about build Gradle files for Android. All people that develop for that platform must know these concepts, because they serve like pillars to more advanced concepts, such as build variants, product flavors, multiflavors variants, variant filters, reuse of build configuration and also about how to generate apk files with a custom name, concepts these that I will show in future posts.