How do you build different versions of the same app from one codebase?
You use build types, product flavors, and variants!
Let’s explain the concept and dive into some examples.
<h2>What is a build type</h2>
A build type defines how the app is built.
The most common build types are:
<ul>
<li>debug</li>
<li>release</li>
</ul>
Debug is what you use during development. It usually:
<ul>
<li>Is debuggable</li>
<li>Has logging enabled</li>
<li>Is signed with a debug key</li>
<li>May include tools like LeakCanary</li>
</ul>
Release is what you ship to users. It usually:
<ul>
<li>Is not debuggable</li>
<li>Has code shrinking enabled</li>
<li>Is signed with your real keystore</li>
<li>Has logging disabled</li>
</ul>
So build types describe technical behavior.
<h2>What is a product flavor</h2>
A product flavor defines what app you are building.
Examples:
<ul>
<li>demo vs prod, different backend servers</li>
<li>free vs paid, different features</li>
<li>white label apps for different clients</li>
<li>staging vs production</li>
</ul>
Flavors describe business or product differences.
You can think of flavors as different personalities of your app.
<h2>What is a variant</h2>
A variant is the combination of:
One build type
One flavor from each flavor dimension
For example:
<ul>
<li>demoDebug</li>
<li>demoRelease</li>
<li>prodDebug</li>
<li>prodRelease</li>
</ul>
Each of those is a fully buildable and installable app.
When you click Run in Android Studio, you are running a specific variant.
<h2>Step 1: Basic Android app setup</h2>
Open your app module file:
<code>app/build.gradle.kts</code>
Inside the android block, you typically have something like:
<pre><code>android {
 namespace = &quot;com.example.variants&quot;
 compileSdk = 35

 defaultConfig {
 applicationId = &quot;com.example.variants&quot;
 minSdk = 24
 targetSdk = 35
 versionCode = 1
 versionName = &quot;1.0&quot;
 }
}
</code></pre>
This defines your base app configuration.
<h2>Step 2: Understanding build types in practice</h2>
Add build types inside the android block:
<pre><code>android {

 buildTypes {
 debug {
 applicationIdSuffix = &quot;.debug&quot;
 versionNameSuffix = &quot;.debug&quot;
 isDebuggable = true

 buildConfigField(&quot;Boolean&quot;, &quot;LOGGING_ENABLED&quot;, &quot;true&quot;)
 }

 release {
 isMinifyEnabled = true
 isShrinkResources = true

 buildConfigField(&quot;Boolean&quot;, &quot;LOGGING_ENABLED&quot;, &quot;false&quot;)

 proguardFiles(
 getDefaultProguardFile(&quot;proguard-android-optimize.txt&quot;),
 &quot;proguard-rules.pro&quot;
 )
 }
 }
}
</code></pre>
What this does:
<ul>
<li>Debug builds have a different application id, so you can install them next to release.</li>
<li>Debug builds expose a constant called LOGGING_ENABLED.</li>
<li>Release builds enable code shrinking.</li>
</ul>
Use the generated constant in code:
<pre><code>object LoggerConfig {
 val loggingEnabled = BuildConfig.LOGGING_ENABLED
}
</code></pre>
Now your app behaves differently depending on build type.
<h2>Step 3: Creating your first flavor</h2>
Now we introduce flavors.
We will create two environments:
<ul>
<li>demo</li>
<li>prod</li>
</ul>
First, define a flavor dimension:
<pre><code>android {

 flavorDimensions += &quot;environment&quot;

 productFlavors {
 create(&quot;demo&quot;) {
 dimension = &quot;environment&quot;
 applicationIdSuffix = &quot;.demo&quot;
 versionNameSuffix = &quot;.demo&quot;

 buildConfigField(
 &quot;String&quot;,
 &quot;API_BASE_URL&quot;,
 &quot;\&quot;https://api.demo.example.com\&quot;&quot;
 )
 }

 create(&quot;prod&quot;) {
 dimension = &quot;environment&quot;

 buildConfigField(
 &quot;String&quot;,
 &quot;API_BASE_URL&quot;,
 &quot;\&quot;https://api.example.com\&quot;&quot;
 )
 }
 }
}
</code></pre>
Now you have:
<ul>
<li>demoDebug</li>
<li>demoRelease</li>
<li>prodDebug</li>
<li>prodRelease</li>
</ul>
Each one has a different API base URL.
Use it in your networking layer:
<pre><code>object ApiConfig {
 val baseUrl: String = BuildConfig.API_BASE_URL
}
</code></pre>
No if statements required.
<h2>Step 4: Source sets and environment specific code</h2>
Android supports separate folders per flavor.
Structure example:
<ul>
<li>app/src/main</li>
<li>app/src/demo</li>
<li>app/src/prod</li>
<li>app/src/debug</li>
<li>app/src/release</li>
</ul>
Suppose you want a developer menu only in demo.
Create:
<code>app/src/demo/java/com/example/variants/FeatureFlags.kt</code>
And in:
<code>app/src/prod/java/com/example/variants/FeatureFlags.kt</code>
<pre><code>object FeatureFlags {
 const val showDeveloperMenu = false
}
</code></pre>
The correct file is compiled automatically depending on variant.
This is cleaner than runtime checks.
<h2>Step 5: Multiple flavor dimensions</h2>
Now let us introduce branding.
Suppose you want:
<ul>
<li>One codebase</li>
<li>Two clients: acme and globex</li>
</ul>
Add a second dimension:
<pre><code>android {

 flavorDimensions += listOf(&quot;environment&quot;, &quot;brand&quot;)

 productFlavors {

 create(&quot;demo&quot;) { dimension = &quot;environment&quot; }
 create(&quot;prod&quot;) { dimension = &quot;environment&quot; }

 create(&quot;acme&quot;) {
 dimension = &quot;brand&quot;
 applicationIdSuffix = &quot;.acme&quot;
 resValue(&quot;string&quot;, &quot;brand_name&quot;, &quot;Acme&quot;)
 }

 create(&quot;globex&quot;) {
 dimension = &quot;brand&quot;
 applicationIdSuffix = &quot;.globex&quot;
 resValue(&quot;string&quot;, &quot;brand_name&quot;, &quot;Globex&quot;)
 }
 }
}
</code></pre>
Now total variants:
2 environments times 2 brands times 2 build types equals 8 variants.
This is how large production apps handle white labeling.
<h2>Step 6: Variant specific dependencies</h2>
You can attach dependencies to specific variants.
<pre><code>dependencies {

 implementation(&quot;androidx.core:core-ktx:1.13.1&quot;)

 debugImplementation(&quot;com.squareup.leakcanary:leakcanary-android:2.14&quot;)

 demoImplementation(&quot;com.jakewharton.timber:timber:5.0.1&quot;)
}
</code></pre>
LeakCanary only in debug.
Timber only in demo builds.
This keeps production builds clean.

Mark Kazakov

A practical guide to Android build types, product flavors, and build variants using Gradle Kotlin DSL. Covers the difference between build types (debug/release) and product flavors (demo/prod, white-label clients), how variants are formed from their combinations, and step-by-step examples including BuildConfig fields, source sets per flavor, multiple flavor dimensions for white-labeling, and variant-specific dependencies like LeakCanary only in debug builds.

Android build types, product flavors, and variants from zero to production