一、渠道标识先定死：它是契约，不是随手写的字符串

多渠道包的第一件事不是打开反编译工具，而是把渠道标识定下来。渠道标识是安装包出厂时带的一张“来源标签”，统计 SDK、运营后台、客服工单、结算系统都靠它对齐。它通常是一个短字符串，例如 official、store_oppo、partner_a。它不决定应用功能，除非你刻意按渠道做差异化；它也不等于包名，更不等于版本号。

建议先做一张渠道清单，把 id、显示名、包名策略、签名策略、负责人写清楚。表格比口头约定可靠，后面生成渠道包、验收、归档都照这张表执行。

渠道 id	显示名	包名策略	签名策略	用途
official	官网直发	不改包名	主产品密钥	官网下载页
store_oppo	OPPO 应用商店	不改包名	主产品密钥	应用商店上架
cust_a	客户 A 白牌	改为 com.example.neitool.a	客户 A 独立密钥	按客户交付

命名规则要一开始就定：全部小写 ASCII；以字母开头；只使用小写字母、数字、下划线或短横线；长度控制在 2 到 24 个字符；不要中文、空格、斜杠、点号；不要用纯数字；不要把日期塞进渠道 id；不要复用已经废弃的 id。日期属于构建记录，渠道 id 属于长期契约。

为什么强调“长期契约”？因为安装包一旦发到用户手机上，渠道值就可能被写进数据库、报表、结算单。后面再改 id，历史数据对不上，运营会以为渠道消失了。宁可在上线前多花十分钟定名，也不要在上线后改十次。

渠道 id 只增不改；显示名可以改，id 不能改。需要区分“环境”时，另建一套环境标识，不要把 test、prod 混进渠道值。

存法有三种常见路线：资源文件、配置文件、Manifest 元数据。三种都能用，差别在“谁来读、改哪里、风险在哪”。下面先给对比，后面每一步再展开。

存法	改哪里	读取方式	优点	风险
资源文件	res/values/channel.xml	getString 或 getIdentifier	简单，随资源一起编译	资源裁剪、文件放错目录
配置文件	assets/channel.properties	AssetManager 打开文件	集中，方便脚本替换	可被解包查看，容易漏打包
Manifest 元数据	AndroidManifest.xml	PackageManager 读取 meta-data	不改业务代码，系统 API 直接读	合并冲突、占位符漏替换

资源方式的优点是读取简单，代码里一个 getString 就拿到；缺点是资源可能被混淆、裁剪，改错文件名或放错目录会直接编译失败。配置文件方式的优点是渠道值集中、方便脚本批量替换，客户交付时也好解释；缺点是 assets 里的内容谁都能解开看，不能把它当安全边界。Manifest 元数据方式的优点是不用改 Java 或 Kotlin 代码，系统 API 直接读；缺点是 meta-data 必须写在 application 里面，写错位置不会报错，只会读不到。

还有一种更进阶的做法：把渠道信息写进 APK 签名块或 ZIP 附加区，由专门的渠道写入方案读取。它适合大规模分发，但手工改 APK 会破坏签名，必须整体重签，而且对工具链要求高。本文面向第一次做多渠道包的读者，不展开这条路；知道有这回事即可，初学阶段用前三种更稳。

不管选哪种，都要遵守一个原则：渠道值只在一个地方定义，其他位置引用它。最怕的是字符串资源里写 official、assets 里写 store、Manifest 里又是 partner_a，最后统计出来三个渠道都有量，谁也说不清。

最后提醒一句安全边界：渠道标识是客户端数据，用户或竞争对手都能改。如果渠道值涉及返利、结算、权限，必须让服务端结合账号、订单、签名校验做二次判断，不能只信客户端上报。本文讲的是工程打包，不是防作弊系统。

二、开工准备：环境、密钥、副本，一个都不能少

修改大师经典版运行在 Windows 上，环境要求是 ASP.Net 4.5+ 与 JDK 1.8+，安装包约 13.74 MB。它和智能修改电脑版可以同机安装，项目互不冲突，所以你不必卸载已有工具。安装路径、工作目录、项目路径都建议用纯英文，不要带中文、空格和特殊符号；这不是洁癖，而是避免命令行工具在解析路径时出现莫名其妙的失败。

先建一个干净的工作根目录，例如 D:\ApkWork，下面分五类：source 放原始 APK 和授权记录；project 放经典版反编译出来的工程；release 放各渠道成品；keys 放密钥库，只在本机保存，不进门禁同步盘；logs 放构建与验收记录。工作盘至少留出几 GB 空间，反编译、回编、对齐都会产生中间文件。

签名材料要提前准备。可以用 keytool 生成一个专用 release 密钥库，命令如下。密钥库文件名、别名、口令都记录到密码管理器，并做两份离线备份；不要用公开的调试密钥，也不要把密钥库提交到代码仓库。

keytool -genkeypair -v -keystore release.jks -alias release -keyalg RSA -keysize 2048 -validity 10000

为什么要强调“专用”？因为签名是应用的身份。同一款应用的所有渠道包必须用同一把密钥签名，否则后装的包无法覆盖先装的包，应用商店也会拒绝更新。给客户做的独立品牌包则相反，应该单独生成密钥，避免把主产品的签名密钥交给外部。

