What is a Gradle product flavor?

What's really being asked

This question tests your practical, hands-on knowledge of the Android Gradle build system. The interviewer wants to see if you can go beyond the simple debug/release buildTypes. They are assessing your ability to manage codebase variations for different user-facing products (like free vs. pro, or white-labeling for different clients) efficiently and scalably. It's a test of build configuration expertise, not just coding.

The full answer

First, define product flavors as a way to create different versions of your app from the same project, intended for different distribution channels or user segments. Second, immediately contrast them with build types, which are for the development process (e.g., debug enables debugging, release enables ProGuard/R8). Explain that they combine to create build variants (e.g., freeDebug, proRelease). Third, provide a concrete configuration example for a free/pro app, defining free and pro flavors in the android block of your build.gradle.kts file. Key properties to mention are applicationIdSuffix (e.g., ".free") to allow both apps on one device, and buildConfigField (e.g., buildConfigField("Boolean", "IS_PRO", "true")) to create a compile-time flag. Fourth, explain how flavors automatically create source sets (e.g., src/pro/java, src/free/res), allowing you to provide flavor-specific code, resources, and even dependencies (proImplementation vs. freeImplementation).

The mistakes people make

A major red flag is confusing product flavors with build types. Saying "flavors are for debug and release" is an instant fail. Another common mistake is proposing a runtime solution, like fetching a user's entitlement from a server and using an if statement. A senior engineer knows to use BuildConfig fields to completely compile-out pro features from the free build, which is more secure and reduces the free app's APK size. Forgetting to mention applicationIdSuffix is also a negative signal, as it suggests a lack of practical experience in testing different flavors on a single device.

What usually comes next

Expect questions like: "What are flavor dimensions and when would you use them?" (Answer: For complex build matrices, like free/pro combined with staging/production API endpoints). Another is, "How would you manage different dependencies for each flavor?" (Answer: Using flavor-specific dependency configurations like freeImplementation and proImplementation). Finally, "How does this impact your CI/CD pipeline?" (Answer: The pipeline must be configured to execute specific build variant tasks, like ./gradlew assembleProRelease and bundleProRelease).

A concrete example

In app/build.gradle.kts, you would configure the flavors: productFlavors {

create("free") {

applicationIdSuffix = ".free" versionNameSuffix = "-free"

buildConfigField("Boolean", "IS_PRO", "false")
resValue("string", "app_name", "My App Free")
}
create("pro") {
buildConfigField("Boolean", "IS_PRO", "true")
resValue("string", "app_name", "My App Pro")
}
}

Then, in your Kotlin code, you can check the compile-time flag:

if (BuildConfig.IS_PRO) {

// Unlock pro features } else { // Show ads or upgrade prompts } This if/else block is resolved at compile time, meaning the else branch code is not even included in the pro build.