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. There are only 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 (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 has 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 of the Maven builds was its ability to support building a Development, QA, Beta and a 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). The process 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" is that 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 stable enough and we recommend that all projects switch over to it.