接着给原始包做一次“身份登记”：包名、versionName、versionCode、minSdk、targetSdk、签名证书摘要、文件 SHA-256。后面每生成一个渠道包，都拿这张登记表对照。可以用 aapt、apksigner 和系统自带的 certutil 或 PowerShell 的 Get-FileHash 完成。命令不必背，知道要记录哪些字段就行。

aapt dump badging app-release.apk
apksigner verify --print-certs app-release.apk
certutil -hashfile app-release.apk SHA256

如果原始 APK 是加固包，先确认它是不是自家产品、有没有授权。确认之后，可以用经典版的自动脱壳修复功能处理，再进入反编译。脱壳修复不是万能钥匙：有些壳会改 Dex、抽代码、加 native 校验，修复后要逐个功能点验证；如果修复后的包启动就崩，先回到原始包，检查壳版本和工具链，不要在半成品上继续改渠道。

经典版的文件管理工具在这里很有用：它能直接浏览项目目录，打开 smali、XML、assets 和日志，改完保存再回编，不用在资源管理器和编辑器之间来回切。日志、装机这些小工具也集中在同一处，排查“到底是反编译失败还是安装失败”会快很多。

看到什么算准备完成？打开经典版，能正常选择 APK；反编译窗口能显示包名、版本、文件树；日志区没有红色报错；工作目录可写；密钥库能被签名环节识别。任何一项不满足，都先停下来修环境，不要带着问题往下走。

怎么验证？做一次“原样回编”：不改任何文件，直接回编、对齐、用 release 密钥签名，然后装到测试机。如果能装上、能启动、版本号不变，说明工具链是通的。这个基线非常重要，后面出问题时可以立刻判断“是环境坏了”还是“我改坏了”。

失败怎么查？JDK 找不到，检查 JAVA_HOME 是否指向 JDK 1.8 而不是 JRE；反编译报框架错误，检查是否用了与目标系统匹配的 framework；回编报资源不存在，检查文件是否放错目录、文件名大小写是否一致；签名报别名或口令错误，检查 keystore 路径、alias、口令是否用了全角字符；安装报解析失败，先确认包是否对齐、是否真的签上了。

三、反编译：先看完整，再做“空回编”基线

把原始 APK 导入经典版，选择反编译。工具会把 APK 拆成可读工程：AndroidManifest.xml 变成可编辑的文本，resources.arsc 解码成 res 目录，dex 变成 smali 目录，assets、lib、META-INF 原样保留。你会看到 smali、smali_classes2 这类分 Dex 的目录，res/values 下的字符串与颜色，res/layout 下的界面，以及 apktool.yml 里的版本信息。

先不要急着改渠道值。第一轮只做检查：Manifest 能不能正常打开；res/values 里的字符串有没有乱码；assets 里的配置文件在不在；lib 下的 so 是否完整；日志里有没有“Could not decode”“resource not found”这类错误。少量 9-patch 警告有时是工具的标准兜底，不代表回编一定失败，但要在空回编时确认。

空回编的意思是不改任何文件，直接回编。回编成功后做对齐和签名，再安装。这个动作看起来多余，实际上是整个流程的地基：它把“工具链问题”和“修改问题”分开。很多人一上来就改渠道、改包名，失败后不知道是哪一步坏的，最后把工程改得面目全非。

空回编通过的标准：生成的 APK 能安装；启动页正常；包名、版本号与原始包一致；主要页面能打开；logcat 没有立刻出现 FATAL EXCEPTION。若原包有加固或签名校验，空回编后可能启动失败，这时要先处理壳与校验，而不是继续改渠道。

看到什么算反编译完整？文件树里能同时看到 AndroidManifest.xml、res、smali、assets、lib；Manifest 的 application 节点可读；资源 ID 能对应到具体文件；apktool.yml 记录了 minSdk、targetSdk、versionCode、versionName。缺任何一项，都可能是反编译不完整。

失败怎么查？框架版本不匹配，换用设备对应的 framework 或用工具自带的框架目录；路径含中文或空格，换纯英文短路径；磁盘空间不足，清理中间文件；JDK 版本不对，切回 JDK 1.8；项目目录被安全软件锁定，加白名单或换目录；上一次构建残留导致冲突，删掉 build 目录重来。每次只改一个变量，才能定位。

反编译完成后，先复制一份工程作为 baseline，后面所有修改都在副本上做。这样即使改崩了，也能回到“已知能回编”的状态，不用重新解包。这个习惯在多渠道场景里尤其重要，因为你要反复改同一个位置。

四、改渠道值：资源、配置、Manifest 三条路逐一落地

下面三种做法都按“做什么、看到什么、怎么验证、失败怎么查”来写。你可以只选一种，但建议在项目里统一，不要这个渠道用资源、那个渠道用 assets。统一之后，脚本、检查清单、验收步骤都能复用。

方案 A：资源文件 res/values/channel.xml

做什么：在 res/values 下新建 channel.xml，写入一个字符串资源。文件名可以叫 channel.xml，不要和已有资源重名；字符串名建议固定为 channel_id。值改成目标渠道，例如 official。注意不是每个应用都有现成的渠道读取代码，如果代码里根本没有读这个资源，单加一个 XML 不会自动生效，这一点后面会讲。

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="channel_id">official</string>
</resources>

