📚 课程目录第3章开发环境搭建

3. 开发环境搭建

Android Automotive 系统服务开发与普通 App 开发最大的区别在于：你面对的不是一个 SDK，而是一整套 AOSP 源码树、编译系统和目标设备。系统服务的修改必须经过源码编译、镜像刷写、设备启动验证的完整闭环，因此开发环境搭建是后续所有工作的地基。本章围绕源码获取、编译配置、模拟器与真车调试、ADB 与 Car 工具链四条主线展开，帮助你建立一套可复现、可调试、可回滚的工程环境。

一、核心原理：AAOS 开发环境的三层结构

AAOS 开发环境可以理解为三层：源码层（AOSP 源码树与 repo 清单）、构建层（Soong/Blueprint、Ninja、Jack 已废弃后的编译体系）、运行层（模拟器或真车上的 Android 系统镜像）。系统服务开发者修改的代码通常位于 packages/services/Car、frameworks/base/services、system/ 等目录，这些模块会被编译进 system.img、product.img 或 vendor.img，最终通过 fastboot 或模拟器加载。

理解这一点非常关键：系统服务不是热插拔的 APK，它的生命周期与系统镜像绑定。因此环境搭建的目标不是“能跑起来”，而是“能快速编译、能刷写、能抓日志、能回滚”。

二、方法流程：从零到可调试设备

第一步是源码下载。AOSP 使用 repo 管理多仓库，AAOS 分支通常选择 android-14.0.0_r* 或厂商指定 tag。下载前需确认磁盘空间（建议 400GB 以上）、内存（建议 32GB 以上）和 JDK 版本。

# 安装 repo 并初始化 AAOS 分支
mkdir ~/aosp && cd ~/aosp
repo init -u https://android.googlesource.com/platform/manifest \
  -b android-14.0.0_r20
repo sync -c -j8 --no-tags --no-clone-bundle

# 编译环境初始化
source build/envsetup.sh
lunch aosp_car_x86_64-userdebug
make -j16

第二步是编译环境配置。Ubuntu 22.04 下需安装 openjdk-17-jdk、git、curl、python3、libncurses5 等依赖。若使用 ccache，可在 ~/.bashrc 中设置 export USE_CCACHE=1 与 export CCACHE_DIR=~/.ccache，并执行 ccache -M 50G。编译目标选择 aosp_car_x86_64-userdebug 可同时满足模拟器运行与调试需求。

第三步是模拟器与真车调试。模拟器通过 emulator -avd car_x86_64 -writable-system 启动，支持 adb root 与 adb remount，适合快速验证 CarService 行为。真车调试则依赖 USB 或以太网 ADB，需在 Settings → System → Developer options 中开启 USB 调试，并通过 adb devices 确认连接。

三、ADB 与 Car 工具链实战

AAOS 在标准 ADB 之上扩展了 Car 相关命令。常用工具链如下表所示：

工具/命令	用途	典型示例
`adb shell dumpsys car_service`	查看 CarService 运行状态	确认服务是否正常启动
`adb shell cmd car_service`	调用 CarService 命令接口	模拟车辆属性变化
`adb shell dumpsys activity service Car`	查看 Car 相关 Activity 栈	排查界面启动异常
`adb logcat -b all \| grep Car`	抓取 Car 模块日志	定位服务崩溃原因
`adb shell cmd car_service inject-vhal-event`	注入 VHAL 事件	模拟车速、档位变化
`adb shell am start -n com.android.car/.CarShellActivity`	启动 Car 界面	验证系统 UI 是否正常

一个典型场景是：修改 CarService 中某个属性监听逻辑后，执行 mmm packages/services/Car 增量编译，再 adb sync 推送，最后 adb shell stop && adb shell start 重启系统服务。若使用模拟器，可直接 adb reboot 验证完整启动流程。

提示：模拟器调试时建议开启 -writable-system，否则 adb remount 会失败。真车调试前务必确认设备已解锁 bootloader，并保留原厂镜像以便回滚。

四、误区与复盘

常见误区一：用 App 开发思维对待系统服务。系统服务修改后不能只靠 adb install 生效，必须重新编译镜像或至少推送对应模块并重启服务。误区二：忽略 lunch 目标与设备匹配。选择 aosp_car_x86_64-userdebug 却刷入真车，会导致驱动与 HAL 不匹配。误区三：不配置 ccache 导致重复编译耗时数小时。误区四：真车调试不备份原镜像，一旦刷写失败难以恢复。

警告：真车刷写存在变砖风险，务必在厂商指导下进行，并确保 fastboot 与 ADB 驱动已正确安装。模拟器环境虽然安全，但无法完全替代真车的 CAN/VHAL 行为验证。

复盘建议：每次环境搭建完成后，记录 repo manifest -r 输出、lunch 目标、编译命令、镜像路径与 ADB 连接方式，形成可复现的环境文档。这样在团队协作或换机时，可以快速重建一致的开发环境，避免“在我机器上能跑”的经典问题。