Android APK 多渠道打包方案：别一上来就堆 Flavor

很多人一听“多渠道打包”，第一反应就是：productFlavors。

这个想法不能说错，但也不能说全对。实际项目里，多渠道打包要先看一个问题：不同渠道到底有没有代码差异？

如果华为包要接 HMS，小米包要接小米推送，Google Play 包要走另外一套支付或统计，那用 Flavor 很合理。可如果只是想知道用户从“华为应用市场 / 小米应用商店 / 应用宝 / 官网”哪个地方装进来的，那每个渠道都重新编译一次，就有点笨重了。

多渠道打包的核心不是“打很多包”，而是把这几件事管清楚：

• 这个 APK 是哪个渠道的。

• 这个 APK 用的是哪个版本、哪个 Git 提交。

• 这个 APK 签名有没有被破坏。

• 这个 APK 能不能安装。

• App 启动后能不能读到正确的渠道号。

• 线上出问题时，能不能反查到构建记录和 mapping 文件。

说白了，多渠道打包更像发布工程，不只是 Gradle 配置。

1. 多渠道包到底解决什么问题？

国内 Android 和 Google Play 的生态不一样。

Google Play 里，很多分发、设备适配、安装来源统计都可以依赖 Play Console。国内就复杂多了：华为、小米、OPPO、vivo、荣耀、应用宝、百度、官网、企业内部分发、推广落地页，入口非常多。

如果所有地方都上传同一个 APK，服务端和数据平台就很难判断用户到底从哪里来的。

所以多渠道包通常用来做这些事：

这里要注意一点：渠道号不是包名。

正常情况下，华为包、小米包、官网包应该还是同一个 applicationId。不要为了区分渠道，把包名改成下面这样：

com.example.app.huawei
com.example.app.xiaomi
com.example.app.yingyongbao

除非你真的想把它们当成不同 App 发布，否则这会把升级、推送、登录、支付、数据迁移全搞复杂。

2. 三种方案先放一起看

多渠道打包一般可以分成三类。

我更推荐用下面这个判断方式：

• 渠道之间有 SDK、资源、代码、权限差异：用 Product Flavor。

• 渠道之间只有渠道号不同：用基础包 + 写渠道号。

• 发 Google Play：优先考虑 AAB。

• 国内应用市场：大多数情况下还是 APK 更现实。

3. 方案一：Product Flavor，适合“真有差异”的渠道

Android 官方构建体系本身就支持 build type 和 product flavor。官方文档里也说明，Gradle 会把 build type 和 product flavor 组合成不同的 build variant，比如 huaweiRelease、xiaomiRelease、officialDebug。

典型配置大概是这样：

android {
    namespace = "com.example.app"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 23
        targetSdk = 36
        versionCode = 100
        versionName = "1.0.0"
    }

    flavorDimensions += "channel"

    productFlavors {
        create("official") {
            dimension = "channel"
            manifestPlaceholders["APP_CHANNEL"] = "official"
        }

        create("huawei") {
            dimension = "channel"
            manifestPlaceholders["APP_CHANNEL"] = "huawei"
        }

        create("xiaomi") {
            dimension = "channel"
            manifestPlaceholders["APP_CHANNEL"] = "xiaomi"
        }
    }
}

然后在 AndroidManifest.xml 里写入：

<meta-data
    android:name="APP_CHANNEL"
    android:value="${APP_CHANNEL}" />

读取渠道号：

object ChannelUtils {

    fun getChannel(context: Context): String {
        return try {
            val appInfo = context.packageManager.getApplicationInfo(
                context.packageName,
                PackageManager.GET_META_DATA
            )
            appInfo.metaData?.getString("APP_CHANNEL") ?: "unknown"
        } catch (e: Exception) {
            "unknown"
        }
    }
}

打包命令：

./gradlew assembleHuaweiRelease
./gradlew assembleXiaomiRelease
./gradlew assembleOfficialRelease

或者一次性打出所有 release 变体：

./gradlew assembleRelease

Product Flavor 的优点

• 官方构建体系支持，稳定性好。

• 可以区分代码、资源、Manifest、依赖、签名配置。

• 很适合“渠道之间确实不一样”的项目。

• IDE 里可以直接切换 build variant，开发调试比较直观。

Product Flavor 的问题

问题也很明显：慢。

假设你有 50 个渠道，如果每个渠道都走完整的编译、混淆、打包、签名流程，CI 时间会变得很难看。

所以它不适合这种场景：

渠道有几十个，但所有代码完全一样，只是 channel 不同。

这种情况下，用 Flavor 也能做，但不是最舒服的做法。

