Gradle的Build Variant与多渠道打包

立泉

2020年06月12日

一个现实中的常见需求，同时也是我对国内混乱的Android生态最无语的需求：

为不同应用商店生成同一版本号的不同渠道包，包中需带有对应商店的标识符，以统计渠道分发数据。
不同应用商店的审核策略不同，App应根据渠道调整部分功能状态以满足合规要求。

即iOS开发中不存在的多渠道打包，解决方案是gradle的build variant，可以用Groovy语言在Module的build.gradle中配置不同打包类型的特有逻辑，以实现用同一份代码打出符合要求的不同包。

buildType与flavor

新建Module有release和debug2个默认buildType，可以在build.gradle中为它们配置不同的签名、applicationId、应用名和其它诸如是否开启混淆、定义不同Manifest占位符等。

debug测试，如果未指定签名配置，默认使用SDK自带的debug签名文件。可以adb安装，但不能在应用商店中发布。
release发布，没有默认签名配置。如果未指定签名，打包后就是未签名unsign状态，不可以被安装。

// Module的build.gradle

android {
    signingConfigs {
        // 定义一个签名配置，不同buildType可以使用不同签名
        mySign {
            storeFile file("../apqx.jks")
            storePassword "123456"
            keyAlias "apqx"
            keyPassword "123456"
        }
    }
    
    // 定义3个buildType
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            // 应定义release的签名文件
            signingConfig signingConfigs.mySign
        }
        debug {
            // applicationId加后缀
            // debug模式下生成同的applicationId，实现让正式版和测试版共存
            applicationIdSuffix = '.debug'
            // 应定义debug的签名文件
            signingConfig signingConfigs.mySign
        }
        share {
            // 继承release定义的属性，下面定义的属性将会覆盖已继承的属性
            initWith release
            // applicationId加后缀，使用与其它buildType不同的applicationId
            applicationIdSuffix = '.share'
            // 这个buildType是能以debug模式安装到设备上的
            debuggable true
        }
    }

sync之后在工程根目录执行./gradlew tasks，列表里只有一个assemble打包task：

./gradlew tasks

Build tasks
-----------
assemble - Assemble main outputs for all the variants.

执行./gradlew assemble，gradle会逐个打包3个buildType，默认输出路径为：

{project}/{module}/build/outputs/apk/{buildType}/{module}-{buildType}.apk

但其实gradle为每个buildType（准确的说是每一个build variant，后面会提到）都生成了单独的打包task：

./gradlew assembleRelease
./gradlew assembleDebug
./gradlew assembleShare

buildType更多的是面向release和debug这2个维度，buildType中再细分打包类型，就是flavor，准确的说，每一个flavor都具有所有定义的buildType。

这里以发布到小米应用商店的mi和发布到Google Play的play为例，它们是2个flavor，每个flavor都有release、debug和share3种buildType，其中发布到小米应用商店的App名为Mi，发布到Google Play的App名为Play：

// Module的build.gradle

android {
    signingConfigs {
        // 定义一个签名配置，不同的buildType可以使用不同的签名
        mySign {
            storeFile file("../apqx.jks")
            storePassword "123456"
            keyAlias "apqx"
            keyPassword "123456"
        }
    }
    compileSdkVersion 29
    buildToolsVersion "29.0.3"
    defaultConfig {
        applicationId "me.apqx.test"
        minSdkVersion 16
        targetSdkVersion 29
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"

        // 定一个Manifest占位符，AndroidManifest.xml文件中用它来作App名，默认为DEF
        // 不同的flavor定义不同的App名
        manifestPlaceholders APP_NAME: 'DEF'
    }

    // 定义包含flavor的Dimiension，可以定义不同的Dimiension各自包含多个flavor，但一般只需要定义一个即可
    flavorDimensions 'version'
    productflavors {
        // 发布到小米应用商店的flavor
        mi {
            // release生成目录为{project}/{module}/build/outputs/apk/mi/release/app-mi-release.apk
            // debug生成目录为{project}/{module}/build/outputs/apk/mi/debug/app-mi-debug.apk
            // share生成目录为{project}/{module}/build/outputs/apk/mi/share/app-mi-share.apk
            dimension = 'version'
            // 修改mi flavor下的应用名
            manifestPlaceholders APP_NAME: 'Mi'
        }
        // 发布到Google Play应用商店的flavor
        play {
            // release生成目录为{project}/{module}/build/outputs/apk/play/release/app-play-release.apk
            // debug生成目录为{project}/{module}/build/outputs/apk/play/debug/app-play-debug.apk
            // share生成目录为{project}/{module}/build/outputs/apk/play/share/app-play-share.apk
            dimension = 'version'
            // 修改play flavor下的应用名
            manifestPlaceholders APP_NAME: 'Play'
        }
    }
    
    // 定义3个buildType
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            // 应定义release的签名文件
            signingConfig signingConfigs.mySign
        }
        debug {
            // applicationId加后缀
            // debug模式下生成不一样的applicationId，实现让正式版和测试版共存
            applicationIdSuffix = '.debug'
            // 应定义debug的签名文件
            signingConfig signingConfigs.mySign
        }
        share {
            // 继承release定义的属性，下面定义的属性将会覆盖已继承的属性
            initWith release
            // applicationId加后缀，使用与其它buildType不一样的applicationId
            applicationIdSuffix = '.share'
            // 这个buildType是可以以debug模式安装到设备上的
            debuggable true
        }
    }

