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.

Writing a Gradle Plugin

Gradle is very extensible, from Groovy scripting code in your build.gradle file all the way up to dedicated Gradle plugins. The more you want to reuse a particular piece of functionality, or the more sophistication you want in your custom builds, the more likely it is that a Gradle plugin will be the right solution.

Sometimes, a Gradle plugin will be focused mostly on tailoring the build process itself. However, a Gradle plugin could be simply an integration point for a tool that could be used in other ways (e.g., command-line API) that would not otherwise require Gradle. This is particularly true for tools that work across IDEs, where you put most of the core logic into a core set of tool code and have thin build system plugins that bridge between the build system or IDE and the tool itself.

In this chapter, we will look at the basics of setting up a Gradle plugin. The plugin that we develop in this chapter will not do much of anything. The next chapter, however, creates a Gradle plugin that generates Java code, building on what we explore here.


This chapter will make the most sense if you have read the preceding chapters on Gradle, particularly the chapter on Gradle tasks.

Customizing a Gradle Build

Gradle is Groovy — in other words, Gradle is a domain specific language (DSL) implemented in the Groovy scripting language. Hence, you are welcome to blend in Groovy code into your build.gradle file, for everything from simple string concatenation to loops, branches, and everything else that you would expect from a modern OO-flavored scripting language.

You are not limited to putting that Groovy code directly in build.gradle either. You can use apply from: to indicate the path to some other Gradle script, reminiscent of a #include from C/C++, <include> elements in an Android layout resource, and so forth:

apply from: 'relative/path/to/some.gradle'

Or, you can create a buildSrc/ directory in your project root. In there, you can have Java code (e.g., in src/main/java/) or Groovy code (e.g., in src/main/groovy/), all of which will be compiled and added to the classpath for your main build.gradle file. As a result, your build.gradle file can refer to whatever classes and such are created in this buildSrc/ quasi-module. This is powerful, but it is inconvenient to distribute, except for other people working on the same overall project (e.g., via version control systems). As such, this approach is mostly for project-specific build system extensions.

A Gradle plugin is a separate module, akin to the buildSrc/ directory, that creates a JAR that incorporates compiled Java and Groovy code. That plugin JAR can then be used by other modules or other projects. The plugin can be distributed through Maven Central, JCenter, or other artifact repositories. And, people can use it just like you use the Android Gradle Plugin: requesting it in a buildscript closure and applying the plugin. This is somewhat more complicated to set up than is a buildSrc/ directory, but it offers the easiest path for distributing substantial build customizations.

Some Use Cases for a Custom Plugin

The preview of this section apparently resembled a Pokémon.

Writing a Plugin

The preview of this section may contain nuts.

Distributing the Plugin

The preview of this section apparently resembled a Pokémon.

Using the Plugin

The preview of this section was whisked away by a shark-infested tornado.

Creating a Real Plugin

The preview of this section apparently resembled a Pokémon.