4、开发环境搭建：配置AOSP源码环境、交叉编译工具链、模拟器与真机调试环境的准备

Android音频HAL开发是一项对工程环境高度敏感的工作。无论是编写一个简单的codec驱动封装，还是调试复杂的音频路由策略，开发环境的稳定性、版本匹配度和调试链路的完整性，直接决定了开发效率与问题定位的准确性。本章将围绕AOSP源码环境的配置、交叉编译工具链的搭建、模拟器与真机调试环境的准备四个核心维度展开，帮助开发者构建一套可复现、可扩展、可高效排障的音频HAL开发底座。

4.1 AOSP源码环境配置：版本选择与repo同步策略

音频HAL开发必须基于完整的AOSP源码树，因为HAL接口定义（如hardware/libhardware/include/hardware/audio.h）、AudioFlinger服务实现以及AudioPolicy引擎均与系统版本强耦合。选择AOSP分支时，需根据目标设备的Android版本确定，例如Android 13对应android-13.0.0_rXX分支，Android 14对应android-14.0.0_rXX分支。不建议使用master分支进行产品级HAL开发，因为其API变动频繁且缺乏稳定性验证。

源码同步的核心操作流程如下：

1. 安装依赖包：执行sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig，确保编译工具链完整。
2. 安装repo工具：mkdir ~/bin && curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo && chmod a+x ~/bin/repo，并将~/bin加入PATH。
3. 初始化仓库：repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_rXX，建议使用国内镜像（如清华TUNA、中科大USTC）加速。
4. 同步源码：repo sync -c -j8，其中-c表示只同步当前分支，-j8为并行任务数，需根据CPU核心数调整。

4.2 交叉编译工具链：从源码到目标库的完整链路

Android音频HAL以共享库形式（audio.primary.<board>.so）运行在目标设备上，必须使用AOSP提供的交叉编译工具链。AOSP使用Clang/LLVM作为默认编译器，通过Soong构建系统（Android.bp文件）管理编译规则。与传统的Makefile不同，Soong强制要求模块声明依赖关系，这有助于减少隐式依赖带来的链接错误。

交叉编译工具链的核心配置要点如下：

• 环境初始化：执行source build/envsetup.sh后，使用lunch选择目标产品配置。对于音频HAL开发，通常选择aosp_arm64-eng或aosp_blueline-eng（Pixel 3模拟器对应配置）。
• 编译单个模块：m audio.primary.$(TARGET_BOARD_PLATFORM)，其中TARGET_BOARD_PLATFORM在build/target/board/<board>/BoardConfig.mk中定义。例如高通平台为msmnile，三星平台为exynos990。
• 输出产物路径：编译后的.so文件位于out/target/product/<device>/system/lib64/hw/（64位）或system/lib/hw/（32位）。

# 典型Android.bp音频HAL模块定义
cc_library_shared {
    name: "audio.primary.goldfish",
    vendor: true,
    srcs: ["audio_hw.c", "audio_hw_utils.c"],
    shared_libs: [
        "libaudioroute",
        "libaudioutils",
        "libcutils",
        "libhardware",
        "liblog",
        "libtinyalsa",
        "libtinycompress",
    ],
    cflags: ["-Wno-unused-variable", "-Wno-unused-parameter"],
    local_include_dirs: ["include"],
}

交叉编译的常见误区在于混淆主机编译与目标编译。主机编译（如编译host工具）使用x86_64 GCC，而目标编译必须使用clang并指定--target=aarch64-linux-android。AOSP的Soong系统已自动处理这些参数，开发者不应手动修改CC或CXX环境变量，否则会导致编译失败或运行时ABI不兼容。

4.3 模拟器调试环境：Cuttlefish与Goldfish音频后端

模拟器是音频HAL开发初期验证的首选环境，尤其适用于无硬件板卡的场景。AOSP官方推荐使用Cuttlefish模拟器（aosp_cf_x86_64_phone），它支持嵌套虚拟化（KVM），启动速度快，且音频后端通过虚拟ALSA设备实现。Goldfish是旧版模拟器内核，其音频HAL实现位于device/generic/goldfish/audio/目录，代码结构简单，适合学习HAL框架。

模拟器调试环境的搭建步骤如下：

1. 编译模拟器镜像：m -j8 aosp_cf_x86_64_phone，编译完成后镜像位于out/target/product/vsoc_x86_64/。
2. 启动模拟器：launch_cvd --daemon，或使用emulator -avd test_avd -no-window -no-audio（无窗口模式）。
3. 验证音频设备：adb shell cat /proc/asound/cards，应能看到goldfish_audio或virtio_snd设备。
4. 测试音频通路：使用adb shell tinyplay /sdcard/test.wav播放音频，使用tinycap /sdcard/record.wav -D 0 -d 0 -c 2 -r 48000 -b 16录音。

4.4 真机调试环境：fastboot刷机与ADB调试链路

真机调试是音频HAL开发的最终验证环节。与模拟器不同，真机环境涉及Bootloader解锁、内核模块加载、SELinux策略、Vendor分区挂载等多个环节。以Pixel系列设备为例，真机调试环境的准备流程如下：

• 解锁Bootloader：fastboot flashing unlock，注意此操作会清除设备数据。
• 编译并刷入系统镜像：m -j8编译完整系统，然后fastboot flashall -w刷入所有分区（-w表示清除用户数据）。
• 验证HAL加载：adb shell lsof | grep audio.primary确认HAL库被AudioFlinger进程加载。
• 查看音频日志：adb logcat -v threadtime | grep -E "AudioFlinger|AudioHAL|audio_hw"。

# 真机音频调试常用命令
# 查看当前音频设备
adb shell dumpsys media.audio_flinger | grep -A 5 "Output thread"
# 查看ALSA PCM配置
adb shell cat /proc/asound/card0/pcm0p/sub0/hw_params
# 使用tinymix查看codec寄存器
adb shell tinymix | grep -E "RX|TX|DAC|ADC"
# 抓取音频HAL层Systrace
adb shell atrace --async_start -c -b 4096 audio
adb shell atrace --async_stop -c -o /data/local/tmp/trace.dat

真机调试的另一个关键点是SELinux策略。AOSP默认启用SELinux enforcing模式，HAL进程（如audioserver）对设备节点（/dev/snd/*）的访问权限受限于system/sepolicy中的te规则。若HAL尝试打开未授权的ALSA设备，会收到Permission denied错误。此时需在system/sepolicy/private/audioserver.te中添加allow audioserver audio_device:chr_file rw_file_perms;等规则，并重新编译boot.img。

最后，无论是模拟器还是真机，建议在开发环境中配置统一的脚本化调试工具集，包括自动抓取logcat、dmesg、tinymix状态、dumpsys音频服务信息的脚本，以便在问题复现时快速收集完整现场数据。这能显著缩短音频HAL问题的定位周期。