<think>我们正在讨论
Android音频系统中的
音频策略
配置文件加载流程。
audio_
policy_
configuration.xml是
Android音频策略的核心
配置文件，它定义了
音频硬件模块、设备、路由策略等关键信息。加载流程涉及多个组件，包括
AudioPolicyService、
AudioPolicyManager等。
加载流程详细步骤：
1
. **系统启动阶段**：
- 当系统启动时，
AudioPolicyService（APS）作为系统服务被初始化（通常在`SystemServer`中启动）。
- APS在构造函数中会创建
AudioPolicyManager（APM）实例。
2
. **
配置文件定位**：
- APS通过`getConfig()`函数确定
配置文件的路径。通常，系统会尝试从多个路径加载
配置文件，优先级顺序为：
- 厂商覆盖配置：`/vendor/etc/
audio_
policy_
configuration.xml`
- 系统默认配置：`/system/etc/
audio_
policy_
configuration.xml`
- 如果存在`
audio_
policy_
configuration_<device>
.xml`（其中`<device>`为设备特定标识），则加载该文件。
3
. **
解析配置文件**：
- 使用`lib
xml2`
解析选定的
XML文件。
- 解析过程由`
AudioPolicyManager`的`loadConfig()`方法（或类似方法）完成，该方法会遍历
XML中的各个节点：
- `<modules>`：定义
音频硬件模块（如primary, a2dp, usb等）。
- `<devicePorts>`：定义输入输出设备（如扬声器、耳机、麦克风等）。
- `<mixPorts>`：定义
音频流类型（如music, voice_call）及其属性（采样率、声道等）。
- `<routes>`：定义
音频路由策略（设备之间的连接关系）。
- `<attachedDevices>`：定义默认连接的设备。
4
. **配置验证与构建**：
- 解析后的配置数据会转化为内部数据结构（如`HwModuleCollection`、`DeviceVector`等）。
- 进行有效性检查，例如确保所有引用的设备端口都存在。
5
. **加载
音频模块**：
- 对于每个在
配置文件中定义的`<module>`，APM通过`
AudioPolicyClient`接口（即APS）调用`
AudioFlinger`来加载对应的动态库（如`primary
.audio.so`）。
- 加载过程通过`hwLoadModule()`函数完成，该函数使用`dlopen`打开动态库并获取`create_module`函数来创建
音频模块实例。
6
. **初始化
音频设备**：
- 加载模块后，APM会查询模块支持的设备列表，并与
配置文件中的设备进行匹配。
- 初始化设备的默认状态（如关闭状态）。
7
. **构建策略引擎**：
- 根据
解析的路由策略，构建
音频路由图（
Audio Route Graph）。
- 设置默认输出/输入设备。
8
. **处理配置变更**：
- 如果系统检测到
配置文件变化（如OTA升级后），APS会重新加载
配置文件并重建策略引擎（但实际中很少动态重载）。
代码关键点（简化版）：
```cpp
//
AudioPolicyManager 加载配置
status_t
AudioPolicyManager::loadConfig() {
audio_
policy::EngineConfig config;
if (deserialize
AudioPolicyXmlConfig(getConfigPath(), &config) != NO_ERROR) {
//
解析失败则使用默认配置
}
// 将
解析的数据转换为内部结构
for (const auto& moduleConfig : config
.modules) {
sp<HwModule> module = new HwModule(moduleConfig
.name);
// 填充设备端口、混音端口等
...
}
// 加载硬件模块
for (size_t i = 0; i < mHwModules
.size(); i++) {
mHwModules[i]
->mHandle = mClient
->hwLoadModule(mHwModules[i]
->getName());
}
}
```
9
. **错误处理**：
- 如果加载失败，系统可能回退到基本配置（如只有主
音频模块）或导致
音频服务无法启动。
注意：从
Android 10开始，
配置文件结构有所变化，引入了`
audio_
policy_
configuration.xsd`验证架构，并支持多
配置文件（通过`<xi:include>`合并）。
§§相关问题§§
1
. 当系统存在多个候选的
audio_
policy_
configuration.xml文件时，具体的加载优先级顺序是怎样的？
2
. 在
解析配置文件过程中，如何处理<xi:include>标签引入的子
配置文件？
3
. 如果
配置文件中定义的某个
音频模块无法动态加载（如so库缺失），系统会采取什么容错机制？
4
. AudioPolicyManager在加载配置后如何通知其他子系统（如
AudioFlinger）配置已更新？
5
. 在
Android的Treble架构下，
音频策略
配置文件的加载流程有哪些变化？</think>###
Android音频策略
配置文件加载流程详解
`
audio_
policy_
configuration.xml`是
Android音频系统的核心策略
配置文件，其加载流程涉及多级
解析和策略引擎初始化。以下是完整加载流程（基于
Android 12+）：
#### **1
. 配置文件定位阶段**
- **优先级路径搜索**（由`
AudioPolicyManager`执行）：
1
. `/vendor/etc/
audio_
policy_
configuration.xml`（厂商定制配置）
2
. `/odm/etc/
audio_
policy_
configuration.xml`（设备制造商配置）
3
. `/system/etc/
audio_
policy_
configuration.xml`（AOSP默认配置）
- **多
配置文件支持**：
```
xml
<xi:include href="primary_
audio_
policy_
configuration.xml"/> <!
-- 模块化子配置
-->
<xi:include href="a2dp_
audio_
policy_
configuration.xml"/>
```
#### **2
. 配置文件解析阶段**
**
解析入口**：`
AudioPolicyManager::loadConfig()`
```cpp
// 代码位置：
frameworks/av/services/
audiopolicy/managerdefault/
AudioPolicyManager.cpp
status_t
AudioPolicyManager::loadConfig() {
auto result = deserialize
AudioPolicyXmlConfig(getConfigPath(), &mConfig);
if (result != NO_ERROR) return result;
//
解析引擎配置
mEngine
->load
AudioPolicyEngineConfig(mConfig);
}
```
**关键
解析节点**：
|
XML节点 |
解析对象 | 功能 |
|
---------|
----------|
------|
| `<modules>` | `HwModuleCollection` | 硬件模块定义（primary/USB/蓝牙等） |
| `<devicePorts>` | `DeviceDescriptor` | 物理设备描述（扬声器/耳机/麦克风） |
| `<mixPorts>` | `IOProfile` |
音频流I/O通道配置 |
| `<routes>` | `
AudioRoute` | 设备间路由策略（如耳机自动切换） |
| `<attachedDevices>` | `DeviceVector` | 默认连接的物理设备 |
#### **3
. 策略引擎初始化阶段**
- **动态模块加载**：
```cpp
for (const auto& module : mConfig
.modules) {
// 加载硬件模块动态库（如
audio.primary
.so）
mHwModules
.add(loadHwModule(module
.name));
}
```
- **路由图构建**：
```mermaid
graph LR
A[
解析mixPorts]
--> B(创建输入/输出流模板)
C[
解析devicePorts]
--> D(创建设备能力描述)
E[
解析routes]
--> F(构建设备间路由矩阵)
B
--> G[生成
音频路由图]
D
--> G
F
--> G
```
#### **4
. 策略生效阶段**
- **设备状态同步**：
- 调用`setDeviceConnectionState()`同步当前物理设备状态
- 触发`on
AudioPortListUpdate()`通知配置变更
- **默认策略激活**：
```cpp
// 设置默认输出设备（如扬声器）
setForceUse(
AUDIO_
POLICY_FORCE_FOR_MEDIA,
AUDIO_
POLICY_FORCE_SPEAKER);
// 初始化音量曲线
initStreamVolume(
AUDIO_STREAM_MUSIC, 0, MAX_STREAM_VOLUME[DEVICE_CATEGORY_SPEAKER]);
```
#### **5
. 热更新机制**
- **配置变更监听**：
```cpp
// 监听/vendor/etc/目录变更
inotify_add_watch(mConfigFileDir, IN_MODIFY);
```
- **动态重载流程**：
1
. 收到`IN_MODIFY`事件后等待500ms（防抖动）
2
. 调用`loadConfig()`重新
解析配置文件
3
. 通过`
AudioSystem::set
AudioPortConfig()`应用新策略
#### **6
. 错误处理机制**
| 错误类型 | 处理方式 |
|
----------|
----------|
|
XML格式错误 | 回退到`/system/etc/`默认配置 |
| 模块加载失败 | 跳过该模块并记录`ALOGE()` |
| 路由冲突 | 按优先级保留首个有效路由 |
**完整流程时序图**：
```mermaid
sequenceDiagram
participant APS as
AudioPolicyService
participant APM as
AudioPolicyManager
participant
XMLP as
XML Parser
participant AF as
AudioFlinger
APS
->>APM: 创建实例时调用loadConfig()
APM
->>
XMLP:
解析/vendor/etc/
audio_
policy_
configuration.xml
XMLP
->>APM: 返回Config结构体
APM
->>APM: 构建HwModuleCollection
APM
->>AF: loadHwModule("primary")
AF
-->>APM: 返回
audio_hw_device_t
APM
->>APM: 构建
AudioRouteMap
APM
->>APS: 触发on
AudioPortListUpdate()
APS
->>Client: 广播配置变更通知
```
超级会员免费看
本文详细解析了Android 7.0中音频配置文件audio_policy_configuration.xml的结构、优势及解析过程，包括XML格式的优势，文件的位置和格式，以及AudioPolicyManager如何处理XML配置。
订阅专栏 解锁全文
扫一扫
641
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
