Android Build Variants: One Codebase, Many Apps
Think of build variants as a matrix for your app builds, combining build types (like debug/release) with product flavors (like free/paid). This lets you manage different API endpoints or features for various versions from a single codebase.
Why it exists
Apps often need multiple versions. You need a debug version for development and a release version for the Play Store. You might also have a free version with ads and a paid version without. Managing these as separate projects would be a nightmare of copy-pasting code. Build variants solve this by letting you define these differences within a single project.
The mental model
A build variant is the result of a cross-product. Imagine a grid: the rows are your Build Types (e.g., 'debug', 'release'), and the columns are your Product Flavors (e.g., 'demo', 'full'). Each cell in that grid, like 'demoDebug' or 'fullRelease', is a unique build variant you can assemble and run. This lets you mix and match packaging rules with feature sets.
How it works
In your app's build.gradle file, you define buildTypes and productFlavors. Gradle then automatically creates variants for every possible combination. For each variant, you can provide specific code or resources (like layouts, strings, or icons) in dedicated source sets, such as src/demo/java or src/release/res/values. When you build a specific variant, Gradle intelligently merges the code and resources from the main, build type, and product flavor source sets.
When to use it
Use build variants when you need to produce different versions of your app from one codebase. This is ideal for managing environments (development, staging, production), monetization strategies (free vs. paid), or white-labeling (custom branding for different clients). It centralizes configuration and prevents code duplication.
When not to use it
Avoid creating too many product flavors or build types. If you have 3 build types and 10 product flavors, you get 30 variants. This significantly slows down Gradle project sync and can make the project difficult to navigate. For very distinct apps that share little logic, separate modules or even separate projects might be a cleaner approach.
One canonical example
A common setup is having debug and release build types. You then add product flavors for staging and production. The staging flavor points to a test backend URL, while the production flavor points to the live one. This results in four variants: stagingDebug, stagingRelease, productionDebug, and productionRelease. A developer can easily build stagingDebug to test new features against the test server without affecting the production app.
Interview question
According to the mental model described, how do Android build types and product flavors combine to form a build variant?
- a.They are combined as a cross-product, where every build type-flavor pair yields a unique variant.Correct
- b.A build variant is chosen by selecting either a build type or a product flavor, but not both simultaneously.
- c.Build types are nested within product flavors, creating a hierarchical structure for the app.
- d.Product flavors define the app's core functionality, while build types determine its distribution channel.
Why? this is the answer
The card states that a build variant is the result of a 'cross-product' and uses the analogy of a 'grid' where build types and product flavors combine to form each unique variant. This means every possible combination of a build type and a product flavor creates a distinct build variant.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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