27、发布与分发：APK签名、应用商店上架、OTA更新
说实话，很多车载开发新手容易忽略一个事：代码写得再好，如果发布流程出了岔子，用户根本用不上。我见过不止一个团队，开发阶段跑得飞起，一到量产装车就翻车。问题往往就出在签名、上架、OTA这几个环节上。
今天咱们就把这块彻底捋清楚。你想想看，车载应用和手机应用最大的区别是什么？是更新周期长、安全要求高、而且一旦出问题，召回成本巨大。所以，发布与分发这件事，必须从一开始就规划好。
一、APK签名：不只是点个按钮那么简单
APK签名，说白了就是给你的应用盖一个「防伪章」。Android系统通过这个章来确认：这个APK确实是你发的，而且没有被篡改过。
我记得刚入行那会儿，有个同事直接用debug签名打了个release包，结果装到量产车上直接闪退。查了半天，原来是车机系统只信任特定的平台签名。嗯，这个坑我踩过，所以今天重点说说。
1.1 签名方案的选择
Android目前支持v1、v2、v3、v4四种签名方案。我建议你直接上v2+v3组合，原因如下：
- v1（JAR签名）：最老，兼容性好，但安全性差。车载场景不建议单独使用。
- v2（APK签名方案v2）：从Android 7.0开始支持，对整个APK文件做签名，安全性大幅提升。
- v3（APK签名方案v3）：Android 9.0引入，支持密钥轮换。这个在车载场景特别有用——万一密钥泄露，可以无缝切换到新密钥。
- v4（APK签名方案v4）：Android 11新增，主要用于增量更新验证。如果你要做OTA差分更新，这个必须加上。
我的建议配置：
在build.gradle中配置v2+v3+v4三签方案。v1可以关掉，除非你要兼容Android 6.0以下的老设备。
// build.gradle 签名配置示例
android {
signingConfigs {
release {
storeFile file("release.keystore")
storePassword "****"
keyAlias "car_app_key"
keyPassword "****"
v1SigningEnabled false
v2SigningEnabled true
v3SigningEnabled true
v4SigningEnabled true
}
}
}⚠ 重要警告：
千万不要把密钥文件提交到Git仓库！我曾经见过一个项目，密钥直接放在源码目录下，结果被外部人员拿到了。那款车后来不得不做全量OTA更新来更换签名。密钥建议用硬件加密模块（如HSM）存储，或者至少用独立的密钥管理服务。
二、应用商店上架：车厂的门槛比手机高多了
车载应用商店和手机应用商店完全是两码事。手机商店你上传个APK，审核个一两天就过了。车厂商店？我经历过最长的审核周期是三个月。
为什么会这样？因为车厂要对整车的安全负责。你的应用如果出了问题，可能导致车机死机、导航失效，甚至影响行车安全。所以，车厂的审核流程极其严格。
2.1 上架前的准备工作
我个人习惯把上架准备分成三个维度：
| 维度 | 检查项 | 常见问题 |
|---|---|---|
| 安全合规 | 权限最小化、数据加密、无高危漏洞 | 滥用定位权限、明文存储用户数据 |
| 隐私合规 | 隐私政策弹窗、数据收集声明、GDPR/个保法 | 未告知用户就收集车辆VIN码 |
| 性能稳定性 | 内存占用、启动速度、无ANR、无Crash | 后台服务持续占用CPU导致车机发热 |
💡 避坑指南：
我曾经有一个应用，因为「在后台频繁获取GPS位置」被车厂打回三次。后来改成「仅在前台且用户主动使用导航时才获取」，才通过审核。记住：车载场景下，用户对隐私的敏感度远高于手机。
2.2 多渠道分发策略
车载应用的分发渠道通常包括：
- 车厂官方商店：主渠道，覆盖量最大，但审核最严
- 预装合作：与车厂签订预装协议，出厂即安装
- 第三方应用市场：部分车机开放了第三方市场入口
- OTA推送：针对已安装用户做增量更新
我的做法是：优先走车厂官方商店，同时保留OTA更新通道。这样既能保证新用户获取，又能服务好存量用户。
三、OTA更新：车载应用的「生命线」
车载应用不像手机应用，用户不会天天去商店检查更新。所以，OTA（Over-The-Air）更新是车载应用持续交付的核心手段。
你想想看，一辆车卖出去后，可能三五年都不会回4S店。如果应用出了Bug，或者需要增加新功能，OTA是唯一的途径。
3.1 差分更新技术
全量更新太费流量了。一个100MB的APK，如果每次更新都全量下载，用户的车载流量套餐根本扛不住。所以，差分更新是必须的。
差分更新的原理很简单：对比新旧APK的二进制差异，只下载变化的部分。我常用的工具是Google的diff-patch库，或者bsdiff算法。
// 差分更新核心逻辑（伪代码）
public class OtaUpdater {
public void applyDeltaUpdate(String oldApkPath, String deltaFile, String newApkPath) {
// 1. 下载差分文件
downloadDeltaFile(deltaFile);
// 2. 应用差分补丁
boolean success = BsDiff.patch(oldApkPath, deltaFile, newApkPath);
// 3. 验证签名
if (success && verifySignature(newApkPath)) {
installApk(newApkPath);
} else {
// 回退到全量更新
downloadFullApk();
}
}
}关键点：
差分更新后必须重新验证APK签名！我曾经遇到过差分补丁被篡改的情况，幸好签名验证环节拦截住了。记住：差分文件本身是不带签名的，完整性全靠下载时的HTTPS和签名验证来保证。
3.2 断点续传与版本回滚
车载网络环境比手机差得多。地下车库、隧道、山区，随时可能断网。所以，OTA更新必须支持断点续传。
我个人习惯用分块下载的策略：把差分文件切成1MB的块，每下载一块就记录进度。下次启动时，从断点处继续下载。
版本回滚也很重要。如果新版本出了严重问题，必须能快速回退到上一个稳定版本。我的做法是保留最近两个版本的APK文件，并维护一个版本回滚表：
| 当前版本 | 回滚目标 | 回滚方式 |
|---|---|---|
| v3.0.0 | v2.5.0 | 全量回滚（因为差分链太长） |
| v2.5.0 | v2.4.0 | 差分回滚 |
| v2.4.0 | v2.3.0 | 差分回滚 |
3.3 静默安装与用户通知
车载应用的安装方式需要特别设计。你不能像手机那样弹个对话框让用户点「安装」，因为用户可能在开车。
我的方案是：
- 下载阶段：后台静默下载，不打扰用户
- 安装阶段：等待车辆熄火、驻车状态时触发安装
- 通知机制：安装完成后，下次启动时通过通知栏告知用户「应用已更新」
⚠ 特别注意：
绝对不要在车辆行驶过程中触发安装！我曾经见过一个案例，某款应用在高速行驶时自动安装更新，导致车机重启，导航中断。这是严重的安全事故。一定要监听车辆的ACC状态和驻车信号。
四、总结一下
发布与分发这件事，看似简单，实则处处是坑。APK签名要选对方案、管好密钥；应用商店上架要过五关斩六将；OTA更新要兼顾差分、断点续传、版本回滚和静默安装。
我个人最大的体会是：车载开发不能只盯着代码，要把整个发布链路都考虑进去。从签名到上架再到OTA，每一个环节都可能成为瓶颈。提前规划好，后面才能走得顺。
好了，这一章的内容就到这里。记住我说的：密钥别放Git、上架前自查隐私合规、OTA一定要支持回滚。这三条做到了，你的车载应用发布流程就稳了一大半。