Build Variants & Signing Interview Questions
BUILD & TOOLING › Gradle
Walk me through why a team would introduce product flavors instead of just using a buildConfigField flag or a runtime check to differentiate a free versus paid version of an app.
What a strong answer covers: Flavors give you compile-time separation via distinct source sets, so paid-only code and assets never even ship inside the free APK rather than being gated behind a runtime check that could be bypassed or accidentally left exposed, and separate applicationIds let both variants install side by side and be released and rolled back independently on the Play Store. The trade-off is a bigger variant matrix and more CI time, so it's worth it mainly when the difference is substantial rather than cosmetic.
When would you actually reach for a new flavor dimension versus just adding a plain flavor or a buildConfigField flag? What's the real cost of adding another dimension?
What a strong answer covers: Add a dimension only when that axis is genuinely orthogonal and needs to multiply against your existing flavors, like a tier dimension that shouldn't imply anything about an environment dimension; the real cost is combinatorial, since every new dimension multiplies the whole variant matrix and CI build and test time by its flavor count, and dimension order also affects source set merge priority. If the difference doesn't need separate code or resources or an independently releasable APK, a simple flag is cheaper.
For the paidRelease variant, the same string resource is defined with different values in the main source set, the paid flavor source set, and the release build type source set. Walk me through which one wins and how you'd debug it if the wrong value shipped.
What a strong answer covers: Android merges from lowest to highest specificity: main loses to the flavor source set, which loses to the build type source set, which loses to a variant-specific source set like paidRelease if one exists; so here release beats paid unless a paidRelease override is also present, in which case that wins outright. The common mistake is assuming a flavor always beats the build type; to debug it you'd inspect the merged resources output for that variant under build/intermediates rather than guess from the source files alone.