Explain Gradle product flavors with a free/pro app example
This tests your grasp of the build variant matrix, not just flavors. A great answer defines flavors, explains how they combine with build types, details Gradle config (applicationIdSuffix), and mentions source sets.
What's really being asked
This question tests your practical, hands-on knowledge of the Android build system. The interviewer is looking for more than a dictionary definition. They want to see if you understand the build variant matrix (the combination of product flavors and build types), how to configure it in Gradle, and how to structure your application's code and resources to support it efficiently. It's a test of both build configuration skill and application architecture.
The full answer
An excellent answer has four parts. First, define a product flavor as a way to create different versions of an app, like free vs. pro, from a single codebase. Second, explain the crucial concept that flavors combine with build types (e.g., debug, release) to create build variants (e.g., freeDebug, proRelease). Third, describe the specific Gradle configuration within the android { productFlavors { ... } } block, mentioning key properties like applicationIdSuffix for unique package names and buildConfigField to expose flavor-specific constants to your code. Finally, explain how to use source sets (e.g., src/free/java, src/pro/res) to provide different code implementations or resources for each flavor.
The mistakes people make
A major red flag is confusing product flavors with build types. A candidate who only talks about debug and release has misunderstood the question. Another common mistake is giving a vague answer without mentioning specific Gradle DSL like productFlavors, applicationIdSuffix, or buildConfigField. Simply saying you'd use an if statement in your code is a weak answer; the correct approach involves leveraging the build system's source sets to provide different implementations of a class or different resources entirely, which is a much cleaner architectural pattern.
What usually comes next
Expect follow-ups like: "How would you handle flavors that need to share some code, but not all?" (The answer involves flavor dimensions). Or, "How would you manage different API keys for each flavor?" (Using resValue, buildConfigField, or manifest placeholders). Another good one is, "What's the difference between applicationIdSuffix and versionNameSuffix?"
A concrete example
In your build.gradle.kts file, you would define the flavors: productFlavors { create("free") { applicationIdSuffix = ".free"; buildConfigField("boolean", "IS_PRO", "false") }; create("pro") { buildConfigField("boolean", "IS_PRO", "true") } }. Then, you could create a file src/free/java/com/example/feature/PremiumFeature.kt that shows an upgrade dialog, while the file at src/pro/java/com/example/feature/PremiumFeature.kt contains the actual paid feature implementation. The build system automatically selects the correct file for the free and pro variants.
Interview question
How do Gradle product flavors primarily enable the creation of distinct app versions (e.g., free vs. pro) from a single codebase?
- a.By creating entirely separate Gradle modules for each app version, each with its own complete set of source files.
- b.By defining separate applicationId values for each version directly in the AndroidManifest.xml file.
- c.By generating unique build variants through their combination with build types, which then utilize dedicated source sets for variant-specific code and resources.Correct
- d.By allowing developers to write conditional logic within their Java/Kotlin code that checks a runtime flag to enable or disable features.
Why? this is the answer
Product flavors combine with build types to form build variants, and these variants then leverage dedicated source sets to include variant-specific code and resources, which is the architectural pattern described. While conditional logic can be used, the card explicitly states this is a 'weak answer' compared to using source sets.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles