2. 环境搭建

Android Car Framework（Car Service）的定制开发，其根基在于一套完整、稳定且可复现的AOSP（Android Open Source Project）构建与调试环境。对于课程学员而言，如果环境搭建不牢固，后续所有的系统服务修改、HAL层适配、系统应用定制都将成为无源之水。本章节将深入剖析从源码获取到真机调试的全链路流程，重点解析Car Service在源码树中的具体位置与依赖关系，帮助大家建立起一套高效的本地开发闭环。

上图展示了本章节的核心知识框架：从源码下载到最终调试的完整工程链路，以及Car Service在AOSP源码树中的核心模块位置。下面我们将按照这一链路逐步展开详细讲解。

2.1 AOSP源码下载与分支选择

核心原理

AOSP源码体量庞大（约50GB以上），且由数百个Git仓库组成。Google使用repo工具对多仓库进行版本管理与同步。对于Car Framework开发，我们不仅需要关注platform/packages/services/Car仓库，还需要关注与其紧密关联的platform/frameworks/base、platform/hardware/interfaces（特别是VHAL相关接口）以及platform/vendor（厂商私有实现）。选择正确的分支至关重要，通常建议选择与目标车型或芯片平台（如高通SA8155/SA8295、瑞萨R-Car H3等）匹配的Android版本（如Android 11/12/13/14）。

操作流程

1. 环境准备：建议使用Ubuntu 18.04或20.04 LTS 64位系统，至少500GB可用磁盘空间（建议SSD），16GB以上内存（推荐32GB）。安装必要的依赖包：git、python3、curl等。
2. 安装Repo工具：执行 mkdir ~/bin && curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo && chmod a+x ~/bin/repo，并将~/bin加入PATH。
3. 初始化仓库：创建源码目录（如~/aosp-car），执行 repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_r41。若需包含Car相关私有仓库，需在default.xml中确认packages/services/Car的引用。
4. 同步源码：执行 repo sync -c -j8（-c表示只同步当前分支，-j8为并行任务数）。此过程耗时数小时，建议使用--no-tags参数减少数据量。

案例拆解：分支选择失误导致编译失败

某项目组在开发车载中控时，误选了Android 12的通用分支（android-12.0.0_r1），但该分支并未包含最新的Car Service API（如CarPropertyManager的新增接口）。编译时出现cannot find symbol错误。经排查，发现packages/services/Car仓库的版本与frameworks/base中的Binder接口不匹配。最终通过切换到android-12.0.0_r32（该版本对应了车机专用补丁）解决了问题。这提醒我们，分支选择必须参考目标硬件厂商的BSP（Board Support Package）文档，而非盲目选择最新版本。

常见误区

• 误区一：认为repo sync一次就能成功。网络中断、磁盘空间不足都会导致同步失败，需使用repo sync --force-sync重试。
• 误区二：忽略repo start创建本地分支。直接在默认分支上修改代码，后续repo sync时极易产生冲突。

2.2 编译环境配置与系统构建

核心原理

AOSP编译依赖特定的工具链版本。Android 13要求OpenJDK 11（不再支持JDK 8），且需要Python 3.8+。编译系统使用Soong（基于Go语言）替代了早期的Make。对于Car相关模块，编译时会生成car-service.jar、android.car.jar（Car API库）等关键产物。环境配置的核心在于build/envsetup.sh脚本，它提供了lunch、m、mm等便捷命令。

操作流程

# 1. 配置JDK环境（以Ubuntu为例）
sudo apt-get install openjdk-11-jdk
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH

# 2. 初始化编译环境
source build/envsetup.sh

# 3. 选择编译目标（以模拟器为例）
lunch aosp_car_x86_64-userdebug

# 4. 开始编译（首次编译建议使用make -j8，根据CPU核数调整）
make -j8 2>&1 | tee build.log

对于仅修改Car Service模块的增量编译，推荐使用m packages/services/Car或进入模块目录执行mm，这能将编译时间从数小时缩短至几分钟。

知识结构表：常见编译目标与用途

案例拆解：ccache加速编译

在编译过程中，C/C++代码的重复编译是耗时大户。我们在一台16核32GB内存的服务器上，通过配置export USE_CCACHE=1和export CCACHE_DIR=/mnt/ccache，并设置ccache -M 50G，将第二次全量编译的时间从2.5小时缩短至1.2小时，效率提升约52%。对于团队开发，共享ccache目录能进一步节省时间。

常见误区