如果应用代码里已经有读取逻辑，例如 getString(R.string.channel_id)，改完这个值就够了。若代码用的是 getIdentifier("channel_id", "string", getPackageName())，要确认资源名没有被混淆工具改掉；自家应用如果在 release 构建里开了资源裁剪，记得把该资源加入保留规则。没有读取逻辑时，优先选方案 C 的 Manifest 元数据，或者让开发先在源码里加读取入口，再回来改值。

看到什么：文件树 res/values 下出现 channel.xml；编辑器里 XML 标签闭合正常；搜索 channel_id 能找到定义处和引用处；值没有多余空格和换行。

怎么验证：回编后先不签名，用 aapt2 dump resources 或解包工具查看字符串值；安装后打开“关于”页或触发一次渠道读取日志，确认显示 official。若应用没有展示入口，就临时在启动日志里打印一次，验证完再关掉。

失败怎么查：回编报 resource not found，检查文件是否放在 res/values 而不是 res/layout；报 duplicate resource，检查是否已有同名 string；安装后读到旧值，检查是否有多个 channel.xml 或 values-xx 语言目录覆盖；读到空值，检查 XML 是否有 BOM、是否用了全角引号。

方案 B：assets 配置文件

做什么：在 assets 下放一个 channel.properties，写 channel=official。用 properties 而不是 JSON，是因为解析简单、对新手友好；如果团队已有 JSON 配置，也可以沿用，但格式要固定，不要一个渠道一个格式。

channel=official
channel_name=官网直发
build_time=2026-10-21

读取侧通常用 AssetManager.open("channel.properties")，逐行按等号切分。注意文件编码用 UTF-8 无 BOM；值不要带引号；行尾不要有多余空格；渠道名可以写中文，但渠道 id 必须保持 ASCII 小写。下面是一段最小读取逻辑，放在 Application 或启动页都可以。

Properties p = new Properties();
p.load(getAssets().open("channel.properties"));
String channel = p.getProperty("channel", "unknown");

看到什么：assets 目录下出现 channel.properties；文件大小不为 0；用文本编辑器打开能看到三行键值；打包后的 APK 里 assets/channel.properties 仍然存在。

怎么验证：回编后解压 APK，确认 assets 里的文件在；安装后读取并显示渠道值；如果是客户交付包，还要确认客户名称与配置文件一致。最好在“关于”页显示渠道 id 和构建时间，售后一眼就能核对。

失败怎么查：APK 里没有 assets 文件，检查是否放到了项目根目录而不是 app 模块的 assets；读取抛 FileNotFoundException，检查文件名大小写；读到乱码，检查 BOM 和编码；值后面带空格，检查编辑器是否自动补了空格；多渠道串值，检查是否只改了一个 assets 而另一个在 res/raw 里。

方案 C：AndroidManifest.xml 的 meta-data

做什么：在 application 节点内加一条 meta-data，name 用带包名前缀的自定义键，value 写渠道 id。带前缀是为了避免和第三方 SDK 的键冲突。meta-data 必须放在 application 里面，放在外面不会报错，但读取时一定拿不到。

<application ...>
    <meta-data
        android:name="com.example.app.CHANNEL_ID"
        android:value="official" />
</application>

读取侧用 PackageManager 拿 ApplicationInfo，再读 metaData。这个方式的好处是渠道值跟着 Manifest 走，不需要额外资源文件；坏处是 Manifest 是 XML，手改容易漏掉闭合标签，而且导出到 Android Studio 后要被 manifestPlaceholders 接管，否则每个渠道都要手改一次。

ApplicationInfo ai = getPackageManager()
    .getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA);
String channel = ai.metaData.getString("com.example.app.CHANNEL_ID", "unknown");

看到什么：meta-data 位于 application 内部，缩进正确；name 与代码里的读取键完全一致；value 是纯 ASCII；回编后的 AndroidManifest.xml 里仍能看到这条记录。

怎么验证：用 aapt dump xmltree 查看 APK 的 Manifest，确认 meta-data 的值；安装后读取并显示；如果走 Gradle 渠道，确认占位符已经被替换成具体值，而不是留下 ${channel} 字样。

失败怎么查：读不到值，检查 meta-data 是否写在了 application 外面；读到 null，检查键名大小写；值变成占位符，检查构建配置是否传了 channel；Manifest 合并冲突，检查是否有多个模块定义了同名 meta-data；安装解析失败，检查 XML 是否合法。

三种方案怎么选？给一张对照表。选择的核心不是“哪个高级”，而是“你的应用现在怎么读渠道、以后谁来维护”。

方案	适用场景	是否要改代码	批量替换难度	防篡改
资源文件	应用已有渠道资源读取逻辑	通常不需要	低，改一个 XML	弱，可被重打包
assets 配置	客户交付、多环境配置、脚本化生产	需要已有读取逻辑	低，替换文件即可	弱，明文可读
Manifest 元数据	不想动业务代码、渠道数量多	需要一次读取封装	中，注意 XML 结构	弱，可被改但需重签

不管选哪种，改完都要做一次“全局搜索旧值”。渠道值往往不止一处：字符串、assets、Manifest、统计初始化代码、客服配置。搜索旧渠道名，确认没有残留；再搜索新渠道名，确认只出现在预期位置。这个动作能避免“包是新的，统计还是旧的”。

