June 12th, 2016

Build your Android applications in Visual Studio using Gradle

Ankit Asthana
Principal Program Manager

This blog post is going to talk about how you can use Gradle to build Android libraries (.AAR) and APK’s and leverage Maven dependencies all in Visual Studio so let’s get started! If you are new to Gradle, then take a look at the gradle overview page and the User Guide.

Gradle has really been the default build system for Android for quite some time and Android developers have slowly but surely been moving to Gradle. Gradle provides flexibility as well as the ability to define common standards for Android builds. Gradle allows Android developers to use a simple, declarative DSL to configure Gradle builds supporting a wide variety of Android devices and App stores.

With a simple, declarative Domain specific language (DSL), Gradle developers can easily describe and manipulate the build logic (e.g. manifest entries – minSDKVersion, targetSDKVersion etc.), use the built-in dependency management via Maven or Ivy and essentially have access to a single, authoritative build that powers both the Android Studio IDE and builds from the command-line but this ability to use Gradle in Visual Studio has been missing until recently.

Getting Started 
With the latest Visual Studio release, if you take a look at the cross-platform C++ section in the File->New project template section, you will see a variety of templates as shown in the figure below. Notice two new Gradle templates that have been introduced.  
template

‘Basic Android Application (Android, Gradle)’, template as the name suggests will build an E2E android application (.APK) and the ‘Basic Library (Android, Gradle)’ template will build an AAR file also known as an Android artifact. For traditional Java users, AAR’s are similar to Jar files with the main difference being AAR files include resources such as layouts, drawables etc. This makes it a lot easier to create self-contained visual components.  For e.g. if you have multiple apps that use the same login screen, with jar’s you can share classes but not the layout itself. With AAR’s everything is bundled into one package. With that said, let us now take a look at structure of a basic Android application.

Understanding the Gradle artifacts   As you create a new project from template, you will notice the top-level build.gradle file, located in the root project directory, defines build configurations that apply to all modules in your project. By default, the top-level build file uses the buildscript {} block to define the Gradle repositories and dependencies that are common to all modules in the project. The following code sample describes the default settings and DSL elements you can find in the top-level build.gradle.template after creating a new project. template2 For this project, the repositories section declares the jCenter and mavenCentral repositories, and we have also introduced a classpath dependency on a Maven artifact. This artifact is the library that contains the Android plugin for Gradle version specified in the property pages (figure below).

gradle2

The module-level build.gradle.template file, located in the ‘app’ directory will allow you to configure build settings for the specific module it is located in. One thing special about this particular specific build.gradle.template file is the fact that it is based upon the experimental plugin (0.4.0) which allows for significant time reduction in configuration time. In addition to this, this experimental plugin also allows for integration with NDK and CMake build system which is important if your application contains C++ code.

A sample Android app module build.gradle.template file when using the experimental plugin outlines some of the basic DSL elements.

The apply plugin: ‘com.android.model.$(ConfigurationType)’ command specifies the kind of artifact being built. You can either set this to an application for building an .APK or a library for building an .AAR file. This configuration type can be controlled via the property pages ‘Configuration Type’ property .

template3

The plugin name used by the experimental plugin is different than the standard plugin name ‘com.android.application’ for building an Android APK or ‘com.android.library’ in case you are building an Android aar library.

The next section in the module-specific ‘build.gradle.template’ file is the model section. The model section wraps the configuration. The Android closure is the standard way used for wrapping the SDK version used for compiling, minimum SDK version supported and more.

template6

The next section ‘compileOptions’ allows for choosing the language level used by the compiler.

template7

The android.buildTypes section creates a debug and release build type  for this application. Although the debug build type doesn’t appear in the build configuration file; it gets configured when the debuggable property is set to true. This allows for debugging the application on secure Android devices and configures APK signing with a default generic keystore.

template8

The last section in the model enclosure is productFlavors. A product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application. Since this particular build.gradle is tailored for an NDK android application the abiFilters.add allows for building one APK per architecture easily.

