4、汽车级权限管控的特殊性：车载场景下的权限分级
权限管控这件事，在手机圈已经玩得很成熟了。但到了汽车上，情况完全不一样。我刚开始做车载系统时，第一反应也是「直接把Android那套拿过来用不就行了？」结果被现实狠狠教育了一顿。
为什么？因为汽车上跑的权限，背后连着的不是一张照片、一个联系人，而是方向盘、刹车、车门、空调。权限给错了，不是隐私泄露的问题，是安全问题。说白了，这是人命关天的事。
4.1 车载场景下的三级权限体系
在汽车级Android系统里，我把权限分成三个层级。这个分级方式，是我在几个量产项目中反复调整后沉淀下来的。
| 权限层级 | 典型拥有者 | 控制范围 | 签名级别 |
|---|---|---|---|
| 系统权限 | Android Framework、系统服务 | 核心车辆控制、底层硬件 | platform签名 |
| OEM权限 | 车厂自研应用（仪表、空调、车控） | 车辆功能控制、车身域通信 | OEM自定义签名 |
| 第三方权限 | 地图、音乐、视频等市场应用 | 信息娱乐、非安全相关功能 | 普通签名或未签名 |
这个表格看起来简单，但实际落地时坑特别多。我一个个说。
4.1.1 系统权限：底层的守门人
系统权限，说白了就是Android系统自身持有的最高权限。它控制着车辆最核心的硬件资源——CAN总线、以太网网关、安全气囊、制动系统。
我记得在某个项目中，第三方应用试图通过JNI直接访问CAN套接字。系统权限层直接拦截了，因为这类操作必须经过Vehicle HAL。你想想看，如果随便一个应用都能往CAN总线上发报文，那车还怎么开？
关键点：系统权限通常只授予预置在/system分区中的应用，且必须使用platform签名。这是Android原生机制，但在汽车上被强化了。
4.1.2 OEM权限：车厂的专属领地
OEM权限是车厂自己定义的一套权限体系。它介于系统权限和第三方权限之间。我习惯把它叫做「半开放权限」。
举个例子：空调控制。这个功能不需要访问CAN总线，但需要控制车身域控制器。车厂自己的空调应用会申请OEM级别的com.oem.permission.CONTROL_CLIMATE权限。第三方应用拿不到这个权限。
我在项目中遇到过一个问题：某车厂想把语音助手做成第三方应用，但语音助手需要控制车窗。怎么办？我们最终的做法是——语音助手通过OEM预置的「车控服务」间接控制车窗，而不是直接授予OEM权限。这是个典型的妥协方案。
我的建议：OEM权限不要轻易开放给第三方。如果非要开放，走代理模式——让第三方应用调用OEM提供的API，而不是直接持有权限。
4.1.3 第三方权限：被严格限制的访客
第三方应用能拿到的权限，基本局限在信息娱乐域。比如读取媒体文件、访问网络、获取位置信息。这些权限在手机上很常见，但在车上，它们被加上了更多限制。
举个例子：位置权限。手机上，地图应用可以随时获取精确位置。但在车上，我们要求第三方应用只能获取到「车辆所在城市」级别的模糊位置。为什么？因为精确位置可能暴露用户的驾驶轨迹和家庭住址。
嗯，这里要注意：第三方权限不是不能提升，但必须经过用户明确授权，而且授权范围要严格控制。我见过一些方案，直接把「读取车辆状态」权限开放给第三方，结果被用来采集驾驶行为数据。这种做法，我个人非常不推荐。
4.2 权限与车辆控制功能的映射关系
权限不能只停留在概念层面。它必须和具体的车辆控制功能一一对应。我习惯用一张映射表来管理这种关系。
| 车辆功能 | 所需权限 | 权限级别 | 授权方式 |
|---|---|---|---|
| 发动机启动/停止 | android.car.permission.CONTROL_POWER | 系统权限 | 预置授权 |
| 车门解锁/闭锁 | com.oem.permission.CONTROL_DOOR | OEM权限 | 预置授权 |
| 空调温度调节 | com.oem.permission.CONTROL_CLIMATE | OEM权限 | 预置授权 |
| 车窗升降 | com.oem.permission.CONTROL_WINDOW | OEM权限 | 预置授权 |
| 导航语音播报 | android.permission.ACCESS_FINE_LOCATION | 第三方权限 | 运行时授权 |
| 音乐播放 | android.permission.READ_EXTERNAL_STORAGE | 第三方权限 | 运行时授权 |
这张表看起来规整，但实际落地时，你会发现很多边界情况。比如：
- 组合权限：控制座椅需要同时拥有「座椅调节」和「座椅记忆」两个权限。我曾经见过一个应用只申请了前者，结果调节完座椅后无法保存位置，用户投诉说「每次上车都要重新调」。
- 权限降级：当车辆处于行驶状态时，某些权限会被自动降级。比如，行驶中禁止第三方应用控制车窗。这个逻辑需要在权限管理服务中做状态感知。
- 权限继承：系统应用通过Binder调用系统服务时，权限会沿着调用链传递。如果处理不当，可能出现权限泄露。我建议在AIDL接口中显式声明权限检查。
避坑指南：我曾经在某个项目中，把「车窗控制」权限错误地配置成了系统级别。结果导致OEM自己的车控应用都无法调用，排查了整整两天才发现是权限级别配错了。记住：OEM应用能完成的功能，不要提升到系统权限。权限粒度越细，后期维护越轻松。
4.3 权限管控的落地实践
理论说完了，聊聊实际怎么落地。我一般会做三件事：
- 定义权限清单：在AndroidManifest中声明所有OEM权限，并绑定到对应的车辆功能。每个权限都要有明确的描述和级别。
- 实现权限检查：在Vehicle HAL和CarService中，对每个敏感操作做权限校验。不要依赖应用层自觉，底层必须兜底。
- 建立权限审计：记录所有权限申请和使用的日志。一旦出现异常，可以快速回溯。我习惯把权限日志单独存储，不和普通日志混在一起。
最后说一句：权限管控不是一锤子买卖。随着车辆功能的增加和第三方生态的丰富，权限体系需要持续演进。保持权限清单的更新，定期审计权限使用情况，这是每个车载安全工程师的必修课。