还有一个常见坑：值改了，但读取代码有缓存。比如首次启动把渠道写进 SharedPreferences，后面一直读缓存。验证时要清数据或重装，不能只覆盖安装。若业务确实需要缓存，升级逻辑里要处理“渠道变化”的情况，否则老用户永远停留在旧渠道。

对比一下智能修改安卓版：它把反编译、改值、回编、对齐、签名收进一条自动流程，适合“先快速看到一个能装的包”；经典版则把每个文件、每个值都摊开给你看，适合“我要确认渠道值到底写进了哪个文件”。两条路线都合法，选你能掌控的那条。

五、包名要不要改：先看影响面，再决定动不动

包名是 Android 应用的身份证。它决定应用在系统里的唯一性，也决定升级、推送、登录、支付、深链、应用商店记录归谁。很多新手把“改渠道”和“改包名”混为一谈，结果同一款应用出了两个包名，老用户收不到更新，后台数据也合不到一起。

做什么：先做判断，而不是先动手。把本次出包的目的写清楚：是同一产品的渠道分发，还是独立品牌交付，还是并行测试。只要答案里出现“同一产品要统一升级”，包名就不该动；只要出现“客户要求独立上架、独立品牌、数据隔离”，才进入改包名流程。

结论先给：同一款应用的多渠道包，不改包名；只有做独立品牌、白牌交付、并行测试、彻底分叉时，才考虑改包名。渠道差异用渠道标识表达，不要用包名表达。

影响面	改包名后的结果	你要做的补救
覆盖升级	变成新应用，旧包收不到更新	重新上架、重新引导用户安装
应用数据	私有目录按包名隔离，旧数据读不到	做迁移或明确告知不迁移
厂商推送	包名和签名变了，通道要重新注册	在各推送平台新建应用并更新配置
第三方登录	微信、QQ 等按包名加签名校验，登录失败	更新开放平台包名、签名、回调
支付与地图	商户配置、Key 绑定包名和证书，调起失败	重新签约或重新申请 Key
深链与 App Links	旧链接可能全部失效	保留旧 scheme 或做跳转兼容
ContentProvider	authority 若写死旧包名，两个包同装会冲突	改成随包名变化或使用唯一 authority

逐项解释。升级方面，Android 只允许同包名、同签名、versionCode 不低于已安装版本的 APK 覆盖安装。改了包名就是新应用，旧应用不会自动更新，用户数据也不共享。推送方面，厂商推送通道按包名和签名注册，包名一换，推送平台上的应用记录、证书、通道都要重新配置；没配好就是“装上了但收不到”。登录方面，微信、QQ 等开放平台按包名加签名校验回调；换包名不更新平台配置，登录会直接失败。Google 登录按包名加证书摘要登记，同理。

支付方面，支付宝、微信支付商户配置绑定包名与签名，换包名要重新签约或改配置，否则调起失败。地图与第三方 Key 方面，高德、百度等 Key 绑定包名和证书摘要，换包名要重新申请。深链方面，scheme、host 与包名、签名有关，App Links 还要做域名校验；换包名可能让旧链接全部失效。应用商店方面，新包名就是新应用，要重新上架、重新积累评价，老用户不会收到更新提示。

所以，渠道包的正确做法是：包名不动，签名不动，只动渠道标识和 versionCode（如果需要发新版）。这样官网包、商店包、合作方包可以互相覆盖升级，后台也能按渠道聚合。

什么场景应该改包名？给一张判断表。

场景	是否改包名	原因
同一产品发多个渠道	不改	要统一升级、统一数据、统一签名
应用商店与官网并存	不改	用户可能从不同入口安装，仍要能覆盖
白牌交付给客户	改	客户要独立品牌、独立上架、数据隔离
测试版与正式版并存	可加后缀	方便同机对比，但测试包不要上架
签名冲突	不改	应先找回原密钥，改包名等于丢掉老用户

如果决定改，清单如下：AndroidManifest.xml 的 package；导出 Gradle 后的 applicationId；ContentProvider 的 authorities；自定义 permission 名称；deep link 的 scheme 与 host；第三方 SDK 的包名配置；推送注册；支付与登录平台；地图 Key；统计与归因；assets 里的客户配置；应用名与图标；签名策略。改完用全局搜索旧包名，逐条确认。

特别提醒：不要为了“绕过签名冲突”去改包名。同包名不同签名确实装不上，但正确做法是找回原签名密钥，而不是换包名把老用户甩掉。换包名只会让问题从“装不上”变成“用户全丢了”。

看到什么：改包名成功后，桌面会出现两个不同图标；系统设置里能看到两个应用条目；adb shell pm list packages 能同时列出新旧包名；旧包的数据目录不会被新包读取。看到这些现象，说明你确实做了一次“新应用”，而不是一次普通升级。

怎么验证：同时安装新旧包，确认互不覆盖；分别登录，确认账号体系符合预期；分别触发推送、支付、深链，确认配置指向正确；用 apksigner 对比两个包的签名，确认是独立密钥还是同一密钥，并把策略写进交付文档。

失败怎么查：安装报 authority 冲突，检查 ContentProvider；登录回调失败，检查开放平台包名与签名；推送收不到，检查厂商后台；支付调不起，检查商户配置；深链打不开，检查 scheme 与 host；升级失败，确认是不是包名根本没改成功。每个失败都对应一个身份配置，不要只盯代码。

