APK 渠道参数注入，无需重签
渠道链接只有在安装后的 App 能读到来源时才有价值。对于不是从 Google Play 分发的 APK，通常需要在下载环节把渠道值附带进去。
referer 是 APK Ref Injector 使用的查询参数，不是 HTTP 的 Referer 请求头。
重签名的麻烦
本节链接常见做法是为每个渠道单独打包，或者在下载时修改 APK 并重新签名。这两种方式都会带来额外风险：
- 每个渠道都要多一个构建产物和签名；
- 更换签名密钥可能导致老用户无法覆盖安装；
- 每次投放都要重复执行重签名流程；
- 用户最终安装的 APK 已经不是原始签名版本。
对于通过自有网站、CDN、企业内部分发或合作渠道分发的团队，这些成本会快速累积。
服务端注入做了什么
本节链接APK Ref Injector 只保留一个已签名的母包。用户请求下载时，服务在下载响应中附加请求的渠道值，而不重新签名 APK。
用户拿到的仍然是同一个 APK 包，仍然保持原始 V2/V3 签名。渠道值随下载一起到达，安装后可以由 App 读取。
这样可以做到：
- 一个应用只维护一个母包；
- 下载前后签名保持一致；
- 新增或修改渠道链接不需要重新发版；
- 服务部署在你自己的环境中。
适用场景
本节链接服务端注入适合：
- 用户从你的域名、合作方页面或企业分发页下载 APK；
- 需要在 Google Play 之外做渠道或活动归因；
- 不能或不希望重新签名 APK；
- 希望一个签名包对应多个下载链接。
如果应用是从 Google Play 安装的，仍应使用 Google Play Install Referrer。两者解决的是不同分发场景。
验证结果
本节链接通过带渠道参数的链接下载后，对比原始 APK 的签名：
apksigner verify --verbose downloaded.apkV2/V3 签名应保持有效。如果 App 会在运行时读取渠道值，请用真实下载链接测试完整流程，而不是只测试本地文件。