Why are build types distinct from product flavors?

Question

Expanding on what @CommonsWare said in the comments, the basic idea is that build types are for different builds of your application that aren't functionally different -- if you have a debug and release version of your app, they're the same app, but one contains debugging code, maybe more logging, etc., and the other is streamlined and optimized and possibly obfuscated via ProGuard. With flavors, the intent is that the app is notably different in some way. The clearest example would be a free vs. a paid version of your app, but developers may also differentiate based on where it's being distributed (which could affect in-app billing API use).

There are developers that make many, many different versions of a similar app for different customers -- an example might be a simple app that opens up a web page in a web view, with different URLs and branding for each version -- this is a good use of flavors.

To reiterate, if it's "the same application", modulo some differences that aren't important to the end user, and especially if all of the variants except for one are for your own testing and development use and only one variant will be deployed to end users, then it's a good candidate for build types. If it's "a different" application and multiple variants would be deployed to users, then perhaps it's a candidate for a product flavor.

You've already seen that there are some functionality differences between build types and flavors, in that some options are supported for one but not the other. But the concepts are different even though they're similar, and there's no plan to merge them together.

Build Types configure the packaging of our app:

• shrinkResources
• proguardFile
• etc.

Product Flavors configure different classes and resources:

• in Flavor1 your MainActivity can do something, while in Flavor2 it can have a different implementation
• different app name
• etc.

Each product flavor can have its own values of the following properties, among others, which are based on the same properties from defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Here's how I distill the difference down to its essence:

• buildType is the how of the build.
• flavor is the what of the build.