26、车载应用商店：应用商店架构、应用审核流程、签名与分发、License管理
车载应用商店，说白了就是车机上的「软件超市」。但跟手机上的应用商店比，它要复杂得多。我参与过几个车厂的项目，发现很多人把手机那套直接搬过来，结果踩了不少坑。
今天咱们就聊聊车载应用商店的核心：架构怎么搭、审核怎么过、签名怎么搞、License怎么管。
一、应用商店的整体架构
车载应用商店不是单机游戏，它是一套完整的云端+车端系统。我个人习惯把它拆成三层：
核心架构三要素：
- 云端管理平台：开发者上传、审核、签名、分发、License发放
- 车端应用商店App：用户浏览、下载、安装、更新、卸载
- 安全通道：签名验证、加密传输、防篡改
下面这张图能帮你快速理解整体流程：
二、应用审核流程
审核这块，我见过最坑的做法是「全人工审核」。车厂说这样安全，结果一个应用上架要等两周。用户早跑了。
我建议的流程是：自动化审核 + 人工抽检。
| 审核阶段 | 检查内容 | 工具/方法 |
|---|---|---|
| 静态扫描 | 权限声明、签名证书、包名冲突 | 自定义脚本 + Androguard |
| 动态扫描 | 运行时行为、网络请求、隐私收集 | 沙箱运行 + 流量监控 |
| 合规检查 | 是否符合车厂UI规范、是否含违规内容 | 自动化规则 + 人工抽检 |
| 性能测试 | 启动时间、内存占用、CPU使用率 | 自动化测试脚本 |
我的经验：静态扫描一定要做「权限最小化检查」。我曾经见过一个导航应用，申请了「读取联系人」权限。你说导航要联系人干嘛？直接驳回。
三、签名与分发
车载应用的签名，跟手机不太一样。手机签名主要是防篡改，车载签名还要考虑车机硬件绑定。
我参与的一个项目里，用的是「双重签名」机制：
- 第一层：应用签名（跟Android标准一样，用jks或keystore）
- 第二层：车机签名（云端根据车机ID生成专属签名，确保应用只能在这台车上跑）
分发方式也有讲究。车机网络环境不稳定，不能指望用户每次都从云端下载完整APK。我建议用增量更新：
// 伪代码：增量更新流程
1. 车端上报当前版本号 v1.0
2. 云端计算 v1.0 → v1.1 的差异包
3. 车端下载差异包（通常只有几百KB）
4. 车端本地合并生成完整APK
5. 验证签名 → 安装注意：增量更新一定要做签名验证。我遇到过有人伪造差异包，往里面注入恶意代码。合并后的APK签名校验必须通过，否则拒绝安装。
四、License管理
License管理，说白了就是「谁能用、用多久、怎么续」。车载应用不像手机应用，很多功能是按年付费的，比如实时路况、在线音乐。
我常用的License模型有三种：
| License类型 | 适用场景 | 校验方式 |
|---|---|---|
| 永久License | 基础功能（如地图、设置） | 安装时校验一次 |
| 订阅License | 增值服务（如在线音乐、实时路况） | 每次启动时联网校验 |
| 试用License | 新用户试用（如7天免费） | 本地计时 + 云端同步 |
License的存储位置也很关键。我见过有人把License明文存在SharedPreferences里，结果被root后的车机直接破解了。
我建议的做法：
- 云端存储：License主数据存在云端，车端只存加密后的Token
- 硬件绑定：Token跟车机TEE（可信执行环境）绑定，换硬件就失效
- 离线容错：允许离线使用7天，超过后必须联网校验
核心要点：License管理不是防破解，而是「让正常用户用得爽，让破解者成本高」。你想想看，如果每次启动都要联网校验，用户在地下停车场没信号怎么办？所以离线容错机制必须做。
五、避坑指南
最后分享几个我踩过的坑：
- 签名证书过期：我曾经有一批应用签名证书只签了1年，结果第二年全部无法更新。现在我都签5年起步。
- 审核流程太慢：有个合作方要求每个应用都人工审核，结果开发者等得不耐烦，直接放弃了平台。后来改成自动化+抽检，效率提升80%。
- License校验太频繁：有个音乐应用每次切歌都校验License，结果在地下停车场完全用不了。改成启动时校验一次就够了。
嗯，车载应用商店的核心就是这些。架构要分层、审核要自动化、签名要双重、License要灵活。把这些搞定了，你的应用商店就能跑得稳、跑得快。