在AndroidManifest文件中使用flavor定义的Manifest占位符，以实现不同flavor定义不同App名：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="me.apqx.demo">
    <!-- 使用Manifest占位符，会自动替换为build.gradle中定义的字符 -->
    <application
        android:label="${APP_NAME}">
    </application>
</manifest>

sync后执行./gradlew tasks，出现了6个assemble打包task，但其实还有一些更细粒度的打包task没有显示出来。

./gradlew tasks

Build tasks
-----------
assemble - Assemble main outputs for all the variants.
assembleDebug - Assembles main outputs for all Debug variants.
assembleMi - Assembles main outputs for all Mi variants.
assemblePlay - Assembles main outputs for all Play variants.
assembleRelease - Assembles main outputs for all Release variants.
assembleShare - Assembles main outputs for all Share variants.

上面提到，mi和play都各自有release、debug和share3种buildType：

miRelease
miDebug
miShare
playRelease
playDebug
playShare

这些flavor和buildType的组合就是build variant，gradle会自动为每一个build variant生成打包task：

# 打包所有build variant
./gradlew assemble

# 打包含有release的2个build variant
./gradlew assembleRelease

# 打包含有mi的3个build variant
./gradlew assembleMi

# 打包mi的release组成的build variant
./gradlew assembleMiRelease

这些gradle task也可以在Android Studio的Gradle视图中找到，双击便可执行。

gradle task

自定义输出包目录

很多公司都有自己的打包服务器，打包时从svn或git仓库拉取代码，执行gradle打包指令，把格式化包名的包输出到指定目录下：

// Module的build.gradle

android {

    /**
     * 过滤指定的build variant，被过滤的variant将不会出现在打包系统里，即不会生成打包task
     */
    variantFilter { variant ->
        // variant名
        def names = variant.flavors*.name
        if (names.contains("mi")) {
            // gradle将会忽略符合条件的Variant
            setIgnore(true)
        }
    }

    // 默认的输出路径为 {project}/{module}/build/outputs/apk/{flavor}/{buildType}/{module}-{variant}-{buildType}.apk
    android.applicationVariants.all { variant ->
        // variant.name 为 {flavor}{buildType}，一般类似 miDebug
        // variant.versionName 为 版本号，一般类似 1.0.0
        // variant.flavors.name 为 flavor名，一般类似[mi]
        // variant.buildType.name 为 buildType名，一般为release或debug
        variant.outputs.all {
            // 定义输出的apk路径和名字
            def apkName = "demo"
            // 相对于默认的输出路径，向上跳2个层级，在apk目录下
            // 注意，这里不再允许使用相对于工程根目录的绝对路径
           outputFileName = "../../${variant.buildType.name}/${apkName}_${variant.name}_${variant.versionName}.apk"
        }
    }
}

多Module的build variant

如果主Module依赖一个或多个Library，主Module有多个build variant，Library也有多个build variant，那么当执行主Module的某个variant的assemble打包指令时，编译器会尝试从它所依赖的Library中寻找同样的flavor和buildType组成的variant。如果没有找到，则使用Library默认的variant。

在Android Studio的Build Variants视图中，可以修改每一个Module的默认build variant：

build variant