Android Product Flavors: Single Class vs. Flavor-Specific Classes (Pros & Cons)
Learn why flavor-specific classes beat a single BuildConfig.FLAVOR switch for APK size, security, and maintenability.
Why We lean on BuildConfig.FLAVOR in the First Place?
The “one class to rule them all” pattern is tempting:
object ConfigAwareAnalytics : Analytics {
private val delegate: Analytics = when (BuildConfig.FLAVOR) {
"free" -> FirebaseAnalyticsImpl()
"paid" -> SegmentAnalyticsImpl()
else -> NoOpAnalytics
}
override fun log(event: Event) = delegate.log(event)
}Pros: quick to write, no Gradle gymnastics.
Cons: it hides complexity that compounds over time, especially when you add SDKs, privacy requirements, or white‑label themes.
What Product Flavors Give You Out of the Box
Android’s build system lets you isolate code, resources, and even dependencies per flavor. At build time, only the source sets for the chosen variant are compiled and packaged. That means:
- Smaller APK/AABs
- Zero runtime branching for "dead" code
- Lower attack surface (you're not shipping your paid SDK to free users)
Five Reasons Flavor‑Specific Classes Trump a Single Switch
|
Benefit |
Why It Matters |
|---|---|
|
Compile‑time separation |
Eliminates runtime if/when branches and ships only relevant bytecode. |
|
Cleaner codebase |
No scattered BuildConfig.FLAVOR checks. Each flavor’s logic lives in its own directory. |
|
Dependency isolation |
Include heavy or licensed SDKs (e.g., Stripe, Segment) only where they’re needed. |
|
Reduced bug surface |
You physically can’t call “paid” code in a “free” build; it doesn’t compile. |
|
IDE superpowers |
Android Studio understands variant‑specific code → accurate “Find Usages,” refactors, and Lint suggestions. |
When a Single Class Is Good Enough
- Prototype or hack‑day app with no long-term maintenance expected.
- ≤ 2 flavors and none of them pull extra libraries.
- Tight delivery where Gradle config time outweighs benefits.
So How Do We Decide Which Strategy to Use?
|
Choose Flavor‑Specific Classes |
Keep a Single Switch |
|---|---|
|
3+ flavors or multiple clients |
1 or 2 simple flavors |
|
Separate 3rd‑party SDKs per variant |
Same dependencies for all |
|
Security / licensing concerns |
No sensitive SDKs |
|
Team ≥3 devs |
Solo dev / PoC |
|
Long‑term maintenance budget |
Throw‑away prototype |
Business Advantages
There are quite a few benefits for non-developers:
- ‑15 % APK size on average for multi‑flavor apps.
- Fewer regressions: impossible to call code that isn’t compiled.
- License compliance: don’t ship paid SDKs to free users.
- Faster cold starts: smaller dex, fewer classes to verify.
All of these will increase the perceived quality of your apps, leading to happier users and better reviews.
Conclusion
A giant when (BuildConfig.FLAVOR) switch is fine for prototypes, but as soon as your app serves more than one paying stakeholder, flavor‑specific source sets win on APK size, security, tooling, and sanity.
