Product Flavors Plug-in in Five Steps
By Tarika Chawla – Mobile Development
Do you want to hire 10 developers to generate a customized android app for 10 clients or have one source code to generate those 10 apps for you. Product Flavor is a gradle plugin in android, available to customize multiple apps using the same code.
Product flavor is defined as the customized version of an application built in the project. A single project/source code can have more than one flavor which can change the generated application. In the same source code, every flavor have a different applicationId, so that you can simultaneously install different flavors from the project on the same device.
Apps can be customized within the same source code using different resources, buildConfig etc. Product flavors are similar to build types. They are added in the build gradle file at the module level. The rules and features for every product can be changed using the buildConfigField. This tutorial will put all these things together in order to provide one logic so that the users can create a new app in 5 steps. And how at Microshare my team implemented this feature to create customized apps.
Microshare have many clients who want to access data in a customized manner and features through their app. Microshare is a prepackaged data management and data sharing platform. We provide SDK’s for multiple platforms such as Android, iOS etc in order to access that data and analyze it. Microshare platform control the access and security of different entities within the data lake. Every company/ entity can live in their own environment inside the platform. Product flavors help us to create that modular and scalable environment on mobile end which is customized based on the needs and requirements of the client or entity.
Five questions to uncover the process of adding a product flavor:
1) How to add product flavors:
productFlavors are added in the module build.gradle file. It goes right under the buildTypes such as release or demo version.
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
}
}
productFlavors {
doIo {
applicationId “point.io.securevault”
buildConfigField “boolean”, “Has_PushNotification”, “true”
buildConfigField “boolean”, “GuestLogin”, “false”
versionCode 15
versionName “3.2.581”
signingConfig signingConfigs.DoioConfig
}
pmc {
applicationId “io.point.pmc”
buildConfigField “boolean”, “Has_PushNotification”, “false”
buildConfigField “boolean”, “GuestLogin”, “false”
versionCode 5
versionName “1.4”
signingConfig signingConfigs.PMCConfig
}
}
2) What to customize
- Resources such as app icon, background images, splash image
- google-services.json files based on the Google API’s being used
- String.xml file
- buildConfigField values: For me this is where I create rule book for every app. Consider I don’t want push notifications for this product flavor, just give the buildConfigField value as False.
The question is how to access this build Config value while the app is running, its quite simple: BuildConfig.BuildConfigKeyName, In case of Push notification use case based on above screenshot it should be BuildConfig.Has_PushNotification
- Other Configuration changes:
Not every product flavor can have the same version code and version number. Well then we need to customize those configurations as well. Usually, VersionCode, Version name and application ID goes into defaultConfig. But in this case we will move them under the product flavor in order to customize them.
According to the image below, all the keys under defaultConfig can be customized under each product flavor or buildTypes. The keys under defaultConfig are inherited as it is under all the product flavors and build types.
Image: Relationship between defaultConfig and productFlavors
3) How to generalize the Product flavor
I am sure you don’t want to do redundant work for every product flavor then what is the point of having the same source code. Android studio made it way simpler for you. The key to this is the main folder under the Project Files
These resources are used by default if the product flavor does not find anything specific to the product flavor. As an example, if the the activity is trying to access the R.string.appName. If there is no specific
BRT
in the strings.xml under values folder of that specific product flavor, then the gradle will use the value from string.xml under the main>values folder.
4) How to access src and values
Project Files> app> src > ProductFlavorName (brt, pmc)
For each product flavor, you can see the res, strings.xml or all the assets which belong to that specific product flavor.
5) How to run each Product Flavor
Build Variant is a cross product of product flavor and build type. There are two types of build types:
- Debug
- Release
- *you can add more build types based on your use cases such as demo, paid, unpaid versions.
In order to run a specific product flavors.
Click on Build Variants (on the left side of the screen) to open the tab. For testing, run the productFlavorNameDebug. Whereas for the release productFlavorNameRelease
For any questions, please comment below.
Tarika Chawla is a mobile developer at Microshare.io