The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
build.gradle file teaches Gradle how to execute tasks, such as how
to compile an Android project. Outside of a Gradle-aware IDE like Android
Studio, you use Gradle itself to run these tasks. If you have installed your
own copy of Gradle, you would use the
gradle command; if you are relying
upon a trusted copy of the Gradle Wrapper, you would use the
script in your project root.
For the purposes of this book, the
gradle command will be shown –
./gradlew where you see
gradle if you are using
the Gradle Wrapper script.
To find out what tasks are available to you, you can run
gradle tasks from
the project directory. That will result in output akin to:
:tasks ------------------------------------------------------------ All tasks runnable from root project ------------------------------------------------------------ Android tasks ------------- androidDependencies - Displays the Android dependencies of the project signingReport - Displays the signing info for each variant Build tasks ----------- assemble - Assembles all variants of all applications and secondary packages. assembleDebug - Assembles all Debug builds assembleDebugTest - Assembles the Test build for the Debug build assembleRelease - Assembles all Release builds build - Assembles and tests this project. buildDependents - Assembles and tests this project and all projects that depend on it. buildNeeded - Assembles and tests this project and all projects it depends on. clean - Deletes the build directory. Build Setup tasks ----------------- init - Initializes a new Gradle build. [incubating] wrapper - Generates Gradle wrapper files. [incubating] Help tasks ---------- components - Displays the components produced by root project 'Decktastic'. [incubating] dependencies - Displays all dependencies declared in root project 'Decktastic'. dependencyInsight - Displays the insight into a specific dependency in root project 'Decktastic'. help - Displays a help message. projects - Displays the sub-projects of root project 'Decktastic'. properties - Displays the properties of root project 'Decktastic'. tasks - Displays the tasks runnable from root project 'Decktastic'. Install tasks ------------- installDebug - Installs the Debug build installDebugTest - Installs the Test build for the Debug build uninstallAll - Uninstall all applications. uninstallDebug - Uninstalls the Debug build uninstallDebugTest - Uninstalls the Test build for the Debug build uninstallRelease - Uninstalls the Release build Verification tasks ------------------ check - Runs all checks. connectedAndroidTest - Installs and runs the tests for Build 'debug' on connected devices. connectedCheck - Runs all device checks on currently connected devices. deviceCheck - Runs all device checks using Device Providers and Test Servers. lint - Runs lint on all variants. lintDebug - Runs lint on the Debug build lintRelease - Runs lint on the Release build Other tasks ----------- compileDebugSources compileDebugTestSources compileReleaseSources Rules ----- Pattern: clean<TaskName>: Cleans the output files of a task. Pattern: build<ConfigurationName>: Assembles the artifacts of a configuration. Pattern: upload<ConfigurationName>: Assembles and uploads the artifacts belonging to a configuration. To see all tasks and more detail, run with --all. BUILD SUCCESSFUL Total time: 9.669 secs
This list is dynamically generated based on the contents of
notably including tasks defined by the
In principle, you are supposed to specify the entire task name when running that task. However, you can use shorthand, so long as it uniquely identifies the task.
Probably the most common task that a developer will use, at least in the short
iD for short). This will build a debug version
of the app and install it on an available device or emulator. This roughly
ant install debug for those familiar with legacy
Ant-based command-line builds.
Just as there is
installDebug, there can also be
Release portions of the task are not hard-coded, but rather are derived
from the “build types” defined in the
build.gradle file. The concept, role,
and usage of build types will be covered in the next chapter.
installRelease is not available by default, because installing an app requires
that the APK be signed, and Gradle for Android does not know how to sign it.
We will address this in the next chapter as well.
If you just want to build the app, without installing it,
aR) will accomplish that aim. If you want to uninstall
the app from a device or emulator,
uR) should work.
Discussion of other tasks, such as the “check” tasks, will be covered in later chapters.
All build output goes into a
Specifically, your APKs will go into
build/outputs/apk, with different APK editions
based upon whether you did a debug or release build.
Note that Gradle has a
clean task that wipes out the