六、回编、对齐、签名：顺序错了，前面全白做

渠道值改完，进入构建链。经典版会把反编译、回编、对齐、签名串起来，但你要知道每一步在做什么，出问题时才能定位。标准顺序是：回编生成 unsigned APK，zipalign 对齐，apksigner 签名，apksigner verify 校验。顺序不能反，尤其是“先对齐再签名”，因为 v2、v3 签名会覆盖整个文件，签名后再对齐会破坏签名。

做什么：先回编，再对齐，再签名，最后校验。整条链路只有四步，顺序固定，不要跳步。

1. 回编：把工程重新打包成 unsigned APK，先确认资源与 smali 都能编译通过。
2. 对齐：用 zipalign 做 4 字节对齐，含 so 时加 -p。
3. 签名：用 apksigner 和固定密钥库签名，开启 v1、v2、v3。
4. 校验：用 verify 确认签名方案和证书摘要，再安装。

回编命令大致如下，路径按你的工程替换。经典版内部也是同样的链路，只是把命令封装成了按钮和日志。

apktool b project -f -o build\unsigned.apk
zipalign -f -p 4 build\unsigned.apk build\aligned.apk
apksigner sign --ks keys\release.jks --ks-key-alias release ^
  --ks-pass env:KS_PASS --key-pass env:KEY_PASS ^
  --out build\signed.apk build\aligned.apk
apksigner verify --print-certs --verbose build\signed.apk

zipalign 的 4 是 4 字节对齐；-p 让 so 按页对齐，含 native 库的包不要省。对齐失败通常说明 APK 里有异常条目或路径过长，先看日志里的具体文件名。

签名要开 v1、v2、v3。v1 是 JAR 签名，老系统需要；v2 是 APK Signature Scheme v2，Android 7 以后主流；v3 支持密钥轮换，现代工具默认会带上。v4 是单独的 .idsig 文件，主要用于增量安装，分发时不一定需要。给普通用户安装的包，v1 加 v2 加 v3 足够覆盖大多数设备。

口令不要写进命令行历史，也不要用明文脚本。用环境变量传入，构建完清掉；日志里不要打印口令。密钥库和别名写进团队密码库，离职交接时只交使用权，不扩散副本。

看到什么：apksigner verify 输出 Verifies，并且 v1、v2、v3 对应行为 true；--print-certs 输出证书 DN 和 SHA-256 摘要；安装时系统不再提示“未签名”或“签名不一致”。经典版的打包日志里，回编、对齐、签名、校验四段都有明确输出，最后一行没有报错。

怎么验证：把每个渠道包的 verify 输出保存下来，比较证书 SHA-256。同一款应用的所有渠道包必须完全一致；给客户的独立包可以不同，但要在交付文档里写清楚，避免客户拿两个不同签名的同包名 APK 互相覆盖。再补一次覆盖安装测试：旧版装好，新版直接装，不卸载，能成功才算真通过。

失败怎么查：INSTALL_PARSE_FAILED_NO_CERTIFICATES 说明没签上或签名被破坏；INSTALL_FAILED_UPDATE_INCOMPATIBLE 说明签名与已安装版本不一致，或 versionCode 降低；INSTALL_FAILED_INVALID_APK 多半是对齐或 ZIP 结构问题；apksigner 报 v2 缺失，检查是否在签名后又改了文件；报别名不存在，检查 keystore 里的 alias 大小写。每次失败只回退一步，不要同时换工具、换密钥、换包名。

现象	常见原因	处理顺序
回编失败	资源缺失、XML 不合法、框架不匹配	看日志第一条错误，回到对应文件
对齐失败	ZIP 条目异常、路径过长、文件损坏	重新回编，检查异常文件名
签名失败	密钥路径、别名、口令、格式错误	先用 keytool 列出别名，再重签
校验失败	签名后改过文件、v2 未开启	重新对齐、重新签名，不再改包
安装被拒	签名不一致、版本降低、包损坏	先 verify，再查 versionCode

经典版的打包日志会把每一步的输出留下来。出问题时先看日志最后三十行，通常能看到具体失败的命令和文件；不要只看弹窗的“失败”两个字。日志、文件管理、装机工具配合使用，定位会快很多。

七、命名与归档：让每个包都能被追溯

多渠道包最容易乱的时刻，不是构建失败，而是“桌面上有五个 apk，不知道哪个是哪个”。命名规则要在第一次生成渠道包前定好，并且机器可读。推荐格式：应用名-versionName-versionCode-渠道 id-构建日期-构建类型.apk，全部小写 ASCII，用短横线分隔，不用空格和中文。

做什么：先定文件名模板，再定目录结构，最后定归档清单。文件名示例：jizhang-3.8.2-382-official-20261021-release.apk；jizhang-3.8.2-382-store_oppo-20261021-release.apk；neitool-1.4.0-140-cust_a-20261021-release.apk。版本号在前，渠道在中，日期在后，排序时天然按版本聚合。

目录也按版本分层：release/3.8.2/382/official/ 放成品；同级的 unsigned、aligned 放中间产物；logs 放构建日志；docs 放渠道清单和验收记录。一个版本一个目录，发布后只读，不再覆盖。需要重出时新建日期子目录，保留旧包，方便回滚和对比。下面的结构可以直接照抄。

