Previously in this series we’ve looked at various aspects of the Android Gradle build system and how we can adapt things in various ways. But what about if we want to convert our existing projects to use the Gradle build system? In this article we’ll do precisely that.
In a previous article on Styling Android we looked at using the GridLayout v7 support library. One of the problems that we saw was that getting the dependency on the GridLayout v7 support library set up was a little fiddly because it contains resources as well as code, and we need to set up a second project containing all of this. But we saw earlier in this series that importing Android Library projects is a whole lot easier under the Gradle build, so our GridLayout-revisited code is a good candidate for showing how we can convert an existing project to Gradle, and also see how much simpler things are when we import Android Libraries as AAR.
The first thing to do is to check out the GridLayout-Revisited sample code from here. The main things that we’ll need to address are importing the GridLayout v7 support library, and that the source tree structure differs from the default Android Gradle structure. To address these issues, and to begin the conversion to Gradle Build we need to add a
build.gradle in the top level directory. Optionally we can also add the Gradle wrapper which I have done by simply copying the
gradle folder and
gradlew.bat scripts from an existing project.
The first thing we need to add to
build.gradle is the buildScript section which configures the environment in which the build executes:
This makes the Android Gradle plugin available to this build. Next we apply the plugin which causes the necessary tasks to produce an Android APK during the build:
apply plugin: 'android'
Now we add a dependency on the GridLayout v7 support library:
We are loading this from the local Maven repository in the same manner than we covered in part 4 of this series. This implicitly imports this dependency in AAR format meaning that we no longer have to create a second project and import the relevant support library.
Next we declare the android configuration which specifies the minimum and target SDK levels, as well as the version of the build tools that we are using for the build:
FInally, we need to change the default source paths to find the manifest, Java source, and resources within the project structure:
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
It’s worth noting that we’re also specifying changes to the aidl, renderscript, and assets source folders as well. This configuration was lifted directly from the official documentation and is a generic model for mapping the old project structure to Gradle build. Using this configuration will ensure that any project which conforms to the old structure will build. Even though, in this case, we aren’t concerned about these additional directories, it is good practise to map the entire structure otherwise we could face problems in the future if we, for example, added assets to the project and couldn’t work out why they weren’t being included!
That really is all there is to it! Simply adding the
build.gradle is enough to get the project building in Gradle, and also to open fully configured into Android Studio.
I won’t specifically cover converting an Android Library project to Gradle because it is almost identical to this, with the exception that we apply the
android-library plugin instead of the
apply plugin: 'android-library'
There is one potential issue that you may face when importing into Android Studio, however. You may see an error similar to the following:
Gradle: A problem occurred evaluating root project 'gridlayout-revisited'.
> The SDK directory '/Users/<username>/Library/Caches/AndroidStudioPreview/compile-server/"/Applications/Android Studio.app/sdk"' does not exist.
I encountered this when building on MacOS. The cause of this is that Android Studio is not correctly finding the SDK install directory. It is easily rectified by adding a
local.properties file to the top level directory, and including a line pointing to the SDK location:
This is the correct location for MacOS, but will vary on different environments. I have not included this file in the sample code because
local.properties is designed to be a configuration on the local build environment and not be generic to all environments.
project.properties is the place for generic properties (and should be committed to source control), and local.properties is the place for those specific to the local environment (and so should not be committed to source control).
One final thing which is worth mentioning is that converting an existing project to the Gradle build can be done by simply adding the
build.gradle file, and not altering the source directory structure at all. This means that the Gradle build can happily co-exist with other build systems such as Ant or Maven. This is actually really important because it means that we can experiment with moving our projects over to Gradle without abandoning our existing build mechanism. We can actually use both in parallel while we iron out the problems, and we have the confidence to make the transition permanent. This significantly reduces the risk of beginning to migrate to Gradle because we do not need to make any commitment until we are happy that it does what we require, and actually works!
In the next article we’ll have a look at some further tools that the Android Gradle build provides us to simplify our builds.
The source code for GridLayout-revisited with Gradle build support is available here.
© 2013 – 2015, Mark Allison. All rights reserved.
Copyright © 2013 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.