With the help of Gradle and the Android plugin, you can easily automate processes that in the past needed to be manually done and a lot of time-consuming activities. Among the advantages of these configurations, we find Android Gradle Build Configuration, with which you can get different versions of your app with variations for things like testing, using different backend endpoints, switching assets, or enabling some locked features.
When talking about these variations we find three main terms “build type”, “product flavour” and “build variant”. Let’s explore each of these and use-cases for one over another.
Build Type
Build Types are mainly for development stages, they allow you to have an app version for each of the steps of your development process. This stages vary from project to project but refer to steps like:
- Develop or Debug
- Testing or QA
- Release
- Release Candidate often referred with the acronym RC
- Golden Master, often referred with the acronym GM
And probably a lot more examples you could think of. Gradle won’t limit you on the number of versions you can have.
What are build types useful for?
Build types give you options for your app such as:
- Adding a suffix to your app id
- Determining whether it’s debuggable or not, which also affects the type of certificate with which the app is signed.
- Minify the code
- Change hostnames
- Optimizing png images
You can find a complete list of options here.
Where do you configure Build Types?
This configuration is made in the module-level build.gradle file. If you started from an Android Studio template project you will find the base of the code there for you:
android {
...
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
...
}
As you can observe in the code above, Android by default provides you with a release ‘build type’, this is because you need to have at least one in order to be able to build a project.
Product Flavor
Flavours are different versions of the same app that you will release. The most common use-case for this is when creating a freemium version of your app and another for paid users. It is usual to see this in games or some other apps, where you don’t get adds if you get the paid version.
For those apps you may have all the build types you defined, as build types are independent of the flavors.
When you want certain parts of the code to execute on one version but not on another is when you use flavors. You may have a menu with disabled buttons in one flavor and another with all buttons accessible. Of course you may be thinking there are other ways to manage this, and it’s true, but you may need flavors for some use cases.
Flavor Dimensions
When you define a flavor you should pair it along with a dimension. In the example above the dimension might be: “version”. But you may also want to have different menus accessible for users in Europe and Africa, so you may add another dimension called “region”.
Remember, your app should have at least one dimension when you add flavors.
What are Product Flavors useful for?
Above I provided two examples of when you may want to use flavors:
- Versions: Full versions, demos, betas, one with adds, another without adds.
- Regionalization: Options available for certain regions that are not available for others.
But those are not the only examples, let’s look at some other:
- When working on apps are clients that want one app with exactly the same features but they want their logo placed in certain areas. When using flavors you can customize the assets, colors, and everything related to the UI of the app to have their brand identity, without the need for different code-bases.
- For phones with a certain API level (Android version), you may know they don’t have certain capabilities that you want to implement, so you may choose not to include that code through a flavor.
Many of these things are easier to achieve with AABs (Android App Bundles) if you want to know how those work, take a look at my article on them.
Where do you configure Product Flavor and Flavor Dimensions?
Just as you did with Build Types, you will configure them in the module-level build.gradle file. Unlike Build Types, if you started from an Android Studio template project, there is no default flavor created, as many projects don’t need this. But don’t worry, adding flavors is easy:
android {
...
defaultConfig {...}
buildTypes {...} // Specifies one flavor dimension.
flavorDimensions "version"
productFlavors {
free {
dimension "version"
applicationIdSuffix ".free"
versionNameSuffix "-free"
}
full {
dimension "version"
applicationIdSuffix ".paid"
versionNameSuffix "-paid"
}
}
...
}
Build Variant
Build Variants are the result of having Build Types and Flavors. Following the examples above, if you had a building type for testing with the app flavor for your European region, the build variant would be testing + Europe.
If you think so, you may end up with a lot of build variants, basically: numberOfBuildTypes * numberOfFlavors
Yes, you usually end up with a lot of versions of your app and testing them can be a bit overwhelming in the beginning, but don’t worry, you will get the hang of it.
Note: If you are wondering how are suffixes added, you will have: appName<flavor><build-type>, so flavor suffixes come before build-type suffixes.
Where do you configure Build Variants?
Build Variants are not directly configured in Gradle because as mentioned above, they are the byproducts of adding flavors and build-types.
Wrapping Up
Configuration for Android projects may seem a difficult topic at first, but it is relatively easy once you understand it. Don’t be afraid of Gradle files, they make a lot of sense once you get used to them. If you want to know more about this topic look at Android’s official documentation on build variants.
If you liked the content on this post, please subscribe at the bottom of the page. Don’t hesitate to leave a comment if you have any doubts or comments, I will reply as soon as possible. You can also donate a coffee to support me so I can keep on creating things like this
See you next time.
Evana Margain Puig