4. 方案二：基础包 + 快速写渠道号，更适合国内多市场

很多国内项目更常见的做法是：只编译一次，先生成一个 release 基础包，然后再往 APK 里写渠道信息。

流程大概是：

1. CI 先执行 assembleRelease，生成一个基础 APK。

2. 渠道工具读取 channel.txt。

3. 基于基础 APK 批量生成 huawei、xiaomi、oppo、vivo、yingyongbao 等渠道包。

4. 每个包都做签名校验和渠道号读取校验。

5. 最后归档或上传测试平台 / 应用市场。

这种方案的代表工具有美团 Walle、腾讯 VasDolly。

Walle 的思路是在 APK Signature Block 区块里写入自定义渠道信息，用来提高渠道包生成效率。VasDolly 也属于快速多渠道打包工具，并且说明支持基于 V1、V2、V3 签名进行多渠道打包。

为什么这种方式快？

因为它不重复编译。

传统 Flavor 方案像这样：

源码 -> 编译 -> 混淆 -> 打包 -> 签名 -> 华为包
源码 -> 编译 -> 混淆 -> 打包 -> 签名 -> 小米包
源码 -> 编译 -> 混淆 -> 打包 -> 签名 -> 应用宝包

快速渠道包方案像这样：

源码 -> 编译 -> 混淆 -> 打包 -> 签名 -> 基础包
基础包 -> 写 huawei -> 华为包
基础包 -> 写 xiaomi -> 小米包
基础包 -> 写 yingyongbao -> 应用宝包

渠道越多，这个优势越明显。

适合什么项目？

适合这种：

• 渠道很多。

• 渠道之间代码完全一样。

• 只是要统计安装来源。

• 应用市场包、官网包、推广包都要出。

• CI 不能接受几十个渠道重复编译。

不适合这种：

• 华为包要单独接 HMS。

• 小米包要单独接小米推送。

• Google Play 包要裁掉某些国内 SDK。

• 不同渠道权限、资源、依赖差异很大。

如果是后面这种，还是老老实实上 Flavor，或者把 Flavor 和快速渠道包混着用。

5. 签名问题要特别小心

Android APK 签名不是简单盖个章。

现代 APK 可能涉及 V1、V2、V3、V4 签名。官方 apksigner 文档也明确提醒：如果 APK 签名后又被修改，签名会失效。

所以不要自己随便解压 APK、塞一个文件进去、再压回去。很多人以前喜欢往 META-INF 或 zip comment 里写渠道号，这种老办法在现代签名方案下很容易踩坑。

渠道包生成之后，至少要跑一遍：

apksigner verify --verbose app-huawei-release.apk

如果还要看证书信息：

apksigner verify --print-certs app-huawei-release.apk

更稳一点的项目，还会加一个安装校验：

adb install -r app-huawei-release.apk

以及渠道号读取校验：

adb shell am instrument 或者启动一个测试入口读取 channel

别只看“文件生成了”，那不等于包是好的。

6. AAB 怎么看？

AAB，也就是 Android App Bundle，主要是 Google Play 生态里的发布格式。

官方文档里写得很清楚：从 2021 年 8 月开始，Google Play 新应用需要使用 Android App Bundle 发布。AAB 不是用户直接安装的 APK，而是包含应用编译代码和资源的发布格式，APK 的生成和签名会交给 Google Play。

所以它和国内多渠道 APK 不是一个层面的东西。

实际项目可以这么分：

不要指望 AAB 直接替代国内所有渠道包。国内很多市场、测试平台、企业分发流程，仍然是围绕 APK 走的。

7. 推荐的工程落地方案

我比较推荐这种组合方案。

7.1 buildType 负责环境

buildType 不要拿来做渠道，最好拿来区分构建环境。

比如 debug 包可以有日志、调试面板、测试域名；release 包则必须关掉调试能力，使用正式签名和正式配置。

7.2 flavor 负责真正的产品差异

flavor 不要无限膨胀。

可以这样设计：

如果只是华为、小米、OPPO、vivo 这些市场渠道，且代码没有差异，不一定要全部做成 flavor。

7.3 渠道工具负责批量市场包

国内市场包可以从 domesticRelease 或 officialRelease 基础包继续生成：

domesticRelease 基础包
  -> huawei
  -> xiaomi
  -> oppo
  -> vivo
  -> honor
  -> yingyongbao
  -> baidu
  -> website

这样既不会让 flavor 爆炸，也不会让 CI 慢到离谱。

8. 渠道号命名要统一

渠道号不要随便写。

推荐用英文小写，避免中文、空格、特殊符号。

不建议写成：

华为应用市场
小米渠道包
应用宝正式包
channel-01
渠道A

