Android Build Systems -Part 2

Let’s get our hands dirty by learning Gradle with some examples.

1. Setup Android Studio and Create an EmptyActivity(say, HelloWorld)
2. Folder structure will look like this

Noticeable things would be here is two different build.gradle files

Project-level Gradle file:

File name: build.gradle (located in the project’s root directory). This Gradle file defines the configuration for the entire Android project. Common configurations in the project-level Gradle file include build-script dependencies, repositories, and global settings.

For example, you might define the Gradle and Android Gradle Plugin versions, repositories for fetching dependencies, and build-script dependencies required for the project-wide build tasks.

App-level Gradle file:

File name: build.gradle (located in the app module directory). This Gradle file is specific to the application module within the Android project. It includes configurations and dependencies specific to the app module, such as its application ID, versioning, dependencies, and build types.

For example, you might specify the dependencies required for the app, configure the build types (e.g., release, debug), and define custom product flavours.

A build folder will be auto generated as whenever a build will take place.

The build folder in an Android project contains the output generated during the build process. It is automatically generated when you build your Android project using Gradle.

Inside the build folder, you will typically find the following subdirectories:

outputs: This directory contains the final build artifacts, such as the APK files and other outputs generated by the build process. The APK files are usually located under the outputs/apk or outputs/apk/debug (or similar) subdirectories.

intermediates: This directory contains intermediate files generated during the build process. It includes compiled Java bytecode, merged resources, processed assets, and other intermediate outputs.

generated: This directory contains generated code and resources. It includes files generated by annotation processors, data binding classes, and other code generation tasks.

reports: This directory contains build reports and logs. It includes reports on lint checks, test results, and other build-related information.

libs: This directory contains libraries and dependencies used in the build process. It may include external libraries or dependencies that are packaged with your project.

The specific contents of the build folder may vary depending on your project's configuration and the build tasks you execute.

3. Building the android application using terminal:

./gradlew build -

When you run ./gradlew build, gradlew or gradlew.bat)is executed, and it performs the following steps:

1. Gradle Version Check: The Gradle Wrapper checks if the required Gradle version specified in the project’s Gradle configuration matches the version it has bundled. If the versions don’t match, it downloads the specified Gradle version.
2. Project Initialisation: The Gradle Wrapper initialises the build environment by setting up the necessary directories and configurations for the project.
3. Dependency Resolution: Gradle resolves and downloads the project’s dependencies from the specified repositories. It checks the both the build.gradle files to determine the required dependencies.
4. Compilation: Gradle compiles the project’s source code. It applies any specified build types and applies the configured compilation options.
5. Resource Processing: Gradle processes and merges the project’s resources. It applies any resource transformations in the project’s configuration.
6. Packaging: Gradle packages the compiled code, resources, and assets into the final output format, typically an APK/Bundle.
7. Testing: If the project includes automated tests, Gradle executes the tests to ensure the code behaves correctly. Test results and reports are generated as part of the build process.
8. Build Output: Once the build is complete, Gradle generates the build output, including the APK file, lint reports, test reports, and other build-related artifacts. The output is typically placed in the project’s build directory.

./gradlew clean -

When you run ./gradlew clean, the Gradle Wrapper script executes the following steps:

1. Build Output Cleanup: The Gradle Wrapper deletes the contents of the build directory within the project. This includes deleting the compiled bytecode, processed resources, generated code, test reports, and other build-related artifacts.
2. Dependency Cache Cleanup: By default, the clean task only deletes the project-specific build outputs. However, you can configure it to also clean the local dependency cache by adding the --refresh-dependencies option. This option deletes cached dependencies, forcing Gradle to re-download them during the next build.

The purpose of running ./gradlew clean is to ensure a clean build environment by removing any previously generated build outputs. This can be useful when you want to start a fresh build or if you're experiencing issues related to stale or conflicting build artifacts.

./gradlew assembleDebug —

When you run ./gradlew assembleDebug, the Gradle Wrapper executes a series of tasks to build the debug variant of your Android application. Here's an overview of what happens during the execution:

1. Follows the same step as it was during .\gradlew build
2. Packaging: Gradle packages the compiled code, resources, and assets into the final output format, typically an APK (Android application package) file. For the assembleDebug task, the output APK file is configured to be signed with a debug key.
3. Build Output: Once the build is complete, Gradle generates the build output, including the APK file for the debug variant. The output is typically placed in the app/build/outputs/apk/debug directory of your project.

During the execution of ./gradlew assembleDebug, you may see logs and progress messages in the terminal indicating the different tasks being executed and their status. Once the build process is finished, you can find the generated APK file in the specified output directory.
It can be done same for release and other build flavours as well.

./gradlew installDebug —

When you run ./gradlew installDebug, the Gradle Wrapper executes a series of tasks to build the debug variant of your Android application. Here's an overview of what happens during the execution:

1. Follows the same step as it was during .\gradlew build
2. Packaging: Gradle packages the compiled code, resources, and assets into the final output format, typically an APK file. For the installDebug task, the output APK file is configured to be signed with a debug key.
3. Device Installation: Once the APK file is generated, Gradle uses the Android Debug Bridge (ADB) to install the APK on a connected device or emulator. It sends the APK file to the device/emulator and installs it, making the application ready for execution.

During the execution of ./gradlew installDebug, you may see logs and progress messages in the terminal indicating the different tasks being executed and their status. Once the installation is complete, you can find and launch the application on the connected device or emulator.
It can be done same for release and other build flavours as well.

./gradlew dependencies -

The ./gradlew dependencies command provides a hierarchical view of the dependencies in an Android project. It shows the relationships between libraries and their versions, aiding in identifying conflicts or duplications. It helps manage dependencies and ensures a stable and efficient configuration for the application.

./gradlew tasks -

The ./gradlew tasks command displays a list of available tasks in your Android project. When executed, Gradle provides a comprehensive overview of the tasks that can be executed, including both the default tasks provided by the Android Gradle Plugin and any custom tasks defined in your project.

The output includes the task names, descriptions, and the group they belong to, making it easier to understand the purpose and functionality of each task. This information is useful for discovering and executing specific tasks, such as building, testing, generating documentation, or performing custom operations. The ./gradlew tasks command helps developers navigate the project's build configuration and provides insights into the available Gradle tasks, enabling efficient project management and automation.

4. Building the android application using Android Studio:

Gradle does provide a extensive set of commands for developers to do multiple tasks. Sometimes it does get a bit tedious to handle and remember multiple set of commands. Android Studio makes it easy by providing a run option and gradle panel on the left side which contains set of tasks that has to be performed.

Clicking on any tasks performs the same functionality as that of command in the terminal.

Android Build Systems is an extensive and vast subject that has to be understand. Keep on checking other articles available online for in-depth understanding of it…