Using Product Flavors and Gradle Build Properties for Android Multi‑Variant Builds

Android multi‑variant builds allow a single codebase to generate different APKs based on various configurations. Huajiao needs to produce fast and normal versions, use different app names for certain stores, enable channel‑specific features (login pre‑load, splash preview, pre‑install, etc.), and adjust SDKs according to store advertising policies.

Huajiao primarily uses Gradle's productFlavors and build‑type attributes to meet these requirements, providing a flexible mechanism that quickly responds to diverse build demands.

Product Flavors

Product flavors, offered by the Android Gradle Plugin, let developers define flavorDimensions and combine them to produce distinct APKs. A typical configuration looks like:

// Configure dimensions; order determines flavor priority
flavorDimensions "api", "mode"

productFlavors {
  demo {
    dimension "mode"
    // ... other settings ...
  }
  full {
    dimension "mode"
    // ... other settings ...
  }
  minApi24 {
    dimension "api"
    minSdkVersion 24
    versionCode 30000 + android.defaultConfig.versionCode
    versionNameSuffix "-minApi24"
    // ... other settings ...
  }
  minApi23 {
    dimension "api"
    minSdkVersion 23
    versionCode 20000 + android.defaultConfig.versionCode
    versionNameSuffix "-minApi23"
    // ... other settings ...
  }
}

The order of flavors in productFlavors determines priority; when both demo and minApi24 set minSdkVersion, the api dimension (placed first) wins.

When a flavor is selected, Gradle looks for source folders named after the flavor (e.g., src/demo/java) and merges resources such as AndroidManifest.xml with the main source set.

In Huajiao, this mechanism is used for CTA pre‑install packages: separate folders ( ctaEnable and ctaDisable) contain different BaseApplicationHook, CtaActivity, and manifest snippets, as illustrated in the diagram below.

When a flavor needs to remove entries from the main manifest, the tools:node="remove" attribute can be used.

Android Studio Variant Window

After defining flavors, each combination creates a variant with its own source set. In Android Studio, the Build Variants panel lets developers switch the displayed variant. Module dependencies follow the selected variant; if a dependent module lacks a matching variant, Gradle falls back to the default (e.g., debug).

Gradle Build Properties

While powerful, product flavors have drawbacks: complex configuration, long variant names for many small builds, difficulty enumerating non‑enumerable dimensions (e.g., dynamic launch URLs), and the need to keep code compilable across all flavors.

For simple requirements that do not modify resources or the manifest—such as toggling a feature or setting a launch URL—Huajiao uses Gradle build properties passed via the -P flag.

The workflow is:

Supply a property on the command line, e.g., -PappNameX=HuajiaoLive.

In build.gradle, check existence with project.hasProperty() and retrieve the value with project.property().

Use the value directly in the Gradle script or expose it to Java code via resValue or buildConfigField.

Example: configuring the application name.

String appNameX = "花椒"
if (project.hasProperty("appNameX")) {
    appNameX = project.property("appNameX")
}
defaultConfig {
    resValue "string", "appNameX", appNameX
}

The above makes the string available as @string/appNameX in the manifest, so running ./gradlew -PappNameX=花椒直播 assemble produces an APK whose label is "花椒直播".

Build properties can also be injected into BuildConfig:

boolean showStatisticLog = false
if (project.hasProperty("showStatisticLog")) {
    showStatisticLog = true
}
defaultConfig {
    buildConfigField "boolean", "SHOW_STATISTIC_LOG", String.valueOf(showStatisticLog)
}

Java code can then enable logging conditionally:

if (BuildConfig.SHOW_STATISTIC_LOG) {
    QHStatAgent.setLoggingEnabled(true);
    QHConfig.setDebugMode(context, true);
    QosSdk.enableLog(true);
}

In Android Studio, these properties can be set under Settings → Compiler as shown below.

Variant Practice

Filtering Unwanted Variants

Some flavor combinations are not needed. They can be excluded via variantFilter:

variantFilter { variant ->
    def names = variant.flavors*.name
    def buildType = variant.buildType.name
    if (names.contains("friendsChannel")) {
        setIgnore(!(names.contains("smEnable") &&
                     names.contains("loginForceFullScreenEnable") &&
                     names.contains("googlePlayDisable") &&
                     names.contains("ctaDisable")))
    }
}

Custom APK Naming

When flavors and build properties are combined, many APKs can be generated. To avoid name collisions, Huajiao encodes build characteristics into the APK filename using applicationVariants:

applicationVariants.all { variant ->
    def buildId = "${applicationName}" +
        (buildName.length() > 0 ? "_${buildName}" : "") +
        "_${variant.buildType.name}" +
        "_${defaultConfig.versionName}" +
        (loginRequestX ? "_loginRequest" : "") +
        flavorNames +
        "_targetSDK${targetSdk}" +
        (huaweiPPS ? "_huaweipps" : "") +
        (huaweiChannel ? "_huaweiChannel" : "") +
        (quickStart ? "_quickStart" : "") +
        (usePhone ? "_usePhone" : "") +
        (oppoDeepLink ? "_oppoDeepLink" : "") +
        (desc.length() > 0 ? "_${desc}" : "") +
        (buildNum.length() > 0 ? "_${buildNum}" : "")
    variant.outputs.all { outputFileName = "${buildId}.apk" }
}

This strategy ensures each generated APK has a unique, descriptive filename that reflects its configuration.