从 AHAL adev_open 到 PAL XML 解析:30 微秒内的调用链追踪
1. 问题的引入
在分析 Android 音频系统启动日志时,我们经常会看到两条紧挨着的日志,时间间隔极其微小(本例中仅为 30 微秒):
02-11 10:35:14.248370 698 698 I AHAL: AudioDevice:
本文分析了 Android 车载音频系统启动时,AHAL 层调用 adev_open 后触发 PAL 层 XML 解析的调用链路。通过源码追踪发现,30 微秒内完成了从 HAL 接口到 ResourceManager 单例初始化及 card-defs.xml 配置加载的过程。重点解析了 card-defs.xml 中 bus_name 与 PCM ID 的映射逻辑,阐述了高通音频架构如何通过 XML 定义硬件拓扑以实现芯片适配灵活性。
在分析 Android 音频系统启动日志时,我们经常会看到两条紧挨着的日志,时间间隔极其微小(本例中仅为 30 微秒):
02-11 10:35:14.248370 698 698 I AHAL: AudioDevice:
AHAL (Audio HAL) 刚说要 open,PAL (Platform Audio Layer) 紧接着就开始解析 XML 配置文件了。这中间到底发生了什么?是谁触发了 PAL 的加载?本文将通过源码深度揭秘。
首先,我们通过一张时序图直观地看下整个调用过程:
ResourceManager (PAL Core) -> Pal.cpp (PAL API) -> AudioDevice (AHAL) -> AudioFlinger
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);
// ...
}
在 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_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 是单例模式,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());
// ... 开始解析逻辑 ...
}
在上面的 Log 2 中,我们看到了 card-defs.xml 被解析。这个文件到底起到了什么作用?
当 ResourceManager::XmlParser 被调用后,它会利用 libxml2 遍历文件。核心的解析逻辑位于 ResourceManager::processDeviceIdProp 等函数中。
| XML 标签 | 源码解析函数 | 对应的 C++ 数据结构 / 逻辑 |
|---|---|---|
<card> | startTagHandler | 开启一个新的声卡定义(虚拟声卡概念)。 |
<pcm-device> | processDeviceIdProp | 创建一个新的 deviceCap 结构体,存入 devInfo 容器。 |
<id> | processDeviceIdProp | 存储为 deviceId(如 124),对应底层的 PCM 端口 ID。 |
<bus_name> | processDeviceIdProp | 关键映射点:将逻辑 Bus(如 BUS00_MEDIA)与物理 ID 绑定。 |
<props> | processDeviceCapability | 解析播放(playback)、录音(capture)及会话模式(session_mode)。 |
以解析 <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);
}
// ...
card-defs.xml 里的 <bus_name> 标签正是这两者之间的强绑定关系。当 AudioPolicy 请求 Media 播放时,系统通过查这张'表',知道该去敲 124 号 PCM 的大门。session_mode 标签,区分了普通播放通道(DEFAULT)和用于特殊处理的通道(如 HOSTLESS:不需要 CPU 参与的直接通路)。那 30 微秒的跨度,完成了从 Android 原生 HAL 接口调用 到 厂商私有硬件描述解析 的华丽转身。
card-defs.xml 来掌控整个声卡的硬件拓扑。通过这种'XML 定义拓扑,源码执行逻辑'的架构,高通实现了同一套代码支持不同变体芯片(如 sa8155 vs sa8295)的灵活性。
参考源码路径:
vendor/qcom/opensource/audio-hal-ar/primary-hal/hal-pal/AudioDevice.cppvendor/qcom/opensource/pal/Pal.cppvendor/qcom/opensource/pal/resource_manager/src/ResourceManager.cpp
微信公众号「极客日志」,在微信中扫描左侧二维码关注。展示文案:极客日志 zeeklog
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具,Base64 字符串编码/解码在线工具,online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具,Base64 文件转换器在线工具,online
将 Markdown(GFM)转为 HTML 片段,浏览器内 marked 解析;与 HTML 转 Markdown 互为补充。 在线工具,Markdown 转 HTML在线工具,online
将 HTML 片段转为 GitHub Flavored Markdown,支持标题、列表、链接、代码块与表格等;浏览器内处理,可链接预填。 在线工具,HTML 转 Markdown在线工具,online
通过删除不必要的空白来缩小和压缩JSON。 在线工具,JSON 压缩在线工具,online
将JSON字符串修饰为友好的可读格式。 在线工具,JSON美化和格式化在线工具,online