【车载audio】【AudioFlinger 01】【从 audio_policy_configuration.xml 静态配置到 mHwModulesAll 动态加载的全生命周期】

深入解析 Android 音频系统：从 audio_policy_configuration.xml 静态配置到 mHwModulesAll 动态加载的全生命周期

1. 序言：音频系统的“蓝图”与“基石”

在 Android 音频架构中，audio_policy_configuration.xml绝非简单的文本文件，它是整个音频策略管理器（AudioPolicyManager, 简称 APM）的“施工蓝图”。它定义了系统支持哪些硬件模块、具备哪些播放/录音能力以及设备间的物理链路。

本文将从源码视角出发，深度剖析 Android 如何将这一纸蓝图，转化为内存中核心数据结构mHwModulesAll，并最终驱动硬件发出声音。

2. 核心架构图解：从配置文件到内存对象

在系统启动时，音频策略的加载遵循“解析 -> 映射 -> 探测”的闭环逻辑：

3. 标签与源码的灵魂契约：XML 元素如何对应 C++ 类

当Serializer.cpp遍历 XML 树时，每一个标签都会在堆内存中实例化为一个特定的 C++ 对象。

3.1 模块映射：<module>->HwModule

每个<module>（如primary,usb）对应一个HwModule对象。它是音频驱动加载的最小单位。

• 源码逻辑：HwModule内部持有一个mProfiles集合，用于存储该模块所有的输入输出能力。

3.2 接口映射：<mixPort>->IOProfile

代表软件侧的音频流描述符。

• 关键属性：role="source"对应播放（Output），role="sink"对应录音（Input）。
• 代码对应：解析后存入HwModule->mProfiles。

3.3 设备映射：<devicePort>->DeviceDescriptor

代表硬件侧的物理接口。

• 地址识别：address="BUS00_MEDIA"这类属性会被解析并用于后续的路由寻址。

4. 深度专题：关键配置的源码级实现

4.1<attachedDevices>：谁是“常驻嘉宾”？

XML 配置：

<attachedDevices><item>Media Bus</item><item>Sys Notification Bus</item></attachedDevices>

源码逻辑（Serializer.cpp）：
解析器读取到这些 item 后，会调用DeviceDescriptor->setAttached(true)。

• 意义：这标志着该设备物理上不可拆卸。在探测阶段，只有标记为attached的设备，才会被系统认为开机即处于AVAILABLE状态。

4.2<defaultOutputDevice>：系统的最后防线

源码实现（AudioPolicyManager.cpp）：
APM 内部维护一个sp<DeviceDescriptor> mDefaultOutputDevice指针。在initialize()过程中，如果系统发现默认设备不可达，会触发ALOGE报错。它是所有音频路由决策的“保底”选择。

4.3 动态参数抉择：samplingRates与channelMasks

多值存储：
源码中使用SampleRateVector（本质是std::vector<uint32_t>）存储如44100,48000这样的列表。

选择逻辑（IOProfile.cpp）：
当 App 请求 48k 采样率播放时，系统会调用profile->isCompatibleConfig(...)：

// 源码简述：遍历 Vector 寻找是否存在匹配值if(std::find(mSamplingRates.begin(),mSamplingRates.end(),requestedRate)!=mSamplingRates.end()){returntrue;// 匹配成功，该通道可用}

• 特殊情况：如果 App 未指定参数，系统默认选取 Vector 中的第一个值作为最优解。

5. 核心逻辑：mHwModulesAll 的初始化与“试运行”

5.1 初始化机制：引用传递的奥秘

很多开发者找不到mHwModulesAll = mConfig->getHwModules()这样的直接赋值。这是因为在现代 AOSP 中，它是通过构造函数初始化列表完成的：

// AudioPolicyManager.cpp 构造函数AudioPolicyManager::AudioPolicyManager(AudioPolicyClientInterface*clientInterface):...mConfig(mHwModulesAll,mOutputDevicesAll,mInputDevicesAll,mDefaultOutputDevice){// 这里 mConfig 持有了 mHwModulesAll 的引用。// 当执行 deserializeAudioPolicyXmlConfig 时，数据直接填充进了 mHwModulesAll。}

5.2 探测期：onNewAudioModulesAvailableInt

这是 APM 启动时最繁忙的时刻。它会针对mHwModulesAll里的每个模块执行：

1. loadHwModule：真正加载.so驱动库。
2. “试开流”（Probing）：调用outputDesc->open(...)。
   • 深度细节：即便 XML 写了支持 192k 采样率，如果此时硬件 HAL 反馈打开失败，系统会跳过该通道，确保不会将声音发往一个“坏死的”硬件通路。
