Explain the difference between Gradle build types and product flavors.
If you know build types are how an app is built—debug versus release—while flavors are what is shipped, like free versus paid. Variants are the Cartesian product.
Treating them as interchangeable or using flavors for debug and release.
What's really being asked
This question probes whether you understand the two independent axes of Gradle Android builds. Build types control the mechanics of compilation and packaging, while product flavors control the functional identity of the application. Senior engineers are expected to reason about multi-dimensional build graphs, avoid redundant configuration, and know when to extend the build logic rather than duplicate it.
The full answer
First, define build types as the how dimension. Debug and release are the defaults, and they govern signing configuration, code shrinking and obfuscation via ProGuard or R8, debuggability, and application ID suffixes. Second, define product flavors as the what dimension. Flavors represent different versions of the app intended for different users or markets, such as free versus paid, demo versus full, or staging versus production API endpoints. Third, explain the combinatorial outcome. Gradle creates a build variant for every pairing of build type and product flavor. If you have two build types, debug and release, and two flavors, free and paid, Gradle generates four variants: debugFree, releaseFree, debugPaid, and releasePaid. Fourth, note that build types and flavors can each have their own source sets and dependency scopes, which allows variant-specific code, resources, and manifest entries without forking the entire project.
The mistakes people make
A major red flag is conflating the two concepts. Candidates sometimes say flavors are just another name for build types, or they create separate flavors for debug and release instead of using build types. Another mistake is claiming that flavors control build optimization settings like minification or signing, which actually belong to build types. Some candidates also forget that variants are the cross product and instead think flavors override build types, leading to incorrect assumptions about how many APKs are produced.
What usually comes next
An interviewer might ask how you would configure a custom build type with its own signing certificate, or how to use flavor dimensions to create more than one axis of flavors, such as tier free versus paid combined with region us versus global. They may also ask about variant-aware dependency management, how to share code between specific variants, or the performance implications of having dozens of variants in a large monorepo.
A concrete example
Imagine a news application with a free tier supported by ads and a paid tier without ads, alongside a requirement to hit staging and production backends. You should use two product flavors, free and paid, to swap the ad module and the subscription check logic. You should use two build types, debug and release, to enable logging and a debug certificate in debug while enabling R8 shrinking and the release keystore in release. The resulting variants are debugFree, releaseFree, debugPaid, and releasePaid. The free flavor pulls in the ads SDK dependency only for free variants, while the release build type ensures shrinking is applied to every release variant regardless of flavor. This keeps the concern of distribution identity separate from the concern of build mechanics.
Interview question
An app requires staging and production API endpoints alongside standard debug and release builds. What is the correct Gradle configuration?
- a.Use product flavors for debug and release, and build types for staging and production endpoints
- b.Use product flavors for the API endpoints and build types for debug and release buildsCorrect
- c.Use build types for the API endpoints and product flavors for signing and code shrinking
- d.Create four product flavors: debugStaging, releaseStaging, debugProduction, and releaseProduction
Why? this is the answer
Product flavors control functional identity such as API endpoints, while build types control compilation mechanics like debug versus release. Option D is tempting but wrong because flattening the matrix into flavors prevents Gradle from automatically generating variants and forces redundant configuration.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #gradle
- #build-variants
- #build-types
- #product-flavors
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