release/
  3.8.2/
    382/
      official/
        jizhang-3.8.2-382-official-20261021-release.apk
        jizhang-3.8.2-382-official-20261021-release.apk.sha256
      store_oppo/
        jizhang-3.8.2-382-store_oppo-20261021-release.apk
      unsigned/
      aligned/
      logs/
      docs/
        channel-list.csv
        acceptance.md

归档清单至少包含：文件名、包名、versionName、versionCode、渠道 id、签名证书 SHA-256、文件 SHA-256、构建时间、构建人、验收人、验收结论。用 CSV 或表格维护，和 APK 放在同一目录。别只靠聊天记录，三个月后没人记得哪个包发过哪个渠道。

字段	示例	为什么必须记
文件名	jizhang-3.8.2-382-official-20261021-release.apk	定位成品，避免“最终版”满天飞
包名与版本	com.example.jizhang / 3.8.2 / 382	确认升级链和商店记录
渠道 id	official	对后台报表和结算
签名摘要	证书 SHA-256 前八位	确认能否覆盖升级
文件摘要	APK 的 SHA-256	防止传输损坏和版本混淆
验收结论	通过 / 有问题 / 回滚	出了问题能追溯责任人

命名还有几个禁忌：不要用 final、new、copy、(1) 这类词；不要用“最新”“最终版”这种会过期的描述；不要把渠道 id 写成中文；不要在文件名里放空格；不要用两个日期格式混排。文件名是给人和脚本一起看的，越朴素越可靠。

归档前按下面的检查清单逐项打勾，七项都通过再进入验收：

• □ 文件名符合模板，渠道 id 与清单一致
• □ 包名、versionName、versionCode 与登记表一致
• □ 文件 SHA-256 已记录，抽样复算一致
• □ 签名摘要与同产品基线一致
• □ 同版本只保留一个最终包，旧包可回滚
• □ 渠道清单、验收记录、构建日志齐全
• □ 客户交付文档不含密钥、账号等敏感信息

看到什么：打开 release 目录，能按版本、渠道、日期一眼找到包；每个包旁边都有摘要文件；归档表里的文件名与实际文件一一对应；同一版本不会出现两个“最终版”。看到这种秩序，说明归档规则生效了。

怎么验证：随机抽一个包，重新计算 SHA-256，和归档表比对；用 aapt 看包名与版本，和文件名比对；用 apksigner 看签名摘要，和归档表比对；再让同事只看文件名，说出这是哪个渠道、哪个版本，能答对就算命名合格。

失败怎么查：文件名和包内信息对不上，说明复制或改名时搞错了对象，回到构建日志找输出路径；摘要不一致，说明文件被重新签过或传输损坏；同一版本出现多个包，说明没有冻结目录；归档表缺字段，说明模板没执行。命名问题看似小事，真出问题时往往最难查。

八、逐渠道安装验收：能装不等于能发

渠道包不是“签完名就完事”。同一份代码，在不同渠道可能因为渠道值、包名、签名、后台配置不同，表现出完全不同的行为。验收要按渠道逐个做，不要只测一个包就全量发布。

做什么：先做静态检查，再做安装矩阵，再做功能核对，最后留验收记录。静态检查包括：aapt dump badging 看包名、版本、应用名、SDK；apksigner verify 看签名；解压看 assets 或资源里的渠道值；计算 SHA-256 与归档记录比对。静态检查能在安装前拦掉大部分低级错误。

安装矩阵要覆盖两类安装：全新安装和覆盖升级。每个渠道至少一台真机或一个模拟器；至少覆盖一个 Android 10 左右的旧设备和一台较新的设备；如果应用有推送，尽量覆盖目标厂商的机器。全新安装看首次启动、权限弹窗、引导页；覆盖升级看数据是否保留、登录态是否还在、versionCode 是否递增。

检查项	操作或命令	通过标准
包名与版本	aapt dump badging 或设置页查看	与归档表完全一致
签名	apksigner verify --print-certs	证书摘要与同产品其他渠道一致
渠道值	关于页、启动日志或解包查看	与目标渠道完全一致，没有旧值
覆盖升级	先装旧版，再 adb install -r 新版	数据保留、登录态正常、版本递增
启动与核心页	冷启动、后台恢复、主要页面	无闪退、无白屏、无 ANR
推送与登录	测试账号登录，发送测试推送	能登录、能收到、能点击跳转
支付与深链	沙箱支付、adb am start 打开链接	能调起、能回跳、参数正确
后台数据	测试环境查看渠道上报	渠道、版本、设备字段正确

渠道值怎么验？优先看应用内的“关于”页或调试日志；没有入口就临时加一条启动日志，验收完删掉。再看后台报表是否收到对应渠道的数据；如果后台有延迟，至少确认客户端上报参数正确。不要只看“报表有数”，因为缓存和默认值也会产生假数据。

签名怎么验？每个包都跑 apksigner verify --print-certs，比较 SHA-256。不要只验一个包就推断全部；批量生成渠道包时最容易出现“某一个包用了旧密钥”。把摘要写进验收表，谁签的、什么时候签的，一目了然。

