Welcome to the final part of this review of the Pluralsight course Exploring Android Studio by Larry Schiefer.

Larry Schiefer is the CTO and co-founder of HiQES, a mobile, embedded, and application development service company. Larry has over 16 years of experience leading teams, and designing and developing high performance and robust software, and is a Google GDE.

Android Gradle Plugin

Overview

In this module we look at how Android leverages Gradle via the Android Gradle plugin.

This plugin allows us to build our Java code, NDK code, AIDL, RenderScript and XML files. We start by looking at the domain specific language, its powerful capabilities and it’s relationship with building components.

Some of the more advanced features it supports are NDK integration, RenderScript support, and product flavors. We’ll be looking at those too.

Android Basic DSL

The Android Gradle plugin is derived from the Gradle Java plugin, and takes the source sets even further, with specific locations for AIDL, RenderScript, Android resources and JNI files:

• AIDL files in src/main.aidl
• RenderScript files in src/main/rs
• Resources (layouts, drawables, etc.) in src/main/res
• NDK/JNI files in src/main/jni

We look at the main build.gradle file in the ServiceInfoViewer project again. The first line is:

apply plugin: 'android'

Larry says this is the main thing to apply for getting the system to build our app, although there are additional configuration options to set in the DSL, such as:

• defaultConfig
• signingConfigs
• buildTypes

These are all described and explained in this lesson.

signingConfigs gives us the ability to setup the necessary key store and file for signing our packages. In this closure we have the following configs:

• keyAlias
• storeFile
• keyPassword
• storePassword

As for Build Types, the Android plugin creates both the release and debug types by default, and it automatically creates an assemble task for each of them.

Some details are what we normally put into our AndroidManifest file. Gradle can take these values and place them into the manifest at build time. This allows us to do advanced things such as dynamic release versions based on a Groovy function.

We also take another look at the build.gradle file in util_lib and the main difference is it applies the ‘android:library’ rather than the ‘android’ plugin.

The util_lib module is built into a library and the build produces an AAR file rather than an APK file. Larry says an AAR file is like a JAR file with additional content such as resources.

Advanced Android DSL

We can define the name of our package using applicationId, previously handled via the Android manifest.

As we can do in Eclipse, the Android Gradle plugin allows us to build NDK-based applications.

We can define different “flavors”.

Larry talks about NDK builds and adding the NDK location to local.properties.

UI Integration

As well as calling gradle from the command line, Android Studio includes other UI integrations:

• Gradle Console
• Gradle tasks for the projects/modules
• Synchronize between Android Studio project and Gradle files
• Sign configs, product flavors, build types and dependencies

Once again Larry demonstrates using the ServiceInfoViewer project, beginning with the Gradle Console.

This is found in the bottom right hand corner of the screen and shows the latest Gradle output. We see this in action by doing a rebuild.

Next we see the Gradle pane, and this is found in the top right hand corner of the screen. This shows recent tasks that have been run. We can rerun tasks or even create new ones here.

Larry speculates that in the future there will be support for Gradle offline mode.