Getting started with tasks

To know which tasks are available on a project, you can run gradlew tasks, which prints out a list of all the available tasks. In a newly created Android project, this includes Android tasks, build tasks, build setup tasks, help tasks, install tasks, verification tasks and other tasks. If you want to see not only the tasks, but also their dependencies, you can run gradlew tasks --all. It is possible to do a dry run of tasks, which prints out all the steps that are executed when running a specific task. This dry run will not actually perform any of these steps, so it is a safe way to see what you can expect to happen when running a certain task. You can do a dry run by adding the parameters -m or --dry-run.

Base tasks

The Android plugin for Gradle makes use of the Java base plugin, which in turn makes use of the base plugin. These add the standard lifecycle tasks and some common convention properties. The base plugin defines the tasks assemble and clean, and the Java base plugin defines the tasks check and build. These tasks are not implemented in the base plugin and do not perform any actions; they are used to define a convention for plugins that add the actual tasks that do the work.

The conventions for these tasks are:

• assemble assembles the output(s) of the project
• clean cleans the output of the project
• check runs all the checks, usually unit tests and instrumentation tests
• build runs both assemble and check

The Java base plugin also adds the concept of source sets. The Android plugin builds on these conventions, and thus exposes tasks that experienced Gradle users are used to seeing. On top of those base tasks, the Android plugin also adds a lot of Android-specific tasks.

Android tasks

The Android plugin extends the base tasks and implements their behavior. This is what the tasks do in an Android environment:

• assemble creates an APK for every build type
• clean removes all the build artifacts, such as the APK files
• check performs Lint checks and can abort the build if Lint detects an issue
• build runs both assemble and check

The assemble task depends on assembleDebug and assembleRelease by default, and more tasks if you add more build types. This means running assemble will trigger a build for every build type you have.

Besides extending these tasks, the Android plugin also adds a few new ones. These are the most significant new tasks:

• connectedCheck runs tests on a connected device or emulator
• deviceCheck is a placeholder task for other plugins to run tests on remote devices
• installDebug and installRelease install a specific version to a connected device or emulator
• All install tasks also have uninstall counterparts

The build task depends on check, but not on connectedCheck or deviceCheck. This is to make sure that regular checks do not require a connected device or running emulator. Running the check tasks generates a Lint report with a list of all warnings and errors, with a detailed explanation and a link to the related documentation. This report can be found in app/build/outputs and is called lint-results.html. It looks like this:

When you assemble a release, Lint will check for fatal issues that could cause the app to crash. If it finds any issues, it will abort the build and print the errors to the command-line interface. Lint will also generate a report in app/build/outputs in a file called lint-results-release-fatal.html. If you have multiple issues, going through the HTML report is more pleasant than scrolling back and forth in the command-line interface. The provided links are also extremely useful, because they take you to detailed explanations of the issues.

Inside Android Studio

You do not always have to run Gradle tasks from the command-line interface. Android Studio has a tool window that contains a list of all the available tasks. This tool window is called Gradle and looks like this:

From this tool window, you can run a task simply by double-clicking on its name. You can follow the progress of any running task in the Gradle Console tool window. If you cannot find these tool windows, you can open them in the View menu, under Tool Window. This is what the Gradle Console tool window looks like:

You can also run tasks from a command-line interface inside Android Studio, so you can do all app-related work inside the IDE if you like. To run the command, you need to open the Terminal tool window. This is a full-blown terminal, so it is possible to run any command from it. You might need to navigate to the top level of the project first, in order to work with the Gradle wrapper.

Tip

Changing the Android Studio terminal

It is possible to configure the terminal inside Android Studio to use a different shell. On Microsoft Windows, for example, the terminal defaults to Command Prompt. If you prefer to use the Git Bash (or any other shell) instead, open the Android Studio settings (under File and Settings) and look for Terminal. There you can change the shell path. For Git Bash on Microsoft Windows, it looks like this: C:\Program Files (x86)\Git\bin\sh.exe --login -i.