升级怎么验？先装上一个正式版本，登录、产生一点数据，再用新渠道包覆盖安装。检查版本号、数据、登录态、推送 token 是否正常。若覆盖失败，先看签名是否一致，再看 versionCode 是否降低，最后看安装包是否损坏。不要用“卸载重装”掩盖升级问题，那会丢数据，也会让真实用户踩坑。

看到什么：测试机上应用能正常启动，关于页显示正确渠道；覆盖安装没有卸载提示；后台能查到对应渠道的测试上报；每个渠道的签名摘要一致；验收表逐项打勾。看到这些，才算“可以发”，而不是“能装”。

怎么验证：把上述检查做成一张矩阵表，每行一个渠道，每列一个检查项；通过打勾，不通过写原因；最后一个人复核。矩阵表比口头“我测过了”可靠，也方便下次发版复用。

失败怎么查：装不上，看 adb install 的完整报错；启动闪退，看 logcat -b crash；渠道值不对，解包看文件；推送收不到，看厂商平台包名与签名；登录失败，看开放平台配置；支付调不起，看商户配置与签名；深链打不开，用 adb am start 手动验证。每个问题都对应一个可检查的证据，不要靠猜。

九、导出 Android Studio 工程：把一次手动变成长期流水线

经典版支持导出 Android Studio 工程。这个功能的价值不只是“继续改代码”，而是把一次性的手动生成渠道包，固化成可重复的构建流程。导出后，你可以在 Gradle 里用 productFlavors 管理渠道，用 manifestPlaceholders 或 resValue 注入渠道值，用 signingConfigs 统一签名，后面出十个渠道也不用重复反编译。

做什么：在经典版里选择导出工程，指定输出目录；用 Android Studio 打开，等待 Gradle Sync；检查 build.gradle 里的 applicationId、versionCode、versionName、minSdk、targetSdk；检查 AndroidManifest.xml 里的渠道配置；检查 assets 和 res 是否完整；先跑一次 assembleDebug，确认能编译。

看到什么：Gradle Sync 没有红色错误；Build Variants 里能看到 debug 和 release；APK 能生成；安装后包名、版本、渠道值与经典版出的包一致。若导出后资源 ID 变化导致崩溃，先清理重建，再检查是否有硬编码的资源 ID；这种情况在老项目里偶发，导出前后都要回归。

接下来把渠道搬进 Gradle：定义 productFlavors，给每个 flavor 设置 applicationIdSuffix（只有需要改包名时）、versionNameSuffix、manifestPlaceholders 或 resValue；签名配置从 keystore.properties 读取，keystore.properties 放进 .gitignore；CI 里用环境变量注入口令。这样每次构建产出的渠道包，签名和渠道值都由配置决定，不靠人手改。

android {
    flavorDimensions "channel"
    productFlavors {
        official {
            dimension "channel"
            manifestPlaceholders = [CHANNEL_ID: "official"]
        }
        store_oppo {
            dimension "channel"
            manifestPlaceholders = [CHANNEL_ID: "store_oppo"]
        }
    }
}

怎么验证：assembleRelease 后，用 aapt 看包名与版本，用 apksigner 看签名，用解包看渠道值；再和经典版手动包对比。两者应该只在构建工具链和压缩细节上不同，业务身份必须一致。若不一致，先查 flavor 配置，再查 Manifest 合并结果。最后做一次覆盖升级：从经典版包升级到 Gradle 包，或反向升级，确认签名相同、版本递增。

失败怎么查：Sync 失败，先看 AGP 与 Gradle 版本是否匹配、JDK 是否满足要求；资源找不到，检查 res 目录是否被导出完整；渠道值读不到，检查 manifestPlaceholders 是否写进了正确的 flavor；签名失败，检查 keystore.properties 路径和口令；安装失败，检查 applicationId 是否被 flavor 改掉、签名是否仍是同一把。每修一项就重新构建一次，不要攒着一起改。

导出工程的维护要点：不要提交密钥库；不要提交 local.properties；把 Gradle、AGP、JDK 版本写进 README；升级 AGP 时先跑通空工程，再迁业务；保留经典版工程作为对照，遇到 Gradle 构建差异时可以快速定位。经典版适合精修和救急，Android Studio 适合长期流水线，两者可以并存。

到这一步，多渠道包就从“每次手工改”变成了“配置驱动”。但不要因此跳过验收：Gradle 也会配错 flavor，也会漏签名，也会把旧渠道值带进新包。流程自动化只减少重复劳动，不替代检查。

十、两个自家实例、工具带与验收习惯

下面两个例子都来自自有或已授权应用，一个是不改包名的双渠道，一个是按客户改包名的内部工具。每个都按“以前怎么做、现在怎么做、改完怎么验证”写，方便你对照自己的项目。例子里的包名、版本、客户名都做了替换，方法可以直接复用。

实例一：自家记账 App 出官网包与商店包

背景：一款自家记账应用，包名 com.example.jizhang，versionName 3.8.2，versionCode 382。需要两个渠道：官网直发 official，应用商店 store_oppo。两个包必须能互相覆盖升级，后台按渠道统计新增与留存。

以前怎么做：每次发版，手工在 smali 里搜渠道字符串，改完用 apktool 回编；签名时有时用旧密钥、有时用新生成的密钥，导致部分用户覆盖安装失败；文件名随手写“记账最终版.apk”，过一周就分不清哪个是商店包。渠道值还出现过 offical 的拼写错误，后台多了一个孤立渠道。