这些名字后期会在文件名、Shell 脚本、数据仓库、埋点平台里反复出现，越简单越不容易出事。

9. 渠道包文件名也要规范

不要让产物都叫 app-release.apk。

推荐格式：

AppName_版本名_版本号_渠道_构建日期.apk

比如：

DemoApp_1.0.0_100_huawei_20260708.apk
DemoApp_1.0.0_100_xiaomi_20260708.apk
DemoApp_1.0.0_100_yingyongbao_20260708.apk

再严谨一点，可以把 Git commit 也放进去：

DemoApp_1.0.0_100_huawei_a1b2c3d_20260708.apk

这样测试、发布、回滚都会舒服很多。

10. CI/CD 流程建议

一个比较稳的流水线可以这么跑：

1. 拉取代码，确认分支、Tag、commitId。

2. 检查 versionCode、versionName、changelog。

3. 执行单元测试、Lint、基础静态检查。

4. 构建 release 基础包。

5. 根据 channel 列表生成多渠道 APK。

6. 校验 APK 签名。

7. 安装校验。

8. 读取渠道号校验。

9. 归档 APK、mapping、构建日志。

10. 上传测试平台、对象存储或应用市场。

这里最容易被忽略的是第 6、7、8 步。

很多事故不是“打包失败”，而是：

• APK 生成了，但是签名坏了。

• APK 可以安装，但是渠道号读不到。

• 渠道号读到了，但是所有包都是 unknown。

• versionCode 没涨，应用市场拒绝上传。

• mapping 没归档，线上崩溃无法反混淆。

所以多渠道打包一定要把校验自动化，不要靠人工看文件名。

11. 常见坑

11.1 用 applicationId 区分渠道

这个坑很常见。

渠道不是应用身份。applicationId 才是 Android 安装和升级识别应用的核心标识。

如果每个渠道一个 applicationId，后果就是：

• 用户无法从一个渠道包平滑覆盖到另一个渠道包。

• 应用市场可能认为它们是不同 App。

• 推送、支付、登录、分享 SDK 配置都会变多。

• 后端统计也会被拆散。

除非你就是要发多个独立 App，否则别这么做。

11.2 盲目复制老 Gradle 脚本

很多老文章里会用 applicationVariants、variant.outputs.all 去改 APK 文件名或处理渠道。

这些脚本不一定适合新版本 AGP。Android 官方现在有专门的 AGP API deprecations and removals tracker，用来追踪 API 废弃和移除。项目升级 AGP 时，老脚本很容易爆。

新项目最好按当前 AGP 文档写，不要直接复制几年前的打包脚本。

11.3 渠道字段没有统一

客户端上报 huawei，服务端记成 Huawei，运营后台又写成 华为，数据平台最后再搞一个 hw。

这种情况一多，数据就会很乱。

建议一开始就定好枚举：

huawei
xiaomi
oppo
vivo
honor
yingyongbao
baidu
official
website
googleplay

客户端、服务端、BI、运营后台都用同一套。

11.4 只归档 APK，不归档 mapping

release 包混淆后，mapping 文件一定要和 APK 一起归档。

推荐归档结构：

release/1.0.0_100/
  apk/
    DemoApp_1.0.0_100_huawei.apk
    DemoApp_1.0.0_100_xiaomi.apk
  mapping/
    mapping.txt
  metadata/
    build-info.json
    channel-list.txt

线上崩溃追踪时，这些东西比 APK 本身还重要。

12. 最终建议

如果是一个常规国内 Android App，我会这样落地：

一句话总结：

少量、差异大的渠道，用 Flavor；大量、只是渠道号不同的渠道，用基础包快速写渠道；Google Play 走 AAB；国内市场仍然优先准备 APK。

多渠道打包不是越复杂越专业。真正舒服的方案应该是：一次构建、批量产物、自动校验、可追溯、可回滚。

参考资料

以下资料为本文方案整理时参考的主要来源，访问日期：2026-07-08。

1. Android Developers：Configure build variants
   https://developer.android.com/build/build-variants

2. Android Developers：About Android App Bundles
   https://developer.android.com/guide/app-bundle

3. Android Developers：apksigner
   https://developer.android.com/tools/apksigner

4. Android Developers：Android Gradle plugin API updates
   https://developer.android.com/build/releases/gradle-plugin-api-updates

5. Meituan-Dianping / Walle：Android Signature V2 Scheme 签名下的渠道包工具
   https://github.com/Meituan-Dianping/walle

6. Tencent / VasDolly：Android V1 / V2 / V3 Signature Channel Package Plugin
   https://github.com/Tencent/VasDolly