3. 正式挂载：验证通过后，设备才会被添加到mAvailableOutputDevices。

6. 路由链路：<routes>的桥接作用

<routetype="mix"sink="Media Bus"sources="media"/>

这是 MixPort 和 DevicePort 之间的逻辑开关。

• 源码校验：当建立音频补丁（Audio Patch）时，系统会检索HwModule->mRoutes。如果没有在 XML 中显式定义这条路径，即便底层驱动支持，APM 也会因为找不到路由而拒绝建立连接。

7.audio_policy_configuration.xml 参考

<modules><modulename="primary"halVersion="3.0"><attachedDevices><item>Media Bus</item><item>Sys Notification Bus</item><item>Nav Guidance Bus</item><item>Phone Bus</item><item>Alerts Bus</item></attachedDevices><defaultOutputDevice>Media Bus</defaultOutputDevice><mixPorts><mixPortname="media"role="source"flags="AUDIO_OUTPUT_FLAG_PRIMARY"><profilename=""format="AUDIO_FORMAT_PCM_16_BIT"samplingRates="48000"channelMasks="AUDIO_CHANNEL_OUT_STEREO"/></mixPort><mixPortname="sys_notification"role="source"><profilename=""format="AUDIO_FORMAT_PCM_16_BIT"samplingRates="48000"channelMasks="AUDIO_CHANNEL_OUT_STEREO"/></mixPort><mixPortname="nav_guidance"role="source"><profilename=""format="AUDIO_FORMAT_PCM_16_BIT"samplingRates="48000"channelMasks="AUDIO_CHANNEL_OUT_STEREO"/></mixPort></mixPorts><devicePorts><devicePorttagName="Media Bus"role="sink"type="AUDIO_DEVICE_OUT_BUS"address="BUS00_MEDIA"><profilename=""format="AUDIO_FORMAT_PCM_16_BIT"samplingRates="48000"channelMasks="AUDIO_CHANNEL_OUT_STEREO"/><gains><gainname=""mode="AUDIO_GAIN_MODE_JOINT"minValueMB="-6000"maxValueMB="600"defaultValueMB="0"stepValueMB="100"/></gains></devicePort><devicePorttagName="Sys Notification Bus"role="sink"type="AUDIO_DEVICE_OUT_BUS"address="BUS01_SYS_NOTIFICATION"><profilename=""format="AUDIO_FORMAT_PCM_16_BIT"samplingRates="48000"channelMasks="AUDIO_CHANNEL_OUT_STEREO"/><gains><gainname=""mode="AUDIO_GAIN_MODE_JOINT"minValueMB="-6000"maxValueMB="600"defaultValueMB="0"stepValueMB="100"/></gains></devicePort><devicePorttagName="Nav Guidance Bus"role="sink"type="AUDIO_DEVICE_OUT_BUS"address="BUS02_NAV_GUIDANCE"><profilename=""format="AUDIO_FORMAT_PCM_16_BIT"samplingRates="48000"channelMasks="AUDIO_CHANNEL_OUT_STEREO"/><gains><gainname=""mode="AUDIO_GAIN_MODE_JOINT"minValueMB="-6000"maxValueMB="600"defaultValueMB="0"stepValueMB="100"/></gains></devicePort></devicePorts><routes><routetype="mix"sink="Media Bus"sources="media"/><routetype="mix"sink="Sys Notification Bus"sources="sys_notification"/><routetype="mix"sink="Nav Guidance Bus"sources="nav_guidance"/><routetype="mix"sink="Phone Bus"sources="phone,mmap_no_irq_out"/><routetype="mix"sink="Alerts Bus"sources="alerts"/></routes></module><!-- Bluetooth Audio HAL --><xi:includehref="bluetooth_audio_policy_configuration.xml"/><!-- Usb Audio HAL --><xi:includehref="/vendor/etc/audio_ar/usb_audio_policy_configuration.xml"/><!-- Remote Submix Audio HAL --><xi:includehref="r_submix_audio_policy_configuration.xml"/></modules>

8. 总结：设计哲学

Android 音频策略架构的设计核心是**“静态约束与动态验证的统一”**：

• XML提供了静态的约束和能力边界。
• mHwModulesAll承载了完整的静态蓝图。
• onNewAudioModulesAvailableInt提供了动态的存活验证。

这种设计使得 OEM 厂商只需通过修改 XML 配置文件，就能支持千变万化的硬件拓扑，而无需修改一行 C++ 核心代码。这正是 Android Treble 架构高内聚、低耦合理念的完美体现。