template9

The last section in this build.gradle.template file is the dependencies section. There are three kinds of dependencies, and you can find what each kind does here on the Android documentation site. This particular build.gradle.template only defines the compile.filetree dependency as shown below. The ${AarDependencies) is an addition by us which allows easy Visual Studio project referencing.

template10

The compile fileTree(dir: ‘libs’, include: [‘*.jar’]) line tells the build system to include any JAR files inside the app/libs/ directory in the compilation classpath and in the final package of your application.

The other Gradle files that are included as the part of your project is the settings.gradle.template file. This file references all the modules that make up your project.

include ‘:app’ $(AarDependenciesSettings)

Using the NDK integration    Using the NDK integration with Gradle in Visual Studio is easy. Typically you would need to add the ndk {} section in your model section for your module specific build.gradle.template file and potentially also use the android.sources section to provide JNI source set as specified in the android documentation  but  in Visual Studio in order to incorporate a native C/C++ component all you need to do is create a new native component through the Cross-Platform – Android section  and then add it via the typical project reference from the Gradle project as shown below. Visual Studio will automatically take care of packaging your native library in the Android application you are building.

gifref

Alternatively you can also use the standard approach for including JNI sources using the experimental Gradle plugin as well if that works out better for you. Google provides a good list of samples for Android NDK and Gradle in this repository. With minor changes, mainly involving copying over contents from the ‘build.gradle’ -> ‘build.gradle.template’ files , those samples would work for you in Visual Studio. We are currently in the process of making this process happen automatically by providing you folks with an Android Studio -> Visual Studio Android project converter. If this converter really interests you please leave your contact information here or reach out to me.

Referencing Android libraries in your Android project     Generally, Android applications built in Visual Studio mainly use C++. Every now and then even for these C++ heavy applications there can be a need to include Android libraries such as AARs and JARs into your Android application. These could be homegrown Android artifacts built for the purposes of sharing common code, assets and utilities.

With this release of Visual Studio, we have made the process really easy for you to do that as well. In order to create and reference an AAR file you can simply do so by creating a new AAR from the File->New project menu (Basic Library (Android, Gradle)) and then include it in your Android application by adding it through a project reference as shown in the figure below.

androidlibref

An example: Incorporating the Facebook SDK in your Android app Now that we have a basic understanding of how the Gradle build system works, lets now go ahead and show off the real power of the build system. As mentioned earlier, Gradle makes it simple to integrate with external repositories. In order to leverage the Facebook SDK (instructions here) all one has to do is use the compile dependency command in the module specific build.gradle.template file and add the following line (given that we have already specified mavenCentral() and JCenter() repositories in the root build.gradle file).

compile ‘com.facebook.android:facebook-android-sdk:4.7.+’

This command declares a remote binary dependency on the version 4.7 and  above for the Facebook SDK. At build time Gradle will now automatically pull the dependency from the jCenter repository specified in the top-level build.gradle.template file.

This mechanism not only allows you to specify and incorporate the Facebook SDK as a build time artifact but also allows Visual Studio to power the Java language service experience with features like Intellisense extending their functionality for the Facebook SDK set of API(s) as well as shown  in the figure below!

template11

Wrap Up    This summarizes the current support for building Android applications with Gradle for Visual Studio 2015 Update 3. We look forward to you trying out these new features and sharing your feedback either through Send-A-Smile/Frown (use #cpp2015), Connect, User Voice or down below in the comments.

Category
C++

Author

Ankit Asthana
Principal Program Manager

1 comment

Discussion is closed. Login to edit/delete existing comments.

  • Miki Nagy

    We have just switched to Android gradle from Android ANT project, because we had a lot of problem with multidexing. Unfortunately the switch between debug and release config much more complicated then under the ANT version.
    Can I pass somehow the used configuration (Debug or Release) to the gradle? Or should the gradle android.buildTypes be modified manually?
    Thank You in advance!