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

3、开发环境搭建：AOSP源码下载与编译、模拟器与真机选择、交叉编译工具链、调试工具（adb、logcat、dmesg）配置

Android传感器HAL开发的第一步，是搭建一套完整、稳定且可复现的开发环境。与普通应用开发不同，HAL层代码运行在系统进程中，直接与Linux内核和硬件抽象层交互，因此开发者必须掌握AOSP（Android Open Source Project）源码的下载与编译、目标设备的选择、交叉编译工具链的配置，以及adb、logcat、dmesg等核心调试工具的使用。本章将围绕这四个关键环节展开，帮助你构建一个从源码到调试的闭环工作流。

3.1 AOSP源码下载与编译

3.1.1 核心原理：AOSP的版本管理与构建系统

AOSP采用Git作为版本控制工具，并通过Repo工具对数百个Git仓库进行统一管理。传感器HAL开发通常需要关注三个关键目录：hardware/interfaces/sensors（HAL接口定义）、device/<vendor>/<board>（设备配置与传感器实现）、kernel/drivers（内核驱动）。AOSP的构建系统基于Soong（Android.bp文件）和Make（Android.mk文件），两者最终都会生成Ninja构建规则。对于传感器HAL，我们通常使用make命令编译整个系统镜像，或使用mmm命令单独编译某个模块。

3.1.2 操作流程：源码下载与编译步骤

环境准备：Ubuntu 20.04 LTS 64位系统，磁盘空间至少300GB（建议500GB），内存16GB以上，安装Git、Python 3.8、OpenJDK 11（Android 12及以上版本不需要JDK）。

安装Repo：

mkdir ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=~/bin:$PATH

初始化仓库：

mkdir aosp && cd aosp
repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_r3
repo sync -c -j8

建议使用清华或中科大镜像源加速下载。

编译系统镜像：
```
source build/envsetup.sh
lunch aosp_arm64-userdebug
make -j$(nproc)
```
编译时间取决于机器性能，通常需要2-4小时。编译完成后，镜像输出在out/target/product/generic_arm64/目录下。

经验提醒：对于传感器HAL开发，建议使用userdebug版本而非user版本，因为userdebug版本保留了root权限和完整的调试工具，方便后续使用adb root和remount操作。

3.1.3 案例拆解：编译传感器HAL模块

假设我们需要修改hardware/interfaces/sensors/2.1/default下的传感器实现，并单独编译该模块。操作如下：

# 修改代码后，进入AOSP根目录
source build/envsetup.sh
lunch aosp_arm64-userdebug
# 编译指定模块
mmm hardware/interfaces/sensors/2.1/default
# 或者使用更快的编译方式
m android.hardware.sensors@2.1-service
# 编译完成后，将生成的so文件推送到设备
adb root
adb remount
adb push out/target/product/generic_arm64/vendor/lib64/hw/android.hardware.sensors@2.1-service.so /vendor/lib64/hw/
adb shell chmod 644 /vendor/lib64/hw/android.hardware.sensors@2.1-service.so
adb reboot

这种模块级编译方式将编译时间从小时级缩短到分钟级，是HAL开发中最常用的迭代方式。

3.1.4 常见误区与总结

风险提示：不要使用make -j$(nproc)时设置过高的并行数，否则容易导致内存溢出（OOM）。建议并行数不超过CPU核心数的1.5倍。另外，AOSP源码下载过程中断后，不要直接重新repo sync，应先执行repo sync -l进行本地同步，再继续完整同步。

总结：AOSP源码下载与编译是HAL开发的基础，掌握模块级编译技巧可以大幅提升开发效率。建议在首次完整编译成功后，将out目录备份，以便后续快速恢复环境。

3.2 模拟器与真机选择

3.2.1 核心原理：不同目标设备的适用场景

传感器HAL开发中，模拟器与真机各有优劣。模拟器（如Cuttlefish、Goldfish）适合快速验证HAL接口逻辑、传感器数据上报流程，但无法模拟真实的硬件中断、I2C时序和电源管理行为。真机（如Pixel系列、RK3399开发板）则能提供真实的传感器硬件环境，但调试成本更高，且需要处理厂商驱动和内核模块的兼容性问题。

