ProductFlavors in Android

Table of contents

What is Product Flavor in Android

• In Android app development, “product flavors” (also referred to as “build flavors”) are a feature provided by the Gradle build system.
• Allows to create multiple variations of the Android app from a single codebase.
• Product flavors are often used to build different versions of an app for different target audiences, environments, or configurations.
• These variations can differ in several ways, including app icons, resource files, package names, and even code.

Difference between Build Flavor, Build Mode & Build Variant

1. Build Flavor ~ is about how to create separate environments for the app using the same code base.

2. Build Modes ~ Allow to specify how the app is built, packaged, and signed for different purposes, such as development, testing, and release.

   Most common build modes in Android are:

   • Debug mode: is used during app development and debugging. Gradle generates an APK that contains debuggable code and symbols. Debug builds are typically larger in size and may include additional logging and debugging information.

   • Release mode: is used when the app is preparing for distribution to end-users through app stores. In release mode, Gradle generates a smaller and more optimized APK. Release builds are also signed with a production keystore for security.

   • Test mode: When one runs tests, Gradle compiles the code in test mode, which allows to access and test the app’s classes and methods. Test builds may have specific configurations, such as test-specific dependencies and settings.

   • Profile Mode: It includes instrumentation and profiling hooks to collect performance data and analyze the app’s behavior, such as CPU usage, memory consumption, and method tracing. Profiling is essential for optimizing your app’s performance.

   • Custom Build Modes: In addition to the standard build modes, one can define custom build modes or product flavors in the app’s build.gradle file to create variants tailored to specific scenarios, such as different environments, feature sets, or branding.

3. Build variant - is a combination of both build mode and build flavor, which allows us to customize the version of the application.

Use cases for Product flavors

1. Branding: One can create different product flavors to build versions of the app with different branding elements, such as app icons, logos, and color schemes. This allows to tailor the app’s appearance to different clients or brands while using the same core functionality.

2. Feature Flags: One can use product flavors to enable or disable specific features in different versions of the app. As an example, we might have a “lite” version of any app with limited features and a “premium” version with additional functionality.

3. Environments: Product flavors can be used to define variations of the app for different environments, such as development, testing, and production. Each environment may have different server endpoints, API keys, or configuration settings.

4. Package Names: Each product flavor can have its own package name. This is useful when one wants to publish multiple versions of an app on the Google Play Store or other app distribution platforms.

5. Languages and Localizations: Product flavors can be used to provide translations and localized resources for different regions or languages. This ensures that the app is culturally relevant to a global audience.

What is Environment

Environments are crucial

• for ensuring the quality,
• reliability, and
• security of the Android app.

They help developers and testers work in controlled settings during development and testing phases while ensuring that the app functions correctly and securely when deployed to the production environment.

Common environments in Android Development

1. Development Environment: developers write and test their code during the app’s development phase. In the development environment, one might use development tools, debugging features, and test data.

2. Testing Environment: perform various types of testing on the app, such as unit testing, integration testing, and user acceptance testing. It often involves deploying the app to a dedicated test server or environment where testers can evaluate its functionality, usability, and performance.

3. Staging Environment: Closely resembles the production environment but is separate from it. It is used for final testing and quality assurance before deploying the app to the production environment. Staging environments help identify and address issues that might occur in production.

4. Pre-production or UAT (User Acceptance Testing) Environment: This environment is used to conduct user acceptance testing, where end-users or stakeholders evaluate the app’s functionality and provide feedback before it goes live in the production environment.

5. Production Environment: It is the live environment or “real-world” context where the app is made available to end-users. Apps in the production environment should be thoroughly tested and optimized to provide a seamless user experience.

6. Custom Environments: Depending on the app’s requirements, one may have custom environments tailored to specific scenarios. For example, one might have separate environments for beta testing, demo purposes, or different geographic regions.

Example of how to define product flavor in the app’s build.gradle file

android {
    flavorDimensions "brand", "environment" // Optional dimension names

    productFlavors {
        free {
            dimension "brand" // Optional dimension name
            applicationId "com.example.free"
            versionCode 1
            versionName "1.0"
        }

        paid {
            dimension "brand" // Optional dimension name
            applicationId "com.example.paid"
            versionCode 2
            versionName "2.0"
        }

        debug {
            dimension "environment" // Optional dimension name
            applicationIdSuffix ".debug"
        }

        release {
            dimension "environment" // Optional dimension name
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

What is flavorDimension

”flavorDimension” - is an optional attribute used within the productFlavors block.

• It is to define dimension names for product flavors.
• Flavor dimensions are used to organize and group product flavors, allowing you to create a multi-dimensional matrix of flavor combinations.

In the above example : the “brand” dimension includes two flavors: “free” and “paid,” while the “environment” dimension includes “debug” and “release.” By specifying dimensions for the product flavors, one can create a matrix of possible flavor combinations like ->

• “freeDebug,"
• "freeRelease,"
• "paidDebug,"
• "paidRelease.”

Accessing Flavor-Specific Build Configurations

One can access flavor-specific build configurations and variables in the code by using the BuildConfig class. For example,

BuildConfig.FLAVOR

will give you the name of the current flavor.

Build and Run Your Variants ~ To build a specific flavor, you can use the following Gradle command:

1. php ->

./gradlew assemble<FlavorName><BuildType>

2. bash ->

./gradlew assembleFreeRelease

Also one can choose Product flavor from Build Variant of Android studio IDE and run the code.

What is versionCode

• versionCode is an unique positive integer value that represents the version of the app’s code.
• The versionCode should be incremented with each new release of the app.
• Android uses versionCode internally to manage and compare different app versions.
• It plays a crucial role in the app update process on the Google Play Store. When one releases a new version with a higher versionCode, users are prompted to update their installed version.
• Ensure that one does not reuse versionCode values for different app versions.

defaultConfig {
    versionCode 2
    // ...
}

What is versionName

• versionName is a string value that represents the user-friendly version of the app.
• Follows a format like “1.0.0” or “2.1.3” to convey the app’s version to users in a human-readable way.
• Unlike versionCode, which is used for internal version tracking, versionName is displayed to users in the app store and within the app itself.
• One can include additional information in versionName if desired, such as release notes or build information.

defaultConfig {
    versionName "2.1.3"
    // ...
}

Get hooked with more learning objects and follow us. Happy Learning !!