Build Variants & Signing Explained
BUILD & TOOLING › Gradle
Build types are Android's answer to *how* a module gets compiled, as opposed to product flavors, which answer *what version* gets built. Every module ships with two build types out of the box: debug and release, and you can add more. debug is debuggable, gets signed automatically with a throwaway local keystore, and does not shrink your code. release starts as the opposite of all three: not debuggable, unsigned until you wire a signingConfig yourself, and unshrunk until you opt in with isMinifyEnabled. Interviewers ask about build types to see whether you separate this 'how' axis cleanly from the 'what version' axis that flavors control; conflating the two is a common tell that someone has only used Android Studio's defaults and never actually configured a release pipeline.
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
}
}
}
Product flavors represent different versions of the same app, like free versus paid, or dev versus prod, and every flavor must be assigned to a named flavor dimension. The total number of build variants Gradle produces is the cross product of the flavor counts in every dimension, multiplied by the number of build types. Two dimensions with two flavors each, times two build types, is not four variants, it is eight, because dimensions multiply against each other rather than adding. This trips people up in interviews because they instinctively add flavor counts instead of multiplying them.
Every build variant gets its own Gradle task for assembling it, named by concatenating the flavors in the order their dimensions were declared, then the build type, each part capitalized: assemble followed by Flavor1, Flavor2, and BuildType. Getting the order wrong is an easy way to run the wrong task or to misread someone else's CI config, so it is worth being able to reconstruct a task name from a flavorDimensions declaration on sight.
You can inject per-variant values two different ways. buildConfigField adds a typed constant to the generated BuildConfig class, which you read straight from Kotlin or Java code. resValue instead generates an Android resource, the kind you'd reach through R, useful when a manifest placeholder or an XML layout needs the value rather than your code. Both can be scoped to a build type or a flavor, and string values passed to buildConfigField need their own quote marks escaped inside the value string, since the value itself is Kotlin source that becomes the field's literal.
Since Android Gradle Plugin 8.0, the BuildConfig class is no longer generated automatically just because you called buildConfigField. You must opt in explicitly per module with buildFeatures { buildConfig = true } inside the android block, or set the matching flag in gradle.properties. Skip that step after upgrading AGP and every buildConfigField call still compiles fine at the Gradle level, but any reference to BuildConfig in your Kotlin code fails to resolve, because the class was never generated. This is a classic 'worked yesterday, broken after the AGP bump' gotcha.
Each build variant can have its own source set folder, and when the same resource or class is defined in more than one, Gradle resolves the conflict by priority. For a variant like demoDebug, built from flavor demo and build type debug, the order highest to lowest is: the variant-specific folder src/demoDebug first, then the build-type folder src/debug, then the flavor folder src/demo, and finally src/main, which is always merged in but sits at the lowest priority. Two Kotlin or Java classes with the same name defined for the same variant are a hard build error though, Gradle has no priority rule that can pick a winner between two definitions of one class at the same level.
When two flavors from different dimensions both set the same buildConfigField or resValue, Gradle needs a tiebreaker, and that tiebreaker is the order you declared flavorDimensions in. Earlier-listed dimensions take priority over later ones. Declare flavorDimensions as listOf("tier", "env") and a flavor in the tier dimension will always win a collision against a flavor in the env dimension, for every variant that combines them. This is easy to get backwards under interview pressure, since intuitively you might expect the later-applied one to win, the way later CSS rules override earlier ones, but Gradle's flavor priority runs the opposite direction.
The debug build type doesn't need you to configure a signingConfig because Gradle auto-generates one for you: a debug keystore at $HOME/.android/debug.keystore, created the first time you build, with a well-known alias and password baked into the tooling. That's exactly why it works everywhere with zero setup, and exactly why it's useless for anything beyond your own machine, Google Play and virtually every other store explicitly reject uploads signed with it. Confusing this auto-generated keystore with a real release signingConfig is one of the more common junior mistakes.
Wiring a signingConfig onto the release build type is something you have to do yourself, Gradle does not assume one. Skip it, and assembleRelease still completes successfully, but the output is an unsigned app-release-unsigned.apk that Android refuses to install and Play refuses to accept, since every APK or AAB that reaches a device or the Play Console has to carry a valid signature. Only the debug build type gets a signingConfig for free, from the auto-generated debug keystore covered earlier.
Two apps can only coexist on the same device if their applicationId values are actually different, Android treats applicationId as the package identity, full stop. applicationIdSuffix, set on a build type like debug, appends onto that id, so com.example.app becomes com.example.app.debug and the two builds install as genuinely separate apps. versionNameSuffix is a cosmetic cousin, it only changes the displayed version string and does nothing for coexistence, which is exactly the distinction interviewers probe for.
Sometimes your app defines a build type a dependency doesn't have. Say your app adds a custom qa build type for internal testing, but a third-party library you depend on only ships debug and release; Gradle can't find a qa variant of that library to link against, and the build fails with a variant-matching error. matchingFallbacks, set on your custom build type, tells Gradle which of the library's build types to substitute in that case, tried in the order you list them.
The mirror-image problem: a dependency declares a flavor dimension, say backend, that your own app module never defined at all. Gradle has no flavor of yours to pair with the library's backend flavors, so it can't compute a matching variant. missingDimensionStrategy, set in defaultConfig, tells Gradle which of the dependency's flavors in that dimension to pick, without forcing you to add the dimension to your own app.
Under Play App Signing, two separate keys are involved, and mixing them up is a favorite interview trap. You sign every AAB you upload with your own upload key. Google verifies that upload, then re-signs the APKs it actually delivers to devices with a completely different app signing key, one it generates and stores for you in its own secure infrastructure, you never see it again after setup. The payoff shows up when a key gets lost: lose your upload key, and you request an upload key reset in the Play Console, then keep shipping updates, because Google still holds the app signing key devices already trust. Lose your one and only signing key on a project without Play App Signing, by contrast, and you can never publish an update to that app again.
An upload key reset fixes a lost upload key, but it doesn't help if you need to move your actual app signing key itself, say because it's been compromised or you're consolidating projects onto a new one. That's what APK Signature Scheme v3 is for: introduced in Android 9, it supports a certificate lineage, a signed record proving that a new signing key is the legitimate successor to an old one. Devices that understand v3 accept the rotated key as trusted, while older devices that predate v3 keep validating against the original key. It's the mechanism, not a Play Console button, that actually lets you rotate a signing key while continuity holds.