build variant = build type + product flavor

构建类型（Build Type）

默认情况下每个模块都有一个debug构建类型（debuggable属性默认为false）,可以在buildTypes代码块中覆盖

android {
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

创建新的构建类型时，可以使用另一个构建类型来初始化，staging和release版有不同的applicationId，可同时被安装

• Debug: com.package
• Release: com.package
• Staging: com.package.staging

android {
    buildTypes {
        staging.initWith(buildTypes.debug)
        staging {
            applicationIdSuffix ".staging"
            versionNameSuffix "-staging"
            buildConfigField "String", "API_URL", "\"http://staging.example.com/api\""
        }
    }
}

一个新的构建类型将有一个新的源集在和main的同级目录产生，同名的类在main源集和其他源集之间不能同时定义，同名的资源（含manifest）在main源集会被其他源集覆盖。
每个构建类型可以有不同的依赖

Product flavor

如果应用需要独立于已有的apk，那么就需要product flavors，它也会产生新的源集

android {
    productFlavors {
        red {
            applicationId 'com.gradleforandroid.red'
            versionCode 3
        }
        blue {
            applicationId 'com.gradleforandroid.blue'
            minSdkVersion 14
            versionCode 4
        }
    }
}

可以创建名称为flavor或者flavor+构建类型的源集，后者有更高的优先级
当定义多维度flavor时，会产生各维度flavor个数相乘再乘以build type个数的build variant，数维度数组的顺序决定了优先级从高到低，和源集的名称

android {
    flavorDimensions "color", "price"
    productFlavors {
        red {
            flavorDimension "color"
        }
        blue {
            flavorDimension "color"
        }
        free {
            flavorDimension "price"
        }
        paid {
            flavorDimension "price"
        }
    }
}

Build variant

资源和manifest的优先顺序为

资源和manifest的优先顺序.png

android {
   buildTypes {
       debug {
           buildConfigField "String", "API_URL",
                   "\"http://test.example.com/api\""
       }
       staging.initWith(android.buildTypes.debug)
       staging {
           buildConfigField "String", "API_URL",
                   "\"http://staging.example.com/api\""
           applicationIdSuffix ".staging"
       }
   }
   productFlavors {
       red {
           applicationId "com.gradleforandroid.red"
           resValue "color", "flavor_color", "#ff0000"
       }
       blue {
           applicationId "com.gradleforandroid.blue"
           resValue "color", "flavor_color", "#0000ff"
       }
   }
}

可以通过使用Variant filters加快构建，不会产生无需执行的任务污染

android.variantFilter { variant ->
    if(variant.buildType.name.equals('release')) {
        variant.getFlavors().each() { flavor ->
            if (flavor.name.equals('blue')) {
                variant.setIgnore(true);
            }
        }
    }
}

签名配置

应用发布时，使用不同的私钥为每个flavor签名

android {
    signingConfigs {
        staging.initWith(signingConfigs.debug)
        release {
            storeFile file("release.keystore")
            storePassword "secretpassword"
            keyAlias "gradleforandroid"
            keyPassword "secretpassword"
        }
    }
}

定义签名配置后，要将它应用到构建类型或flavor中

android {
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

android {
    productFlavors {
        blue {
            signingConfig signingConfigs.release
        }
    }
}

当为flavor分配一个配置时，实际上它会覆盖构建类型的签名配置，因此，应在使用flavor时，为每个构建类型的每个flavor分配不同的密钥

android {
    buildTypes {
        release {
            productFlavors.red.signingConfig signingConfigs.red
            productFlavors.blue.signingConfig signingConfigs.blue
        }
    }
}