TinkerPatch对Flavors及加固的支持

对Flavors的支持

如果只是多渠道的需求，建议不要使用Flavor。多flavor必须在后台建立相应的基线工程(如下例子的命名规则为：appVersion_flavorName)，每次生成补丁时也必须对应的生成多个分别上传。

TinkerPatch增加了tinkerPatchAllFlavorsDebug和tinkerPatchAllFlavorsRelease用于一次性生成所有flavors的Patch包。

如果只是多渠道的需求，建议不要使用flavor的方式。首先其打包很慢，其次需要维护多个基线包，后期维护成本也很大。Tinker官方推荐packer-ng-plugin或者walle来进行多渠道打包，其中walle是支持最新的SchemaV2签名的。

具体可以参照：tinkerpatch-flavors-sample

在TinkerPatchSupport中添加如下字段：

/** 
 * 若有编译多flavors需求，可在flavors中覆盖以下参数
 * 也可以直接通过tinkerPatchAllFlavorDebug/tinkerPatchAllFlavorRelease，一次编译所有的flavor补丁包
 * 注意的是：除非不同的flavor代码是不一样的，不然建议采用zip comment或者文件方式生成渠道信息
 **/
productFlavors {
    flavor {
        flavorName = "flavor1"
        // 后台需要按照每个flavor的appVersion来建立独立的工程，并单独下发补丁
        appVersion = "${tinkerpatchSupport.appVersion}_${flavorName}"

        pathPrefix = "${bakPath}/${baseInfo}/${flavorName}${buildType}/"
        name = "${project.name}-${flavorName}${buildType}"

        baseApkFile = "${pathPrefix}/${name}.apk"
        baseProguardMappingFile = "${pathPrefix}/${name}-mapping.txt"
        baseResourceRFile = "${pathPrefix}/${name}-R.txt"
    }

    flavor {
        flavorName = "flavor2"
        // 后台需要按照每个flavor的appVersion来建立独立的工程，并单独下发补丁
        appVersion = "${tinkerpatchSupport.appVersion}_${flavorName}"

        pathPrefix = "${bakPath}/${baseInfo}/${flavorName}${buildType}/"
        name = "${project.name}-${flavorName}${buildType}"

        baseApkFile = "${pathPrefix}/${name}.apk"
        baseProguardMappingFile = "${pathPrefix}/${name}-mapping.txt"
        baseResourceRFile = "${pathPrefix}/${name}-R.txt"
    }
}

对加固的支持

基本配置

这里默认有同时生成加固渠道与非加固渠道的需求，如果只是单一需要加固，可以直接在配置中开启protectedApp = true即可

可以参考tinkerpatch.gradle文件，具体工程可以参照tinkerpatch-flavors-sample

productFlavors {
    flavor {
        flavorName = "protect"
        appVersion = "${tinkerpatchSupport.appVersion}_${flavorName}"

        pathPrefix = "${bakPath}/${baseInfo}/${flavorName}-${variantName}/"
        name = "${project.name}-${flavorName}-${variantName}"

        baseApkFile = "${pathPrefix}/${name}.apk"
        baseProguardMappingFile = "${pathPrefix}/${name}-mapping.txt"
        baseResourceRFile = "${pathPrefix}/${name}-R.txt"

        /** 开启加固开关，上传此flavor的apk到加固网站进行加固 **/
        protectedApp = true
    }

    flavor {
        flavorName = "flavor1"
        appVersion = "${tinkerpatchSupport.appVersion}_${flavorName}"

        pathPrefix = "${bakPath}/${baseInfo}/${flavorName}-${variantName}/"
        name = "${project.name}-${flavorName}-${variantName}"

        baseApkFile = "${pathPrefix}/${name}.apk"
        baseProguardMappingFile = "${pathPrefix}/${name}-mapping.txt"
        baseResourceRFile = "${pathPrefix}/${name}-R.txt"
    }
}

加固步骤

• 生成开启protectedApp = true的基础包（这里假设此APK名为：protected.apk）
• 上传protected.apk到相应的加固网站进行加固，并发布应用市场(请遵循各个加固网站步骤，一般为下载加固包->重新签名->发布重签名加固包)
• 在tinkerPatch后台根据appVersion建立相应的App版本(比如这里2个flavor，就需要建立2个App版本。App版本即为各自flavor中配置的appVersion)
• 基于各个flavor的基础包（这里的基础包是第一步中生成的未加固的版本）生成相应patch包，并上传至相应的App版本中，即完成补丁发布

支持列表

这里是否支持加固，需要加固厂商明确以下两点：

• 不能提前导入类
• 在art平台若要编译oat文件，需要将内联取消