Using Gradle Product Flavors and Build Properties for Flexible Android Builds at Huajiao

Huajiao’s Android client needs to generate many APK variants to satisfy different market and functional requirements, such as fast and normal versions, store‑specific app names, channel‑specific features, and SDK configurations.

To meet these needs the team relies on Gradle’s productFlavor mechanism, which allows defining flavorDimensions and combining them to produce distinct builds. A typical configuration looks like:

// Configure dimensions, order matters
flavorDimensions "api", "mode"

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

When a flavor is selected, Gradle looks for source files under src/<flavorName>/java and merges XML resources, allowing each variant to have its own implementation and manifest entries.

For simpler requirements the team also uses Gradle build properties passed via the -P flag. In build.gradle they check the property with project.hasProperty() and expose it through buildConfigField or resValue. Example for changing the app name:

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

The resulting AndroidManifest.xml uses @string/appNameX, so building with gradlew -PappNameX=花椒直播 assemble produces an APK whose label is “花椒直播”.

Another use case is toggling statistic logging:

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

In Java code the flag can be read via BuildConfig.SHOW_STATISTIC_LOG to enable or disable logging.

To avoid generating unwanted variants, a variantFilter block can exclude them based on flavor combinations:

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

Finally, the team customizes the APK filename to embed build‑specific information, preventing overwrites and easing delivery:

applicationVariants.all { variant ->
    def buildId = "${applicationName}" + "_${variant.buildType.name}" + "_${defaultConfig.versionName}" + flavorNames
    variant.outputs.all { outputFileName = "${buildId}.apk" }
}

Through the combined use of product flavors, build properties, variant filtering, and dynamic naming, Huajiao achieves a flexible and maintainable multi‑variant Android build pipeline.