Android Build System: BuildConfig fields and Build Variants

In this article, we are going to learn about the Android build System-Gradle, and how it helps to configure different aspects of your build i.e Build types, build variants, Product flavor, dependencies, and more...

‍

Android Build System

We all need our Android project code resources well configured, organized, and accessible to the users without modifying the core source files. This can be achieved using the Android build system. It compiles app resources and source code and packages them into APKs for testing, deployment, signing configuration, dependency management, and distribution.

You can manage your build processes and define flexible custom build configurations that are specific to building and testing Android apps using the Gradle build system and Android plugins (Gradle and the Android plugin run independently from Android Studio). 

Each build configuration defines its own set of code and resources while reusing the common code in all versions of your project.

Gradle and the Android plugin help you configure,

• Build Types
• Build Variants
• Product Flavours
• Manifest entries
• Dependencies
• Signing
• Code and resource Shrinking
• Multiple APK Support

The project configuration files typically contain a slew of constants; these constants can be made flavor-specific in Android using BuildConfig. It enables you to arrange, tweak and change the settings of a build using a build system.

‍

What is BuildConfig?

Gradle generates a BuildConfig class that contains static configuration constants that are specific to the build at build time. The class includes default fields such as debug and flavor, but you can override them with build.gradle.  

BuildConfig class is generated for each build variant separately and contains information such as application id, debug flag, flavor dimensions, version name, and version code.

‍

Custom Build Configurations

Build Type

Build Type class refers to the build and packaging setting in the module-level build.gradle file inside the android block. The default build types are release and debug.

When we run the application from the IDE directly onto a device, the debug will use an Android debug certificate to package the APK file.

While the release type will use a user-defined release certificate for signing and packaging the APK, the release builds are defined to upload on the play store. In the release build, the code is obfuscated using ProGard to prevent reverse engineering.

Build type allows you to define how Gradle will build an application. They can be defined in the app’s build. gradle file like this:

1android {
2    buildTypes {
3        release {
4            isMinifyEnabled = true
5            proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")
6        }
7
8        debug {
9            applicationIdSuffix = ".debug"
10            isDebuggable = true
11        }
12    }
13}
14
15     

Android Product Flavor

Android Product flavors are created in the build.gradle file similar to build types.  It is used to customize the code for different application versions that you expect to coexist on a single device, google play store, or repository.

These app versions can be free or paid, they can have different features, icons,  resources, styles, themes and can use different environments, and APIs. For example, the production code is slightly different from the development code.

Another example is, the Product flavor can be used to make the live server URL as a base URL for Retrofit in one flavor while adding a testing server URL for debugging purposes.

You can combine the configuration for multiple product flavors by creating groups of product flavors, called flavor dimensions. The flavors dimensions property is used in the following code sample to create the Version flavors dimension, which groups the free and paid versions.

1android {
2  flavorDimensions("version")
3
4  productFlavors {
5    freeVersion {
6      // Select the dimension for flavor
7      dimension = "version"
8
9      // Configure applicationId for free version
10      applicationId = "com.pcc.flavors.free"
11
12      // Configure app name for free version
13      resValue("string", "flavored_app_name", "Free Great App")
14    }
15
16    paidVersion {
17      // Select the dimension for flavor
18      dimension = "version"
19
20      // Configure applicationId for paid version
21      applicationId = "com.pcc.flavors.paid"
22
23      // Configure app name for paid version
24      resValue("string", "flavored_app_name", "Paid Great App")
25    }
26  }
27}
28
29     

Build Variant

Build Variant is the outcome of Gradle that uses a specific set of rules to combine resources, setting, and code configured in your build types and product flavors. In short, we can say that build variant is the combination of build type and Product flavors. 

Although you cannot directly configure build variants, it includes a combination of the configurations,  resources in the build types, and product flavors in the main source set.

For example, for build types (debug and release) and product flavors (free and paid versions), the resulting build variants can be freeDebug, freeRelease, paidDebug, and paidRelease.

To view build variants in Android Studio navigate to View → Tool Windows → Build Variants. It will look like this:

‍

‍

Manifest entries

If you want to generate multiple APKs for your app modules, each with a unique application name, minimum SDK version, or target SDK version. In the build variant, you can specify values for some Manifest file properties.  The specified values will override the existing ones.

Dependencies

The build system helps you to manage project dependencies from your local filesystem and remote repositories and helps you to reduce lots of manual work.

Signing

With the build system, you can specify the signing setting in BuildConfig. It automatically signs your APK during the build process and avoids password prompts at build time.

Code and resource shrinking

The build system applies an appropriate set of rules and shrinks your code while building your application to avoid reverse engineering using shrinking tools such as R8.

Multiple APK support

The build system allows you to automatically generate builds for different APKs, with each APK containing only the code and resources required for a specific screen density or Application Binary Interface.

‍

Simplify Android (Kotlin) app development with DhiWise

Developers struggle with different issues in Android app development and configuring app build is one of them. 

DhiWise Android Builder allows developers to automatically generate build variants with Development, QA, and Production values when they add configuration fields in the product flavors of DhiWise. 

DhiWise enables developers to speed up the development process with its advanced features and technologies. So they can wrap up the month’s work in weeks.

“Build your next Android app with DhiWise . Experience the power of simplicity with the modern agile development approach; we believe in delivering value through a developer-centric platform.” 

Sign up now!

Short on time? Speed things up with DhiWise!

Tired of manually designing screens, coding on weekends, and technical debt? Let DhiWise handle it for you!

You can build an e-commerce store, healthcare app, portfolio, blogging website, social media or admin panel right away. Use our library of 40+ pre-built free templates to create your first application using DhiWise.