Gradle Build Types vs. Product Flavors
This tests your understanding of Gradle's build matrix for creating different app versions. A great answer defines build types (how it's built) vs. flavors (what is built) and explains that variants are the cross-product. A red flag is confusing their roles.
What's really being asked
This question assesses your ability to manage build complexity in a mature Android project. The interviewer wants to see if you understand the fundamental difference between configuring how an app is built (build types) versus what is included in the app (product flavors). It's a test of practical Gradle knowledge beyond the basics, crucial for managing different environments (dev, QA, prod), monetization strategies (free vs. paid), or white-labeling.
The full answer
A strong answer explains the concepts in order. First, define Build Types as properties for packaging and signing, like debug and release. They control settings like debuggable, minifyEnabled, and signing keys. Second, define Product Flavors as different versions of your app you release, like free and paid, or mock and prod API endpoints. They control resources, code, and dependencies. Third, explain that a Build Variant is the final, buildable artifact, created by combining one build type with one product flavor (e.g., freeDebug, paidRelease). The total number of variants is (number of types) x (number of flavors).
The mistakes people make
A major red flag is confusing the two concepts, for example, saying you'd use a build type to change the app's name or icon. That's a flavor's job. Another mistake is describing them as interchangeable or simply as "ways to change the build." The key is the conceptual separation: build types are about the process of building (debug vs. release), while flavors are about the product being built (free vs. paid). Candidates also stumble by not knowing that they combine multiplicatively to create variants.
What usually comes next
Expect questions about managing complexity. For example, "What are flavor dimensions and why would you use them?" (Answer: to combine more than two flavor categories, like (free/paid) x (google/amazon) stores). Another is, "How do you manage different source sets for each variant?" (Answer: Gradle uses a priority-based system, where freeDebug source sets override free, which overrides main). You might also be asked about managing different dependencies per variant (freeImplementation vs. paidImplementation).
A concrete example
A common scenario is a freemium app. You'd use two product flavors: free and premium. The free flavor might include an ad SDK dependency (freeImplementation 'com.google.android.gms:play-services-ads:...') and show ads in the UI. The premium flavor would have no ad dependency and would have UI code that hides the ad views. You would also have two build types: debug and release. The debug type would be signed with a debug key and have ProGuard/R8 disabled (minifyEnabled false). The release type would be signed with your production key and have code shrinking enabled (minifyEnabled true). This setup creates four build variants: freeDebug, freeRelease, premiumDebug, and premiumRelease, each serving a specific purpose.
Interview question
What is the primary conceptual distinction between Gradle Build Types and Product Flavors?
- a.Build Types define how the app is packaged and configured, while Product Flavors define what content and features are included.Correct
- b.Build Types determine the application's identity (name, icon), while Product Flavors control build performance optimizations.
- c.Build Types manage external dependencies, while Product Flavors manage internal source code organization.
- d.Build Types are exclusively for development environments, and Product Flavors are exclusively for production environments.
Why? this is the answer
Option A accurately captures the core distinction: Build Types control the *process* of building (e.g., debuggable, signing), whereas Product Flavors define the *product* being built (e.g., features, resources for free vs. paid versions). Option D is a common misconception, as both are utilized across all environments.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #gradle
- #build variants
- #build systems
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