Gradle plugin to build android applications

Using Gradle Plugins

Gradle at its core intentionally provides very little for real world automation. All of the useful features, like the ability to compile Java code, are added by plugins. Plugins add new tasks (e.g. JavaCompile), domain objects (e.g. SourceSet), conventions (e.g. Java source is located at src/main/java ) as well as extending core objects and objects from other plugins.

In this chapter we discuss how to use plugins and the terminology and concepts surrounding plugins.

What plugins do

Applying a plugin to a project allows the plugin to extend the project’s capabilities. It can do things such as:

Extend the Gradle model (e.g. add new DSL elements that can be configured)

Configure the project according to conventions (e.g. add new tasks or configure sensible defaults)

Apply specific configuration (e.g. add organizational repositories or enforce standards)

By applying plugins, rather than adding logic to the project build script, we can reap a number of benefits. Applying plugins:

Promotes reuse and reduces the overhead of maintaining similar logic across multiple projects

Allows a higher degree of modularization, enhancing comprehensibility and organization

Encapsulates imperative logic and allows build scripts to be as declarative as possible

Types of plugins

There are two general types of plugins in Gradle, binary plugins and script plugins. Binary plugins are written either programmatically by implementing Plugin interface or declaratively using one of Gradle’s DSL languages. Binary plugins can reside within a build script, within the project hierarchy or externally in a plugin jar. Script plugins are additional build scripts that further configure the build and usually implement a declarative approach to manipulating the build. They are typically used within a build although they can be externalized and accessed from a remote location.

A plugin often starts out as a script plugin (because they are easy to write) and then, as the code becomes more valuable, it’s migrated to a binary plugin that can be easily tested and shared between multiple projects or organizations.

Using plugins

To use the build logic encapsulated in a plugin, Gradle needs to perform two steps. First, it needs to resolve the plugin, and then it needs to apply the plugin to the target, usually a Project.

Resolving a plugin means finding the correct version of the jar which contains a given plugin and adding it to the script classpath. Once a plugin is resolved, its API can be used in a build script. Script plugins are self-resolving in that they are resolved from the specific file path or URL provided when applying them. Core binary plugins provided as part of the Gradle distribution are automatically resolved.

Applying a plugin means actually executing the plugin’s Plugin.apply(T) on the Project you want to enhance with the plugin. Applying plugins is idempotent. That is, you can safely apply any plugin multiple times without side effects.

The most common use case for using a plugin is to both resolve the plugin and apply it to the current project. Since this is such a common use case, it’s recommended that build authors use the plugins DSL to both resolve and apply plugins in one step.

Binary plugins

You apply plugins by their plugin id, which is a globally unique identifier, or name, for plugins. Core Gradle plugins are special in that they provide short names, such as ‘java’ for the core JavaPlugin. All other binary plugins must use the fully qualified form of the plugin id (e.g. com.github.foo.bar ), although some legacy plugins may still utilize a short, unqualified form. Where you put the plugin id depends on whether you are using the plugins DSL or the buildscript block.

Locations of binary plugins

A plugin is simply any class that implements the Plugin interface. Gradle provides the core plugins (e.g. JavaPlugin ) as part of its distribution which means they are automatically resolved. However, non-core binary plugins need to be resolved before they can be applied. This can be achieved in a number of ways:

Including the plugin from the plugin portal or a custom repository using the plugins DSL (see Applying plugins using the plugins DSL).

Including the plugin from an external jar defined as a buildscript dependency (see Applying plugins using the buildscript block).

Defining the plugin as a source file under the buildSrc directory in the project (see Using buildSrc to extract functional logic).

Defining the plugin as an inline class declaration inside a build script.

For more on defining your own plugins, see Custom Plugins.

Applying plugins with the plugins DSL

The plugins DSL provides a succinct and convenient way to declare plugin dependencies. It works with the Gradle plugin portal to provide easy access to both core and community plugins. The plugins DSL block configures an instance of PluginDependenciesSpec.

To apply a core plugin, the short name can be used:

Источник

The Application Plugin

The Application plugin facilitates creating an executable JVM application. It makes it easy to start the application locally during development, and to package the application as a TAR and/or ZIP including operating system specific start scripts.

Applying the Application plugin also implicitly applies the Java plugin. The main source set is effectively the “application”.

Applying the Application plugin also implicitly applies the Distribution plugin. A main distribution is created that packages up the application, including code dependencies and generated start scripts.

Building JVM applications

To use the application plugin, include the following in your build script:

The only mandatory configuration for the plugin is the specification of the main class (i.e. entry point) of the application.