3.2.2 判断方法：如何选择目标设备

维度	模拟器（Cuttlefish）	真机（Pixel 6）	开发板（RK3399）
启动速度	快（秒级）	慢（分钟级）	中等（需烧录）
传感器硬件	虚拟传感器（可模拟加速度计等）	真实传感器（LSM6DSO等）	可外接传感器模块
调试便利性	支持快照、回放	需要adb连接	支持串口+adb
适用阶段	HAL逻辑验证、单元测试	集成测试、性能调优	驱动开发、硬件验证

3.2.3 实战场景：模拟器上的传感器HAL验证

使用Cuttlefish模拟器时，可以通过cvd start启动虚拟设备，然后通过adb shell进入系统。模拟器默认提供一组虚拟传感器，包括加速度计、陀螺仪、磁力计等。我们可以通过修改device/google/cuttlefish下的传感器配置文件，添加自定义的虚拟传感器行为。例如，在sensors配置文件中添加一个模拟温度传感器：

# device/google/cuttlefish/shared/config/sensors_config.json
{
  "sensors": [
    {
      "name": "virtual_temperature",
      "type": "temperature",
      "vendor": "Google",
      "version": 1,
      "maxRange": 100.0,
      "resolution": 0.1,
      "power": 0.5
    }
  ]
}

修改后重启模拟器，即可在adb shell dumpsys sensorservice中看到新传感器。

3.2.4 常见误区与总结

风险提示：模拟器无法验证传感器中断唤醒、低功耗模式等硬件相关功能。如果开发的是需要深度睡眠唤醒的传感器（如计步器），必须使用真机验证。另外，真机调试时务必确认设备已解锁bootloader，并刷入对应的userdebug版本系统。

总结：建议采用“模拟器先行、真机兜底”的策略。在HAL逻辑开发阶段使用模拟器快速迭代，在功能稳定后切换到真机进行硬件适配和性能验证。

3.3 交叉编译工具链配置

3.3.1 核心原理：Android的交叉编译体系

Android系统运行在ARM、x86等不同架构上，而开发主机通常是x86_64架构。交叉编译是指在x86主机上编译生成ARM架构的可执行文件。AOSP提供了完整的交叉编译工具链，位于prebuilts/gcc/linux-x86/aarch64/和prebuilts/clang/host/linux-x86/目录下。对于传感器HAL，我们主要使用Clang编译器，配合aarch64-linux-android-前缀的binutils工具。

3.3.2 操作流程：配置Android.bp编译传感器HAL

现代AOSP推荐使用Android.bp（Blueprint）文件定义模块。一个典型的传感器HAL模块配置如下：

// hardware/interfaces/sensors/2.1/default/Android.bp
cc_binary {
    name: "android.hardware.sensors@2.1-service",
    relative_install_path: "hw",
    vendor: true,
    srcs: ["sensors.cpp", "Sensor.cpp"],
    shared_libs: [
        "libbase",
        "libcutils",
        "liblog",
        "libutils",
        "libhardware",
        "libhidlbase",
        "libhidltransport",
        "android.hardware.sensors@2.1",
    ],
    cflags: ["-Wall", "-Werror"],
    arch: {
        arm: {
            compile_multilib: "32",
        },
        arm64: {
            compile_multilib: "64",
        },
    },
}

编译时，Soong会自动调用交叉编译工具链，生成对应架构的二进制文件。如果需要手动编译独立的测试程序，可以使用以下命令：

# 设置环境变量
export PATH=$AOSP/prebuilts/clang/host/linux-x86/clang-r450784d/bin:$PATH
export PATH=$AOSP/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin:$PATH
export CROSS_COMPILE=aarch64-linux-android-
export CC=aarch64-linux-android-clang

# 编译测试程序
aarch64-linux-android-clang++ -o sensor_test sensor_test.cpp -I$AOSP/system/core/libcutils/include

