Using Android Product Flavors to build Full and Demo Version of the app.

ProductFlavor is a very powerful feature available in the Android gradle plugin that allows us to manage different “flavors” of an application.
This is useful when you want the same application but with different features per flavor (e.g. Full Version vs Free Version).

In this post we will build a simple weather app that will display the current temperature for a given city using openweathermap.org. To illustrate our point, this fully integrated app will be called the “Full” version.

We will add a different flavor called “Demo” version for our marketing team so users can use the app without the real data. The “Full” version app will make web service calls where as the “Demo” version app will return canned data so no web service calls are made.

Product flavor is configured in build.grade file.

In the above block, we defined “demo” and “full” product flavors. We set applicationId and app_name string resource in each flavor. Doing this allows us to install both applications at the same time on a device since they have unique applicationIds.
We also gave them different names, defined by app_name. The Full version will be named “Full App” and the Demo version will be named “Demo App”.
(Note: app_name is used in AndroidManifest.xml the application name)

Now, we will need to set up the source directories for each flavors so that we can have specific classes in them.
Lets create
app/src/full/java and app/src/demo/java parallel to app/src/main/java

2. Folders

Common classes and resources should live in main/java package where as flavor specific classes and resources live in each flavor specific source folder we created above.

In this example we have “WeatherService.java” class in each product flavor. Class in full flavor makes calls to openweathermap.org.

Class in Demo flavor just returns a dummy data and does not make a network call.

You will find that both classes refer to “WeatherListener” which is defined in the main flavor.

Let’s build each flavor, In Android Studio, so you can pick a flavor by going to “BuildVariant” tab on the left. Let’s pick “demoDebug”. This picks the “demo” flavor with the “Debug” type. The combination of these two makes the “demoDebug” build variant.
Running this build variant will build our “Demo” version of the application. This application will show “75.0” for any city except for “Bermuda”.

Screen Shot 2015-03-26 at 10.52.17 AM

Screen Shot 2015-03-26 at 10.51.33 AM

Now, let’s build the “fullDebug” flavor where it will make the call to “openweathermap.org” to get the weather information for the city entered.

Screen Shot 2015-03-26 at 11.07.42 AM

Here you can see that we built both full and demo versions of the app using same source.

Full code could be found at: https://github.com/manijshrestha/BuildVariantDemo

You can read more about product flavors on android gradle plugin site: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors

About the Author

Object Partners profile.

One thought on “Using Android Product Flavors to build Full and Demo Version of the app.

  1. Alice Wang says:

    Hello,

    This is very nice and useful,

    Best Regards

  2. Alice Wang says:

    Hello,

    This is very nice and useful. Thanks for posting this.
    I have another question, generally, we will have product flavors like full_staging, demo_staging for testing use. Product flavour full_staging wants to have the same source code (WeatherService.java in this example) as product flavour ‘full’, but has different configurations, like using different weather request urls. In this case, have to copy WeatherService.java to each product flavour. Are there any better solution to solve this ?

    Best Regards
    Alice

  3. Annamalai says:

    Hi ,
    Thank you for the helpful blog.

    Can we able to create layout xml files in the flavor we create ? When i created a layout file in the same name which presents in main folder , the schemas throwing some exceptions.

    Please reply me.

    Thank you.
    Malai…

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Feature Flags in Terraform
Feature flagging any code can be useful to developers but many don’t know how to or even that you can do it in Terraform. Some benefits of Feature Flagging your code You can enable different […]
Infrastructure as Code – The Wrong Way
You are probably familiar with the term “infrastructure as code”. It’s a great concept, and it’s gaining steam in the industry. Unfortunately, just as we had a lot to learn about how to write clean […]
Snowflake CI/CD using Jenkins and Schemachange
CI/CD and Management of Data Warehouses can be a serious challenge. In this blog you will learn how to setup CI/CD for Snowflake using Schemachange, Github, and Jenkins. For access to the code check out […]
How to get your pull requests approved more quickly
TL;DR The fewer reviews necessary, the quicker your PR gets approved. Code reviews serve an essential function on any software codebase. Done right, they help ensure correctness, reliability, and maintainability of code. On many teams, […]