现在怎么做：先定渠道清单，official 和 store_oppo 两个 id 写进表格；在 res/values/channel.xml 里维护 channel_id；反编译一次，复制两份工程，分别改值为 official 和 store_oppo；回编、zipalign、用同一把 release 密钥签名；按 jizhang-3.8.2-382-official-20261021-release.apk 和 jizhang-3.8.2-382-store_oppo-20261021-release.apk 命名；把签名摘要和 SHA-256 写进归档表。

改完怎么验证：两个包分别装到两台测试机，打开“关于”页确认渠道 id；后台测试环境确认收到对应渠道的上报；先装 3.8.1 正式包，再用 3.8.2 覆盖，确认数据与登录态保留；apksigner verify 对比两个包证书摘要一致；检查应用商店后台的包名、版本、签名与上传包一致。

这个例子的关键不是工具多强，而是“包名不动、签名不动、只动渠道值”。一旦守住这三条，升级链路就不会断。用修改大师经典版的好处是每一步都能停下来核对，渠道值到底写进哪个文件、签名到底用了哪把密钥，都能当场看到。

实例二：自家内部工具按客户渠道出包

背景：一套自家内部巡检工具，要交付给客户 A 和客户 B。两家客户要求桌面图标、应用名、API 地址都独立，而且要在同一台手机上并存。包名分别为 com.example.neitool.a 和 com.example.neitool.b，渠道 id 为 cust_a、cust_b。

以前怎么做：复制一份工程，只改了 Manifest 的 package 和应用名，忘了改 ContentProvider 的 authority，两个包同时安装时冲突；客户 B 的 API 地址还指向测试环境，上线后数据写到了错误的后台；两个客户共用一个签名密钥，交付边界不清。

现在怎么做：先做改包名清单：package、applicationId、provider authorities、自定义 permission、deep link、SDK 配置、assets 里的 API 地址、应用名、图标、签名策略；每个客户单独生成密钥库，不共用主产品密钥；在 assets/channel.properties 写客户渠道与 API 地址；用经典版反编译、改值、回编、对齐、签名；按 neitool-1.4.0-140-cust_a-20261021-release.apk 命名，客户目录分开归档。

改完怎么验证：同一台手机同时安装 A、B 两个包，确认都能启动、图标和名称不同；分别触发一次接口请求，在各自后台日志确认来源；检查两个包的签名摘要不同且与交付文档一致；升级 B 包时确认不影响 A 包；卸载 A 后 B 的数据仍在；把“可共存、数据隔离、接口正确、签名可追溯”写进验收表。

这个例子的重点是：改包名不是改一行 package 就完事，所有跟身份绑定的地方都要跟着改。清单比记忆可靠。客户交付还要注意授权边界：只改客户拥有或书面授权的应用，交付包里不要夹带主产品的密钥、后台账号和测试账号。

工具带：自动脱壳修复、文件管理、日志与装机

自家应用如果加了壳，反编译出来可能只有壳的代码。确认授权后，可以用经典版的自动脱壳修复先处理，再进入常规反编译。修复后要逐项验证：启动、登录、核心页面、支付、推送；任何一项异常都先回到原始包排查，不要在半成品上改渠道。脱壳修复只用于自有或已授权应用，这条底线不能破。

文件管理工具负责“看得见”：项目目录、smali、XML、assets、日志都能直接打开，改完保存即可回编。它的价值在排查——渠道值到底写进哪个文件、回编失败是哪个资源、签名日志停在哪一步，都能当场看到。日志和装机工具则把“构建、安装、启动”串起来，减少在多个窗口之间切换。

工具再多，也替代不了清单。建议把本文的步骤压缩成一页检查表：渠道清单、反编译基线、改值位置、包名策略、签名摘要、命名规则、验收记录、AS 导出。每次生成渠道包照着打勾，出错时倒着查，效率比凭记忆高得多。

用户评价

“以前最怕渠道包签名不一致，装到一半报错。现在固定一把密钥，生成包后先 verify 再安装，官网包和商店包终于能互相覆盖了。”
—— 阿泽 独立开发者

“我们给客户做白牌交付，包名、应用名、接口地址三处最容易漏。照着清单改，再用文件管理逐个核对，交付前心里有底。”
—— 小林 某硬件公司 Android 开发

“经典版的好处是每一步都看得见。渠道值写进哪个文件、回编卡在哪个资源，日志里都有，不用猜。”
—— 老周 外包团队负责人

“导出 Android Studio 工程后，把渠道搬进 productFlavors，后面加渠道就是改配置，不用每次重新反编译。”
—— 阿岚 电商公司客户端开发

“内部工具按客户生成包，最怕两个包互相覆盖。现在包名和签名都分开，同机共存、数据隔离，验收表一填就清楚。”
—— 陈工 企业信息化运维

合规提醒

本文所有操作都应以自有版权或已获授权的应用为前提。请勿用于破解、去除他人付费限制、绕过安全机制或侵犯他人知识产权。给客户交付时，确认合同与授权范围；处理用户数据时，遵守隐私与安全要求；签名密钥、后台账号、测试账号分开管理，不随安装包外发。遇到来源不明的 APK，不要因为“能反编译”就默认可以改，先确认权利归属。