Explain what a Gradle product flavor is and give a free vs pro example
Tests understanding of build-variant dimensions beyond build types. A strong answer defines flavorDimensions, sets free and pro applicationIdSuffix values, and explains variant generation. Red flag: conflating flavors with build types or manual APK renaming.
What's really being asked
This question tests whether you understand the difference between product flavors and build types, and whether you can use Gradle's variant system to isolate code and resources for different product editions without duplicating modules. Interviewers want to see that you know flavors represent product dimensions while build types represent stages of the build pipeline, and that you can configure source sets and generated BuildConfig values in a maintainable way.
The full answer
First, define a flavor dimension such as tier inside the android block so Gradle knows how to group flavors. Second, declare free and pro productFlavors with distinct applicationIdSuffix values so both variants can install side by side, and add buildConfigField entries for feature flags like FEATURE_SET. Third, create source directories src/free/java and src/pro/java or res to hold edition-specific code and assets, letting the compiler merge them automatically. Fourth, explain that flavors cross product with build types like debug and release to generate the full variant matrix, for example freeDebug, freeRelease, proDebug, and proRelease. Fifth, mention that you can customize dependencies per flavor using freeImplementation or proImplementation to pull in analytics or billing libraries only where needed.
The mistakes people make
A major red flag is treating build types as flavors by putting free and pro logic inside debug and release blocks. Another mistake is suggesting you maintain two separate app modules or use manual file copying to produce APKs, which destroys maintainability. Some candidates forget flavorDimensions entirely, which causes Gradle to emit an error in newer plugin versions. Others propose runtime if checks on a boolean everywhere instead of compile-time source-set isolation, which litters the codebase with conditionals and increases binary size.
What usually comes next
The interviewer may ask how you handle a third dimension such as country or apiLevel, which requires adding another flavorDimension and understanding that Gradle multiplies all dimensions together. They might also ask how to resolve source-set merge conflicts when the same class exists in both src/free and src/main, or how variant-aware dependency resolution works with native libraries. You could also be asked how product flavors interact with the Android App Bundle and dynamic feature modules.
A concrete example
Suppose you have a news reader app. In build.gradle you set flavorDimensions tier and add a free block with applicationIdSuffix .free and buildConfigField boolean FEATURE_ADS true, plus a pro block with applicationIdSuffix .pro and buildConfigField boolean FEATURE_ADS false. You place an AdsManager class in src/free/java/com/example/app that loads banners, and a no-op stub in src/pro/java/com/example/app with the same package and class name so the shared main code compiles against both. When you run assembleProRelease Gradle builds the pro variant with the stub and no ad SDK dependency, while assembleFreeDebug builds the free variant with real ads and a suffix that lets it install alongside the pro edition on the same device.
Interview question
To keep pro-only billing code out of the free APK while sharing a common codebase, which approach follows Gradle product-flavor best practices?
- a.Place runtime if-checks on BuildConfig.FLAVOR throughout the main source set
- b.Add the billing class to src/pro/java and a no-op stub to src/free/java, then reference it from mainCorrect
- c.Use debug and release build types to separate the free and pro editions
- d.Maintain separate app modules for free and pro and copy shared files manually
Why? this is the answer
Source-set merging lets Gradle compile only the relevant edition-specific code, keeping the free APK smaller and cleaner. Runtime if-checks on BuildConfig.FLAVOR are a common anti-pattern because they bloat the binary and scatter product logic across the main codebase.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #gradle
- #build-variants
- #product-flavors
- #intermediate
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