Summary

The article discusses using Android build variants to manage different server environments efficiently.

Abstract

The article provides insights into leveraging Android build variants for streamlined management of development, staging, and production server environments. It explains the distinction between build types and product flavors, emphasizing the use of build variants to automate the selection of server configurations, thereby eliminating manual updates when generating APKs. The author introduces an experimental approach to define build variants for each server environment, ensuring that the appropriate base URLs and configurations are automatically included in the build process. The article also offers practical Gradle tips, such as using initWith to inherit properties from existing build variants, and suggests that this method can be adapted to accommodate additional environments and API keys as needed.

Opinions

The author views the use of build variants to manage server environments as an improvement over manual configuration updates.
The approach described is considered experimental and the author welcomes feedback and suggestions for enhancements.
Product flavors are praised for their flexibility in maintaining separate code for different app variants within the same codebase.
The author emphasizes the importance of automating the build process to reduce the potential for human error and to increase efficiency.
The article suggests that the described method can be customized to fit various workflows and requirements beyond the typical three server environments.

Use Android Build Variants To Manage Server Environments

Build, run, and deploy multiple apps simultaneously

Takeaway From the Article

By the end of this article, you’ll have learned how to use build variants to manage your server’s development, staging, and production environments. With this approach, you no longer need to update anything before generating APKs.

Note: This is an experimental approach; if you’ve any suggestions for enhancements or you find bugs, let me know in the comments.

Introduction

Android, by default, uses two build types: debug and release. When you run an app through the Android studio, it will install debug APK, and while building signed APK, you can see both build types.

If you’ve implemented any product flavors, you’ll see these two variants for each flavor. Build types are different from product flavors. Product flavors are the top-level distribution of app variants, and build types are internal variants of each flavor.

A common use case to demonstrate product flavors and build variants is free and paid versions. Here free and paid are product flavors, whereas release and debug are build variants. Finally, you’ll end up with four build variants, as shown below:

Product flavors are a powerful feature in the Android Gradle system that allows you to create different app variants with the same code base. It gives the flexibility to maintain whatever is required in all variants on the main module and create a separate module for each flavor to implement independent code. To learn more about it, read the following article:

Android Product Flavors

Here is everything you need to know about product flavors and real-time problems with solutions

sgkantamani.medium.com

Don’t confuse product flavors with build variants; product flavors are the top-level distribution of app variants, and build types are internal variants of each flavor.

Now that you know the difference between product flavors and build variants, it’s time to use build variants to manage server environments. Usually, the development process contains three environments: development, staging, and production.

Development: Usually, developers build and test the new implementation in this environment.

Staging: Once the developers are finished with implementation and done with their testing, they’ll move to staging, where the main testing and final approval to move production take place.

Production: If the application is approved, it’ll go to the production server, where it’s available to end users.

Server Environments With Build Variants

Now that we know what build variants and different server environments are, it’s time to make use of build variants to generate different server environment builds.

Typically, developers maintain three different sets of details for each variant. Only one set is active at any given time; we’ve to update it manually based on the type of build that is being generated. This is the process that I’ve followed over the years, but I don’t think it’s the best approach because it involves manual work on each build generation. It has the scope to be automated.

My idea to automate this process is to maintain three different build variants serving each server environment. We need to declare build variants buildTypes inside the android tag. This results in five build variants: release, debug, prod, stg, and dev. Have a look:

One of the server environment’s key changes is base URLs; we can declare the appropriate base URL in each variant using the buildConfigField feature. Have a look:

What we have basically done is we’ve removed all the manual work that we need to do while generating build types and automated them with the buildConfigField in each build type. We need just to select the required build type; all the server configurations linked to that build type are bundled automatically into the generated APK.

Real-Time Gradle Tips

Use initWith

Usually, when you’re creating a new flavor, either you apply to debug or enable ProGuard rules. By default, debug variant is in debug mode, whereas the release variant has ProGuard enabled. So when you’re creating a new variant, we can inherit appropriate properties from each variant using initWith.

For instance, suppose in the above example we’ve applied ProGuard rules for prod and stg variants and debug for dev variant manually. We can enhance the code by reusing those rules from release and debug mode via initWith, as shown below:

Different approaches for different workflows

Not all workflows have three environments; there might be more phases like a testing environment. We can create as many build variants as required with as many buildConfigFields as we need.

We can add different hostnames, different Facebook, Twitter, and other API keys, and different Firebase JSON config files for each variant. This makes it easy to track variant level metrics and more.

That is all for now. I hope you learned something useful, and thanks for reading.