Android Project Setup — Part 1 — Build Variants

Building apps @ scale

Hello all,

This is a series of articles on how to set up your Android Project, based on my personal experience. This is not perfect (not even close) and your suggestions are welcome in the comments section.

The topics I will cover during this series are the following.

  1. Build Flavors & Variants
  2. Fastlane Integration (for Mac users only)
  3. Testing
  4. CI/CD
  5. Continuous inspection

The project can be found on Github. The code will be tagged at the end of each part (e.g. part-1).


So, lets start… with Build Types.

This first part will be around build variants of our project. My experience has shown that 2 build types are needed, one is for Debug builds that contain debug information & logs and one is for release builds either for beta testing via Crashlytics/Firebase or for actual releases of your application. So open your app modules build.gradle file and make sure that under buildTypes is the following. I will explain in detail later why we need applicationIdSuffix. For now all u need to know is that your debug builds applicationId will have a “.debug” suffix.

buildTypes {

debug {
applicationIdSuffix ".debug"
debuggable true
}

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

Now we would like to add some product flavors. We will be using 1 dimension and 2 flavors for that dimension, but feel free to adapt these numbers to the needs of your project. We will be building a fairly simple product, so we will use a flavor dimension named environment”, a “ stage” and a “production” flavor. We add the dimension by adding the following line to our build.gradle.

// Defines the environment we are working on
flavorDimensions "environment"

And now we add the flavors

productFlavors {
stage {
dimension "environment"
applicationIdSuffix ".stage"
versionNameSuffix "-stage"
}

production {
dimension "environment"
}
}

Now sync your gradle file and upon finishing you should the following in your Build Variants window (View > Tool Windows > Build Variants).

What we have achieved so far is that we have set 4 build variants for our project.

Now lets say a few things about “applicationIdSuffix”.

Lets say we want to have different builds of the same app on our test device. E.g. we can have our production version, which is released on the Google Play Store, the debug version we are building at the moment and also the version we have distributed via Crashlytics/Firebase. This is where applicationIdSuffix comes in handy. Android won’t let you have the same application id installed twice on your device. But, what if the application id is only used for our productionRelease configuration and the rest will be build by appending the suffix to our base applicationId, defined in the defaultConfig of our gradle file. Then we can have as many installations of our app as our bundle ids. So, in our case we will be 4 applicationIds, one for each variant.

  • productionRelease => com.hack.max.landmark (inherited from our defaultConfig)
  • productionDebug => com.hack.max.landmark.debug (debug build type appends the “.debug”)
  • stageRelease => com.hack.max.landmark.stage (stage flavor appends the “.debug”)
  • stageDebug => com.hack.max.landmark.stage.debug (stage flavor appends the “.stage”, debug build type appends “.debug”)

Now we can have 4 different builds in our device, but they all have the same name, and its kinda hard to identify which is which. The are all called after our “app_name” string resource. What we need, is a different name per build variant. Well, guess what, it is possible.

In order to do so we will create a new Source Set. By default android creates the main source set for our project. This is usually where our main code and assets reside. We are going to create 3 new source sets stageDebug, stageRelease and productionDebug variants. What we actually need is a different app_name for each build variant, so we will add strings.xml in their respective res folder, in the build variants folder. This way android will pick the right app_name during build.

In order to add a new strings.xml for a buildVariant

  1. In the same Project pane, right-click the src directory and select New > XML > Values XML File.
  2. From the drop-down menu next to Target Source Set, select your variant.
  3. Enter strings in the name field.
  4. Click finish.

This way 3 new strings.xml files will be created under app/src/{buildVariant}/res/values . What I want to achieve do is to add a prefix to the name of the app with the initial letters of the flavor followed by the build type one. You could have your own convention though, that will work for your project. So we will use the following names for out app’s variants.

  • stageDebug : <string name=”app_name”>SD-Landmark</string> in app/src/stageDebug/res/values/strings.xml
  • stageRelease: <string name=”app_name”>SR-Landmark</string> in app/src/stageRelease/res/values/strings.xml
  • productionRelease: <string name=”app_name”>PR-Landmark</string> in app/src/productionRelease/res/values/strings.xml

If you liked this, click the clap below so other people will see this here on Medium.