We are approaching an important phase of our project--defining build variants for our application. Build variant stands for a unique version of an Android application.

They are unique because they override some of the application attributes or resources.

Each build variant is configured per module level.

Let's extend our build.gradle! Put the following code in the android section of the build.gradle file:

    android { 
      ... 
      buildTypes { 
        debug { 
          applicationIdSuffix ".dev" 
        } 
        staging { 
          debuggable true 
          applicationIdSuffix ".sta" 
        } 
        preproduction { 
          applicationIdSuffix ".pre" 
        } 
           release {} 
        } 
       ... 
    }  

We defined the following buildTypes for our application--debug, release, staging, and preproduction.

Product flavors are created in a similar way like buildTypes. You need to add them to productFlavors and configure the needed settings. The following code snippet demonstrates this:

    android { 
      ... 
      defaultConfig {...} 
      buildTypes {...} 
      productFlavors { 
        demo { 
          applicationIdSuffix ".demo" 
          versionNameSuffix "-demo" 
        } 
        complete { 
          applicationIdSuffix ".complete" 
          versionNameSuffix "-complete" 
        } 
        special { 
          applicationIdSuffix ".special" 
          versionNameSuffix "-special" 
        } 
       } 
    } 

After you create and configure your productFlavors, click on Sync Now in the notification bar.

You need to wait a while for the process to be done. Names for Build Variants are formed by the <product-flavor><Build-Type> convention. Here are some examples:

    demoDebug 
    demoRelease 
    completeDebug 
    completeRelease 

You can change the build variant to the one that you want to build and run. Go to Build, select Build Variant, and select completeDebug from the drop-down menu.

The Main/source set is shared between all build variants in your application. If you need to create a new source set, you can do that for certain build types, product flavors, and their combinations.

All source set files and directories must be organized in a specific way, similar to the Main/Source set. Kotlin class files that are specific to your debug build type must be located in src/debug/kotlin/directory.

In order to learn how to organize your files, open the terminal window (View | ToolWindows | Terminal) and execute the following command line:

./gradlew sourceSets

Take a look at the output carefully. The report is understandable and self-explanatory. Android Studio doesn't create the sourceSets directories. It's a work that has to be done by you.

If desired, you can change the location where Gradle is looking for a source set using the sourceSets block. Let's update our build configuration. We will update the following expected source code paths:

    android { 
      ... 
      sourceSets { 
       main { 
       java.srcDirs = [ 
                'src/main/kotlin', 
                'src/common/kotlin', 
                'src/debug/kotlin', 
                'src/release/kotlin', 
                'src/staging/kotlin', 
                'src/preproduction/kotlin', 
                'src/debug/java', 
                'src/release/java', 
                'src/staging/java', 
                'src/preproduction/java', 
                'src/androidTest/java', 
                'src/androidTest/kotlin' 
        ] 
        ... 
     } 

Code and resources that you want packaged only with certain configurations, you can store in the sourceSets directories. Here are given examples for build with the demoDebug build variant; this build variant is a product of a demo product flavor and debug build type. In Gradle, the following priority is given to them:

    src/demoDebug/ (build variant source set) 
    src/debug/ (build type source set) 
    src/demo/ (product flavor source set) 
    src/main/ (main source set) 

This is the priority order that Gradle uses during the build process and considers it when applying the following build rules:

The lowest priority is given to resources and manifests included with library module dependencies.