You can run the application by executing the run task (type: JavaExec). This will compile the main source set, and launch a new JVM with its classes (along with all runtime dependencies) as the classpath and using the specified main class. You can launch the application in debug mode with gradle run —debug-jvm (see JavaExec.setDebug(boolean)).

Since Gradle 4.9, the command line arguments can be passed with —args . For example, if you want to launch the application with command line arguments foo —bar , you can use gradle run —args=»foo —bar» (see JavaExec.setArgsString(java.lang.String).

If your application requires a specific set of JVM settings or system properties, you can configure the applicationDefaultJvmArgs property. These JVM arguments are applied to the run task and also considered in the generated start scripts of your distribution.

If your application’s start scripts should be in a different directory than bin , you can configure the executableDir property.

Building applications using the Java Module System

Gradle supports the building of Java Modules as described in the corresponding section of the Java Library plugin documentation. Java modules can also be runnable and you can use the application plugin to run and package such a modular application. For this, you need to do two things in addition to what you do for a non-modular application.

First, you need to add a module-info.java file to describe your application module. Please refer to the Java Library plugin documentation for more details on this topic.

Second, you need to tell Gradle the name of the module you want to run in addition to the main class name like this:

That’s all. If you run your application, by executing the run task or through a generated start script, it will run as module and respect module boundaries at runtime. For example, reflective access to an internal package from another module can fail.

The configured main class is also baked into the module-info.class file of your application Jar. If you run the modular application directly using the java command, it is then sufficient to provide the module name.

You can also look at a ready made example that includes a modular application as part of a multi-project.

Building a distribution

A distribution of the application can be created, by way of the Distribution plugin (which is automatically applied). A main distribution is created with the following content:

Table 1. Distribution content

All runtime dependencies and main source set class files.

Start scripts (generated by startScripts task).

Static files to be added to the distribution can be simply added to src/dist . More advanced customization can be done by configuring the CopySpec exposed by the main distribution.

By specifying that the distribution should include the task’s output files (see more about tasks), Gradle knows that the task that produces the files must be invoked before the distribution can be assembled and will take care of this for you.

You can run gradle installDist to create an image of the application in build/install/projectName . You can run gradle distZip to create a ZIP containing the distribution, gradle distTar to create an application TAR or gradle assemble to build both.

Customizing start script generation

The application plugin can generate Unix (suitable for Linux, macOS etc.) and Windows start scripts out of the box. The start scripts launch a JVM with the specified settings defined as part of the original build and runtime environment (e.g. JAVA_OPTS env var). The default script templates are based on the same scripts used to launch Gradle itself, that ship as part of a Gradle distribution.

The start scripts are completely customizable. Please refer to the documentation of CreateStartScripts for more details and customization examples.

Tasks

The Application plugin adds the following tasks to the project.

Depends on: classes

Starts the application.

Creates OS specific scripts to run the project as a JVM application.

Depends on: jar , startScripts

Installs the application into a specified directory.

Depends on: jar , startScripts

Creates a full distribution ZIP archive including runtime libraries and OS specific scripts.

Depends on: jar , startScripts

Creates a full distribution TAR archive including runtime libraries and OS specific scripts.

Application extension

The Application Plugin adds an extension to the project, which you can use to configure its behavior. See the JavaApplication DSL documentation for more information on the properties available on the extension.

You can configure the extension via the application <> block shown earlier, for example using the following in your build script:

Источник

Gradle plugin to build android applications

We are very sorry to announce that development of this plugin has been discontinued. Google has created their own Android development toolchain based on Gradle, which supercedes this plugin.

This is the Android plugin for the Gradle build system. This plugin enables the creation of Android applications using Gradle, with all of the power and flexibility you’ve come to expect from Gradle.

Currently, Gradle 1.0-rc-3 is required.

For mailing lists see the project page on Google Code: https://code.google.com/p/gradle-android-plugin/

Features of the Android plugin include:

• Compile, package, and install Android applications. (Including handling of Android resource files.)
• Sign application packages using the default debug key, or with a release key for publication to Android Market.
• Incorporation of ProGuard to ensure that applications have minimal memory footprint.
• Easily create Android applications in Scala (and possibly Groovy or Clojure).

The Android plugin fully integrates into the Gradle build lifecycle by extending the Java plugin. Furthermore, the incorporation of ProGuard into the build not only ensures that Android application packages are small and tight, it also trivially enables the use of Scala for Android application development simply by incorporating the existing Scala plugin into the build. ProGuard will include only those classes from the Scala library that are actually used by your Android application, resulting in an application package that is as small as possible.

TASKS AND LIFECYCLE

The Android plugin adds the following tasks and dependencies to the build:

To use the Android plugin for Gradle you must first create the application skeleton using the android command-line tool. For example:

This will create and Android application skeleton that you can immediately build using Ant. To build with Gradle instead, you must (1) create a build.gradle file that includes the Android plugin, and (2) either move the source code to the directory expected by Gradle, or tell Gradle to use the src directory of your project directly.

Create a build.gradle file in the root directory of the project, and include the Android plugin as follows:

The android create project command created the source code directly in the src directory of the project. The Android plugin tries to conform to the conventions established by Android’s Ant-based build, but in this case it is better to conform to Gradle’s «source sets» convention, since it allows you to have separate test source code, or to use multiple languages. Therefore, we recommend that the source should be moved to src/main/java instead. Once you’ve done this you can, of course, utilize Gradle’s source sets to their full extent by placing resources in src/main/resources, Scala source files in src/main/scala etc. However, if you prefer to keep your source code directly in the src directory (for example, if you need to retain compatibility with Ant) then you can do so by configuring the Java source set in your build.gradle file. Just add the following to build.gradle:

If your Android project was initially created by Eclipse rather than the android create project command, then you will have some additional setup work to do. The Android plugin for Gradle must be told the location of the Android SDK. When you create a project with the android create project command, the location is filled in for you by the application generator, but the Eclipse project generator does not provide this information to the project. Therefore, you must fill it in yourself. To do this, create (or edit) the local.properties file in the root of the project and add the sdk.dir property, referring to the location of your Android SDK installation:

Note that this file should not be checked in to your version control system as it will likely differ across various development environments. Alternatively, you can use the ANDROID_HOME environment variable instead.

Once you’ve performed these steps you can build your Android application by invoking the tasks described above.

A complete minimal but real-world example is as follows.

This build script configures the build to sign with a provided keystore. This configuration applies for every build (1). It also sets Gradle to expand properties in every resource file (2).

In this way you can get a full build with the command:

It processes all the resources, expanding them with properties from the project’s scope, compiles classes, packs them into the dex file, builds the apk, signs it with the provided keystore (but does not process it with proguard) and zipaligns the package, which is named -x.y.z.apk and placed in /build/distributions. You can see the proguard task is skipped from Gradle’s output during the build.

You can create several build configurations and choose which one to execute from the gradle command line. The task configureDebug (3) defines the Gradle classifier for the package name. Executing this build with the command:

creates a package with same steps than the default build, but the package name is project-x.y.z-debug.apk.

The task configureRelease (4) defines a release configuration task, which activate the proguard step. Again, you get the package named -x.y.z.apk in the same output directory.

To disable signing and get a signed apk with the debug key, you can remove the androidPackage configuration (1): if keyStore or keyAlias are null, the signing is skipped and the debug key is used. Of course, you can put the signing configuration in a dedicated configuration task and invoke that task in order to get a signed package (or not to call it for the debug signed package).

Also note that if you don’t supply password (that is, keyStorePassword or keyAliasPassword are null), Gradle asks for them on the command line (not very good for CI servers. ).

To install the generated apk onto a running emulator or a device connected with USB (and configured in debug mode), run:

This installs the default built package; as with previous examples, if you want to install the debug (or release) package, you have to issue:

The androidUninstall task unistalls the application from a running emulator or a device. There is no need to specify which package: there can be only one package to undeploy and it’s defined by the base package name of the application, from androidManifest.xml.

You can use Gradle to generate an Eclipse project for you. The Android plugin enhances this process by setting up the Eclipse project correctly for Android, which includes establishing the correct class path and inserting the Android builders into the build process.

To use the Eclipse integration, first make sure that you apply the Gradle Eclipse plugin in your build.gradle file:

Then you can generate the Eclipse project files as follows:

The plugin is able to run instrumentation tests for you on a connected device or emulator:

On projects that do not define any instrumentations in their manifest, this task will safely be skipped. By default, the task runs all tests in the given project, using Android’s default test runner. If you want more control, you can add a configure closure to your test project:

The ‘run’ method can you be used in different ways. If used as above, all tests will be run using the given test runner. The ‘options’ field can be used to route parameters to the Activity manager that’s used to run the instrumentation (cf. ‘adb shell am instrument’). Note that you don’t have to supply the «-w» parameter, that’s done by default.

You can also partition your test suite to run with different runners. Note that this only works if you don’t also have a more general runner configured as seen above. Currently, the plugin allows you to partition by test package and annotation:

Источник

Location	Content