Android New Build System (Gradle)

At Lolay we've now started and are using the Android "New Build System" on 3 projects with success.  We are using a combination of using Android Studio and Gradle with the Android Gradle Plugin. Overall, it was a good decision and it's been worth the time investment as well as minor bugs with Android Studio.

For a background, prior to this for Android development we would use Eclipse, Maven, Maven Android Plugin and the Eclipse m2e Plugin (And we've also used IntelliJ). We're not huge fans of Eclipse, but it is the most popular IDE for Android development (probably not for long). Using Maven, Android and Eclipse together is not an easy experience, and typically had lots of issues. This would particularly be true where the IDE build worked, but the Maven build did not (or vice versa).

One of the things we did like with the Maven builds was the ability to support building a Development, QA, Beta and Release version of an application all of which would use different server URL's, different Flurry codes, etc. This allowed a sophisticated setup. The only problem is this caused a lot of duplication and Android Manifests to obtain this result (we settled on using Maven profiles to point to alternate Android Manifests). This all worked, but was difficult to maintain.

Enter the "New Build System" with Android Studio. First, Android Studio is an absolute pleasure to use. It's as good as the Google I/O talks present. It's also very stable for a Beta version of the product, although this is most likely a result it's really based on IntelliJ and IntelliJ's Android support under the scenes, which was already pretty robust. The Android Plugin for Gradle is also very stable, and this is most likely a result of being able to learn from the Android Plugin for Maven.

One of the nice things about using Android Studio and Gradle with the Android Plugin is it has direct support for building multiple versions of an application. We are now building Debug, QA, Beta and Release version of the application and use different buildTypes to support each one. It's very natural, and it supports modifying your single Android Manifest so that we no longer need to have multiple manifests. In addition, it has a nice "overlay" feature where code and resources in src/main can be overlayed by content/settings in src/{buildType}. This allows us to have have a src/debug/res/values/strings.xml to add in environment specific URL's or Flurry codes. It also allows us to have an environment specific icon in src/debug/res/drawable/ic_launcher.png.

We've also have the great benefit that both the IDE and command line both use Gradle for the build, so that we no longer get issues where an engineer says "works fine built from Eclipse".

The only issue we've run into with the "New Build System" are that occasionally on an Android Studio upgrade it can break something in the project (I'm speaking to you 0.2.4). We've learned to make sure we have a time machine backup before applying any Android Studio upgrade). But, even when this does occur we could build the project command line and edit with a basic text editor like Text Mate to get the build out.

Android Studio and the Android Plugin for Gradle are mainstream enough and stable enough that we recommend all projects switch over to it.