3.3.3 案例拆解：解决链接错误

在编译传感器HAL时，常见的错误是链接阶段找不到符号。例如，undefined reference to 'sensor_list'。这通常是因为没有链接正确的库。解决方案是检查Android.bp中的shared_libs是否包含了libhardware和libsensor。另一个常见问题是ABI不匹配，例如在64位系统上编译了32位的库。此时需要检查compile_multilib设置，确保与目标设备的ABI一致。

3.3.4 常见误区与总结

经验提醒：不要直接使用系统自带的gcc/g++编译Android HAL代码，因为Android的Bionic libc与glibc不兼容。务必使用AOSP提供的工具链。另外，编译时建议开启-Wall -Werror，将警告视为错误，避免潜在的内存问题。

总结：交叉编译工具链是HAL开发的“翻译官”，正确配置Android.bp文件是高效编译的关键。建议熟悉Blueprint语法，并掌握m、mmm、mm等编译命令的区别。

3.4 调试工具配置与实战

3.4.1 核心原理：adb、logcat、dmesg的分工

传感器HAL调试涉及三个层次的日志：adb负责设备通信与文件传输，logcat捕获用户空间（HAL、Framework）日志，dmesg查看内核空间（驱动）日志。三者配合可以完整追踪一条传感器数据从硬件中断到应用层上报的全链路。

3.4.2 操作流程：调试工具配置

adb配置：

# 添加USB设备权限
echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"' | sudo tee /etc/udev/rules.d/51-android.rules
sudo udevadm control --reload-rules
# 常用命令
adb devices
adb root
adb remount
adb shell

logcat过滤传感器日志：

# 查看所有传感器相关日志
adb logcat -s Sensors:V SensorsHAL:V
# 带时间戳和线程ID
adb logcat -v threadtime -s Sensors:V
# 保存到文件
adb logcat -d -f /data/local/tmp/sensor.log

dmesg查看内核日志：

# 实时查看内核日志
adb shell dmesg -w
# 过滤传感器驱动日志
adb shell dmesg | grep -i "sensor\|i2c\|irq"

3.4.3 案例拆解：传感器数据异常排查

场景：某款手机加速度计数据始终为0，但传感器服务已正常注册。

排查过程：

首先使用adb shell dumpsys sensorservice确认传感器是否注册成功，发现加速度计存在但数据为0。
使用adb logcat -s SensorsHAL:V查看HAL层日志，发现batch()和activate()调用正常，但poll()返回的数据结构体中的data[0]为0。
使用adb shell dmesg | grep -i "accel"查看内核日志，发现I2C读取失败：i2c_transfer failed: -6（NACK错误）。
进一步检查硬件连接，发现加速度计的I2C地址配置错误，在HAL的device_config中修正地址后，数据恢复正常。

复盘：该问题涉及HAL、内核、硬件三层，通过logcat和dmesg的配合，快速定位到I2C通信层。建议在HAL代码中增加详细的错误日志，包括I2C地址、寄存器地址和错误码，便于快速定位。

3.4.4 常见误区与总结

风险提示：不要在生产环境中使用adb root和adb remount，这会破坏系统分区完整性。调试完成后应执行adb unroot并重新锁定设备。另外，logcat日志缓冲区有限，长时间抓取日志可能导致旧日志被覆盖，建议使用adb logcat -G 16M增大缓冲区。

总结：调试工具是HAL开发的“眼睛”，熟练掌握adb、logcat、dmesg的配合使用，可以大幅缩短问题定位时间。建议在开发初期就建立标准化的日志规范，在HAL代码中统一使用ALOGI/ALOGD/ALOGE输出关键信息。

  本章要点回顾：AOSP源码下载与编译是基础，建议使用镜像源并掌握模块级编译；模拟器适合逻辑验证，真机适合硬件适配；交叉编译工具链必须使用AOSP自带版本；调试工具中adb负责通信、logcat管用户空间、dmesg管内核空间，三者缺一不可。下一章将深入传感器HAL接口定义与实现框架。