• 误区一：忽略userdebug与user版本的区别。userdebug版本支持adb root，便于调试系统服务，而user版本则移除了调试权限。
• 误区二：编译时内存不足。Soong编译系统对内存要求极高，若内存小于16GB，建议增加swap空间，否则会出现Killed进程。

2.3 模拟器与真机调试环境搭建

核心原理

模拟器（Emulator）基于QEMU，提供了快速的硬件模拟环境，适合Car Service的框架层调试。真机调试则更贴近实际硬件，能验证VHAL（Vehicle Hardware Abstraction Layer）与真实车辆信号的交互。两者的核心调试工具均为ADB（Android Debug Bridge）。对于Car Service，adb shell dumpsys car_service是查看服务内部状态（如属性值、订阅者列表）的关键命令。

操作流程：模拟器搭建

# 1. 编译模拟器镜像（已在上节完成）
# 2. 启动模拟器（需在源码根目录下）
source build/envsetup.sh
lunch aosp_car_x86_64-userdebug
emulator -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect &
# 3. 等待系统启动完成
adb wait-for-device
adb shell getprop sys.boot_completed

操作流程：真机调试搭建

1. 刷机：将编译生成的out/target/product/<device>/目录下的img文件（如system.img、vendor.img）通过fastboot flash命令刷入设备。
2. 启用开发者模式：在设备上连续点击版本号7次，开启USB调试。
3. 连接与验证：执行adb devices确认设备在线，执行adb shell dumpsys car_service验证Car Service是否正常运行。

案例拆解：模拟器无法启动Car Service

某次在模拟器上启动系统后，发现dumpsys car_service报错Service not ready。通过adb logcat -s CarService查看日志，发现VHAL初始化失败，原因是模拟器默认不提供VHAL实现。解决方案是使用emulator -feature -VirtioVehicleHal参数启用模拟VHAL，或者编译并推送一个模拟的VHAL服务（如EmulatedVehicleHal）。此案例说明，模拟器环境与真机在HAL层存在显著差异，调试时需明确区分。

常见误区

• 误区一：在模拟器上调试VHAL相关功能，导致误判为代码问题。应优先在真机或使用模拟VHAL。
• 误区二：真机刷机后未清除用户数据（fastboot -w），导致旧数据与新系统不兼容，出现系统服务崩溃。

2.4 Car Service相关模块源码结构解析

核心原理

Car Service的源码位于packages/services/Car目录下，其结构清晰，职责分明。理解该目录结构是进行定制开发的前提。核心模块包括：car-lib（客户端API）、service（系统服务实现）、vehiclehal（VHAL接口定义与默认实现）、evs（外部视图系统）、cluster（仪表盘）、audio（车载音频策略）等。

源码结构清单

packages/services/Car/
├── car-lib/                  # Car API 库 (android.car.jar)
│   ├── src/android/car/      # 公开API，如 Car.java, CarPropertyManager.java
│   └── tests/                # API单元测试
├── service/                  # CarService 系统服务实现
│   ├── src/com/android/car/  # 核心服务逻辑
│   │   ├── CarServiceImpl.java
│   │   ├── property/         # 属性管理
│   │   ├── audio/            # 音频焦点与音量策略
│   │   ├── cluster/          # 仪表盘数据管理
│   │   └── evs/              # 外部视图（环视/后视）
│   └── res/                  # 系统资源配置
├── vehiclehal/               # VHAL 相关
│   ├── default/              # 默认VHAL实现（模拟器用）
│   └── proto/                # VHAL AIDL/Protobuf定义
├── evs/                      # EVS 独立模块
├── cluster/                  # Cluster 独立模块
├── audio/                    # 音频策略服务
└── tests/                    # 集成测试

核心模块对比表

案例拆解：定位一个属性读取超时问题

假设车辆速度属性（VehiclePropertyIds.PERFORMANCE_VEHICLE_SPEED）读取超时。排查路径如下：

1. 应用层：检查CarPropertyManager.getProperty()调用是否正确，排除客户端问题。
2. 服务层：在CarPropertyService.java中打印日志，确认请求是否到达服务端。
3. HAL层：在VehicleHal.java的getProperty()方法中打断点，确认是否成功调用底层驱动。
4. 驱动层：检查VHAL的AIDL接口是否返回Status.STATUS_OK。

通过逐层日志分析，最终定位到是VHAL中一个synchronized方法阻塞导致超时。此案例展示了熟悉源码结构对快速定位问题的重要性。