高通音频架构：从 AHAL adev_open 到 PAL XML 解析的调用链追踪

2. 核心调用链路总览

首先，我们通过一张时序图直观地看下整个调用过程：

ResourceManager (PAL Core) -> Pal.cpp (PAL API) -> AudioDevice (AHAL) -> AudioFlinger

1. 打印日志：adev_open 2650...
2. 触发单例构造函数
3. 打印日志：XML parsing started...
4. adev_open() (通过 hw_module->methods->open)
5. adevice->Init()
6. pal_init()
7. ResourceManager::getInstance()
8. ResourceManager::ResourceManager()
9. ResourceManager::XmlParser("/vendor/etc/card-defs.xml")

3. 源码级解析

第一阶段：AHAL 的入口 adev_open

当 Android 的 AudioFlinger 通过 audio hal 加载厂商的 audio.primary.xxx.so 时，会通过 HAL 框架调用 .open 接口。在高通的实现中，这个函数位于 AudioDevice.cpp。

文件路径：vendor/qcom/opensource/audio-hal-ar/primary-hal/hal-pal/AudioDevice.cpp

// 源码位置：AudioDevice.cpp 约 2622 行
static int adev_open(const hw_module_t *module,
                     const char* name __unused, 
                     hw_device_t **device) {
    // ...
    // 关键点 1：打印第一条日志
    property_get("vendor.audio.hal.log_type", ahal_log_type, "");
    ALOGI("%s %d ahal_log_lvl 0x%x", __func__, __LINE__, ahal_log_lvl);
    
    std::shared_ptr<AudioDevice> adevice = AudioDevice::GetInstance();
    
    // ...
    // 关键点 2：调用 Init 函数
    ret = adevice->Init(device, module);
    // ...
}

第二阶段：从 AHAL 跨越到 PAL

在 AudioDevice::Init 函数中，高通 AHAL 会初始化其核心引擎——PAL (Platform Audio Layer)。

文件路径：vendor/qcom/opensource/audio-hal-ar/primary-hal/hal-pal/AudioDevice.cpp

// 源码位置：AudioDevice.cpp 约 1077 行
int AudioDevice::Init(hw_device_t **device, const hw_module_t *module) {
    int ret = 0;
    // ...
    // 关键点 3：调用 PAL 库的初始化入口
    ret = pal_init();
    if(ret) {
        AHAL_ERR("pal_init failed ret=(%d)", ret);
        return -EINVAL;
    }
    // ...
}

第三阶段：PAL 内部单例触发

pal_init() 是 PAL 库暴露给 AHAL 的标准 API。它的职责是拉起 PAL 内部的资源管理器 ResourceManager。

文件路径：vendor/qcom/opensource/pal/Pal.cpp

// 源码位置：Pal.cpp
int32_t pal_init(void) {
    int32_t ret = 0;
    std::shared_ptr<ResourceManager> ri = NULL;
    try {
        // 关键点 4：获取 ResourceManager 单例
        // 如果是开机后第一次调用，将触发 ResourceManager 的构造函数
        ri = ResourceManager::getInstance();
    } catch(const std::exception& e) {
        PAL_ERR(LOG_TAG, "pal init failed: %s", e.what());
        return -EINVAL;
    }
    // ...
}

第四阶段：ResourceManager 构造与 XML 解析

由于 ResourceManager 是单例模式，getInstance() 会执行 new ResourceManager()。在这个构造函数中，系统会根据配置文件初始化所有的音频路由、设备和策略。

文件路径：vendor/qcom/opensource/pal/resource_manager/src/ResourceManager.cpp

// 源码位置：ResourceManager.cpp 约 683 行
ResourceManager::ResourceManager() {
    int ret = 0;
    // ... 各种属性初始化 ...
    
    // 关键点 5：解析第一个 XML (通常是 resourcemanager.xml)
    ret = ResourceManager::XmlParser(SNDPARSER);
    
    // 关键点 6：解析第二个 XML (即日志中看到的 card-defs.xml)
    // rmngr_xml_file 的路径通常指向 /vendor/etc/card-defs.xml
    ret = ResourceManager::XmlParser(rmngr_xml_file);
    if(ret) {
        PAL_ERR(LOG_TAG, "error in resource xml parsing ret %d", ret);
        throw std::runtime_error("error in resource xml parsing");
    }
    // ...
}

// 真正打印日志的地方
int ResourceManager::XmlParser(std::string xmlFile) {
    // 源码位置：ResourceManager.cpp 约 10897 行
    PAL_INFO(LOG_TAG, "XML parsing started - file name %s", xmlFile.c_str());
    // ... 开始解析逻辑 ...
}

4. 深度解析 card-defs.xml：PAL 的硬件资源底座

在上面的 Log 2 中，我们看到了 card-defs.xml 被解析。这个文件到底起到了什么作用？

4.1 XML 标签与源码 C++ 映射关系

当 ResourceManager::XmlParser 被调用后，它会利用 libxml2 遍历文件。核心的解析逻辑位于 ResourceManager::processDeviceIdProp 等函数中。

4.2 标签背后的源码逻辑实现

以解析 <bus_name> 为例：

// ResourceManager.cpp
void ResourceManager::processDeviceIdProp(struct xml_userdata* data, const XML_Char *tag_name) {
    // ...
} else if (!strcmp(tag_name, "bus_name")) {
    // 将 XML 里的 "BUS00_MEDIA" 拷贝到 ext_name 字段
    strlcpy(devInfo[size].ext_name, data->data_buf, strlen(data->data_buf)+1);
    
    // 设置标志位，标识这是一个 Bus 类型的设备
    devInfo[size].device_flag = BUS_NAME_FLAG;
    
    PAL_INFO(LOG_TAG, "find bus card %s bind to %d", data->data_buf, devInfo[size].deviceId);
}
// ...

4.3 card-defs.xml 的核心作用：桥梁与清单

1. 作为'硬件配置清单'：它告知 PAL 这一代芯片（如 sa8295）到底开放了多少个虚拟 PCM 端口（100 号到 155 号）。
2. 实现'逻辑到物理'的路由映射：
   • Android 框架层通过 Audio Bus 寻址（逻辑地址）。
   • 底层驱动通过 PCM ID 传输数据（物理 ID）。
   • card-defs.xml 里的 <bus_name> 标签正是这两者之间的强绑定关系。当 AudioPolicy 请求 Media 播放时，系统通过查这张'表'，知道该去敲 124 号 PCM 的大门。
3. 定义'会话模式'：通过 session_mode 标签，区分了普通播放通道（DEFAULT）和用于特殊处理的通道（如 HOSTLESS：不需要 CPU 参与的直接通路）。

5. 总结

那 30 微秒的跨度，完成了从 Android 原生 HAL 接口调用 到 厂商私有硬件描述解析 的华丽转身。

• AHAL 只负责'迎宾'，它遵守 Android 的标准协议。
• PAL 才是'内管家'，它通过解析 card-defs.xml 来掌控整个声卡的硬件拓扑。

通过这种'XML 定义拓扑，源码执行逻辑'的架构，高通实现了同一套代码支持不同变体芯片（如 sa8155 vs sa8295）的灵活性。

参考源码路径：

• vendor/qcom/opensource/audio-hal-ar/primary-hal/hal-pal/AudioDevice.cpp
• vendor/qcom/opensource/pal/Pal.cpp
• vendor/qcom/opensource/pal/resource_manager/src/ResourceManager.cpp