1. 课程导入

Android Automotive OS（AAOS）把 Android 的应用生态、权限模型与汽车电子电气架构深度结合，形成了“车载信息娱乐系统 + 车辆信号控制 + 多用户座舱”的复合安全场景。与手机 Android 相比，AAOS 的权限安全工程不仅要处理应用沙箱、运行时权限、签名与 SELinux，还要面对车辆属性（Vehicle Property）、驾驶分心限制、多用户/多账户、OTA 升级与整车网络边界等新问题。本课程的目标，是让学习者从“会写应用”进阶到“能设计并验证一套可落地的车载权限安全方案”。

一、学习目标：从权限使用者到安全设计者

本课程围绕四个能力层次展开。第一层是理解模型：掌握 Android 权限体系在 AAOS 中的继承与扩展，包括 UID/GID、权限声明、运行时授权、AppOps、SELinux 域与类型。第二层是识别风险：能够判断哪些车辆信号、系统服务、第三方应用接口存在越权、提权或信息泄露风险。第三层是设计控制：能够为 Car Service、Vehicle HAL、系统应用与第三方应用设计最小权限、签名白名单、角色授权与用户隔离策略。第四层是验证与复盘：能够通过日志、dumpsys、SELinux 拒绝记录、CTS/VTS 与渗透测试手段验证权限策略是否真正生效。

二、核心概念：AAOS 权限安全的五个关键词

• Permission 与 Protection Level：normal、dangerous、signature、privileged 等保护级别决定了应用能否获得权限，以及是否需要用户或系统签名授权。
• UID / GID 与沙箱：每个应用默认运行在独立 UID 下，系统通过 UID 隔离数据与进程；共享 UID 会显著扩大攻击面。
• Car Service 与 Vehicle Property：车辆属性是 AAOS 的核心数据通道，权限控制必须覆盖属性读取、订阅、写入与速率限制。
• SELinux 与 MAC：即使应用获得了 Android 权限，SELinux 仍可在内核层拒绝其访问特定设备节点、Binder 服务或文件。
• 多用户与驾驶状态：不同用户、不同座位、不同驾驶状态下的权限应动态变化，不能一套策略走天下。

三、整体知识框架：一张图看清权限安全工程

下图给出本课程的知识框架。它从应用层、框架层、原生层到内核层逐层展开，并标出权限决策与强制执行的路径。学习时建议先建立这张“地图”，再逐章深入每个节点。

四、实战路线图：从环境搭建到安全验证

课程后续章节将按“环境 → 模型 → 控制 → 验证 → 复盘”推进。建议学习者按以下路线动手实践，每完成一步都保留日志与配置快照，便于回溯。

1. 环境准备：搭建 AAOS 模拟器或真车开发板，确认 adb、dumpsys、logcat、SELinux 工具可用。
2. 权限建模：梳理目标应用需要访问的车辆属性、系统服务与硬件资源，形成权限清单。
3. 策略设计：为每个权限选择保护级别、签名要求、用户范围与驾驶状态限制。
4. 代码落地：在 AndroidManifest、Car Service 配置、SELinux 策略与 seapp_contexts 中同步实现。
5. 验证与复盘：通过越权测试、日志审计与 CTS/VTS 验证策略有效性，记录误报与漏报。

五、典型场景与常见误区

以“第三方应用读取车速”为例：应用声明了 android.car.permission.CAR_SPEED，但该权限为 signature 级别，普通应用无法获得。若开发者误以为“声明即可用”，就会在运行时收到 SecurityException。正确做法是：系统应用或签名应用通过 Car Service 暴露受控接口，第三方应用只能读取脱敏后的状态或通过角色授权获得有限访问。

# 查看应用权限授予情况
adb shell dumpsys package com.example.carapp | grep -A 20 "requested permissions"

# 查看 SELinux 拒绝记录
adb shell dmesg | grep avc

# 查看 Car Service 属性权限
adb shell dumpsys car_service | grep -i permission

六、核心检查清单

掌握这张框架图与检查清单后，后续每一章都会围绕其中一个节点展开：从权限声明细节，到 Car Service 的属性控制，再到 SELinux 策略编写与整车安全验证。学习时请始终带着“这条权限最终由谁强制、如何验证”的问题，才能真正把 AAOS 权限安全工程落到工程实践中。