Gradle Build Variants for the Common Dev - Part 1: Build Types
By: Greg Loesch

With the introduction of the new Gradle build system for Android came a new build feature called Build Flavors , as well as the ability to better hook into the different Build Types (Debug, Release).  We’ll be discussing the latter in this post.

Most of the example use cases you’ll see using these build variants revolve around having a free/lite and paid version of an app that slightly varies in functionality. While these build variants (and more particularly Build Flavors) are perfectly suited for this, a lot of developers don’t have these tiered apps, and thus, I’d imagine, may not pay much attention to these build features.  At WeddingWire we only have free apps, but we still utilize these build tools to help manage builds internally.

Modifying our build.gradle file

For this first part, let’s drop into a typical project’s build.gradle file.  Out of the box, a new project will generally contain a block that Google has so graciously provided us that's similar to the following:

 android {  
   buildTypes {  
     release {  
       runProguard false  
       proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'  
     }  
   }  
 }

This block tells you where proguard configurations should be grabbed and ironically, not to run proguard on release builds. You can ignore this info for now, as proguard is not the topic of discussion :).

By itself, this isn’t all that helpful, though you can add some useful build flexibility and management with just a few extra lines!

Add a debug { } closure!

At WeddingWire, one of the first things we do is add a debug closure to configure our debug builds.  In this block, we add two lines, as you can see below.

 android {  
   ...  
   buildTypes {  
     release {...}  
     debug {  
       applicationIdSuffix '.debug'  
       versionNameSuffix '-debug'  
     }  
   }  
 }

applicationIdSuffix

The first line, applicationIdSuffix '.debug' - as it's aptly named - adds a suffix to the end of our Application id.  This id is usually something along the lines of "com.weddingwire.appname" and is set in the defaultConfig{} block in our build.gradle (may be in your AndroidManifest.xml file if it's an older project).  Assuming our application id is com.weddingwire.testapp, the resulting application id would be “com.weddingwire.testapp.debug.”

Why is this helpful?

By adding an applicationIdSuffix to your debug builds, this means you can have both a debug build AND a production/Play Store version on your device at the same time.  No more "Application Not Installed. an existing package by the same name with a conflicting signature is already installed" errors!

versionNameSuffix

Setting a versionNameSuffix tacks on the provided string at the end of your app version name for debug builds.  In this example, if our typical app version name was something like "1.2.2", the debug version name would be "1.2.2-debug."

This, along with the next tip, helps us quickly distinguish between debug and release build types.

Custom icons for Build Types

One of the simplest ways to quickly distinguish between builds is to use a custom icon for the different build variants.  This can be done by creating folders that correspond to the “debug” and “release” Build Type names (which contain java/ and res/ directories).  This is better explained with a picture:

Screenshot 2014 10 15 16.55.40

As you can see in this screenshot, we've added "debug" and "release" folders (at the same level of our already existing "main" and "instrumentTest" folders).  We added "java" and "res" subfolders in each Build Type folder as well.  By convention, Android will automatically add the contents of these folders to the existing source and resources found in the "main" folder depending on which type is being built.

Adding a custom ic_launcher.png (assuming that's the name of your app's launcher icon drawable) in the debug/res/drawable-*dpi folders essentially overrides the ones found in main/res/drawable-*dpi for debug builds.

Now not only will you be able to install a debug version right alongside a production version, but you'll be able to easily identify which is which by looking at the icon.

Screenshot 2014 10 15 17 27 15

SHARE:

Meet Greg:
Greg is a Senior Software Engineer (Android) at WeddingWire. Greg is from Mansfield, Ohio and has a Computer Science and Engineering degree from Ohio State University. When he isn't over-analyzing better ways to architect Android apps, Greg pretends to be a photographer, plays a little guitar, and ponders all things wedding.