CODEWITHSUNDEEP
androidandroid-gradle-pluginandroid-productflavors
sagar suri
sagar suri

Reputation: 4731

Product Flavors Configurations in Android

I am completely new to Product Flavors and I have gone through many links to understand it. But there are few doubts which are still not clear. I am having 3 product flavors i.e: qa, dev and prod. I have only created these three product flavors because I need to change the URLs and some API keys for different flavors which I have done by creating 3 different packages and placing the same java(having the URLs) file in the app/src directory. This is how my build.gradle. What are the mandatory things I need to add in each flavor? Something related to: proguard, signingConfigs:

android {
    useLibrary 'org.apache.http.legacy'
    compileSdkVersion 26
    buildToolsVersion '26.0.2'
    flavorDimensions "default"

    defaultConfig {
        applicationId "com.sagar.demo"
        minSdkVersion 21
        targetSdkVersion 25
        multiDexEnabled true
        versionCode 67
        versionName "1.0.0" //Update Version build number
        vectorDrawables.useSupportLibrary = true
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
        externalNativeBuild {
            cmake {
                cppFlags ""
            }
        }
    }

    signingConfigs {

        release {
            storeFile file("myKeystore")
            storePassword "Keystore2017"
            keyAlias "SagarSuri"
            keyPassword "Keystore2020"
        }
    }

    buildTypes {
        debug {
            debuggable true
            minifyEnabled false  // shrink
            useProguard false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        release {
            debuggable false
            minifyEnabled true
            useProguard true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }


    productFlavors {

        qa {
            dimension "default"

        }
        prod {
            dimension "default"
            signingConfig signingConfigs.release
        }
        dev {
            dimension "default"

        }
    }
}

Upvotes: 0

Views: 896

Answers (1)

ahasbini
ahasbini

Reputation: 6901

The way product flavors work is such that you'll end up with the number flavors in each dimension multiplied by the number of buildTypes, in your case you have 3 flavors in a single dimension and 2 build types which ends up with 3x2=6 build variants which are the following:

  • qaDebug
  • qaRelease
  • prodDebug
  • prodRelease
  • devDebug
  • devRelease

Each combination is an actual combination of the related product flavor config and the related build type config combined. Meaning for variant qaDebug, it's configuration are from the defined under qa and from the defined under debug combined. Hence if debug already defines the proguardFiles there's generally no need to define it in qa, unless if qa requires extra proguard configs for it's own code then that's a different matter that needs to be decided and hence proguard should be defined specific for each flavor and not in the build types.

Another aspect I'd like to point out is signingConfig which here is defined the same value for prod and release. This means that any combination that starts with prod or ends with Release will have the signingConfig set, which in this case are: qaRelease, prodDebug, prodRelease and devRelease.

Hence the configuration is really up to your choice and design, and not all projects will have the same config.

Upvotes: 1

Related Questions