第九章：音频策略服务（AudioPolicyService）：策略决策、路由管理、动态策略加载
各位同学，今天我们来聊聊 AudioPolicyService。说实话，这是整个 Android 音频系统里最容易被低估的一个模块。很多人一上来就盯着 AudioFlinger 看，觉得混音、重采样才是硬核技术。但我要说，没有 AudioPolicyService，AudioFlinger 就是个只会蛮力的莽夫——它不知道声音该往哪走，也不知道什么时候该切换设备。
我个人习惯把 AudioPolicyService 比作音频系统的「交通指挥中心」。它不负责具体的音频数据处理，但它决定了每一路音频流的走向。你插上耳机，音乐自动从耳机出声；你拔掉耳机，外放立刻接管——这些看似理所当然的操作，背后都是 AudioPolicyService 在调度。
9.1 策略决策：谁的声音更重要？
先问一个问题：当你在导航语音播报的同时听音乐，为什么音乐声会自动变小？这就是策略决策的典型场景。
AudioPolicyService 内部维护了一套优先级规则，我称之为「音频江湖地位排行榜」。电话的优先级最高，其次是导航、闹钟，最后才是媒体播放。这套规则定义在 audio_policy_configuration.xml 里，每个音频流都有一个 usage 属性，系统根据 usage 来决定谁该被「闪避」。
核心概念：音频策略决策三要素
- Usage（用途）：标明音频流的用途，比如 USAGE_MEDIA、USAGE_ALARM、USAGE_VOICE_COMMUNICATION
- Source（来源）：音频数据的来源类型，比如 AUDIO_SOURCE_MIC、AUDIO_SOURCE_FM_TUNER
- Flags（标志）：一些特殊行为标记，比如 AUDIO_FLAG_AUDIBILITY_ENFORCED（强制可听性）
我在项目中遇到过一个问题：某款手机在通话时，微信语音消息竟然也能同时播放。排查下来发现，是策略配置里把微信的 usage 和通话的 usage 设成了同一优先级。说白了，就是「江湖地位没分清楚」。解决方案很简单，把微信语音的 usage 从 USAGE_VOICE_COMMUNICATION 改成 USAGE_MEDIA，问题就解决了。
9.2 路由管理：音频信号该走哪条路？
路由管理是 AudioPolicyService 最核心的职责。它要回答三个问题：
- 当前有哪些可用的音频设备？
- 这个音频流最适合走哪个设备？
- 设备切换时，如何做到无缝过渡？
你想想看，手机上的音频设备可不少：内置扬声器、有线耳机、蓝牙耳机、USB-C 耳机、HDMI 输出……每个设备都有自己的特性。扬声器适合外放，但音质一般；蓝牙耳机方便，但有延迟；USB-C 耳机音质好，但占用充电口。
AudioPolicyService 通过 AudioPolicyManager 来管理这些设备。它会维护一个设备列表，每个设备都有一个 device_address 和 device_type。当新的音频流到来时，Policy Manager 会根据 usage 和当前可用设备，选出一个「最佳路由」。
// 伪代码：路由选择逻辑
AudioDeviceDescriptor selectBestDevice(audio_usage_t usage, audio_source_t source) {
// 1. 获取当前所有可用设备
Vector<AudioDeviceDescriptor> availableDevices = getAvailableDevices();
// 2. 根据 usage 过滤设备
// 比如通话优先选择耳机或听筒
if (usage == USAGE_VOICE_COMMUNICATION) {
// 优先有线耳机，其次蓝牙，最后听筒
return selectDeviceByPriority(availableDevices,
{DEVICE_OUT_WIRED_HEADSET, DEVICE_OUT_BLUETOOTH_SCO, DEVICE_OUT_EARPIECE});
}
// 3. 媒体播放优先选择音质好的设备
if (usage == USAGE_MEDIA) {
return selectDeviceByPriority(availableDevices,
{DEVICE_OUT_USB_HEADSET, DEVICE_OUT_WIRED_HEADPHONE, DEVICE_OUT_SPEAKER});
}
// 4. 默认路由
return availableDevices[0];
}避坑指南：我曾经在调试蓝牙耳机切换时踩过一个坑。蓝牙耳机连接成功后，AudioPolicyService 会收到设备添加的通知，但此时蓝牙的音频通道可能还没完全准备好。如果立即切换路由，会导致几秒钟的无声。解决方案是加一个延迟切换的机制，等蓝牙的 SCO 连接稳定后再做路由切换。
9.3 动态策略加载：不改代码也能改行为
这是 AudioPolicyService 最灵活的地方。你不需要修改 framework 代码，只需要修改 XML 配置文件，就能改变整个音频策略行为。
动态策略加载的核心文件有两个：
| 文件 | 路径 | 作用 |
|---|---|---|
| audio_policy_configuration.xml | /vendor/etc/ | 定义全局策略，包括设备列表、路由规则、音量曲线 |
| audio_policy_engine_configuration.xml | /vendor/etc/ | 定义策略引擎的行为参数，比如闪避的衰减量、切换延迟时间 |
我记得有一次，客户要求手机在连接特定蓝牙设备时，媒体音量自动降低 30%。按照常规思路，这得改 framework 代码，重新编译，烧录——至少一周时间。但利用动态策略加载，我只需要在 audio_policy_configuration.xml 里加一条规则：
<!-- 针对特定蓝牙设备的音量调整策略 -->
<volumeGroup name="media_volume">
<profile name="default">
<deviceAddress type="bluetooth" address="XX:XX:XX:XX:XX:XX">
<volumeCurve>
<point>0, -96dB</point>
<point>100, -30dB</point> <!-- 最大音量降低30dB -->
</volumeCurve>
</deviceAddress>
</profile>
</volumeGroup>改完配置文件，重启 audioserver 进程，策略就生效了。这就是动态策略加载的魅力——策略与代码分离，修改策略不需要重新编译。
注意：动态策略加载虽然灵活，但也有风险。如果 XML 格式错误，AudioPolicyService 启动时会解析失败，导致整个音频系统不可用。我曾经在生产环境遇到过因为 XML 里多了一个空格导致解析失败的事故。所以，修改配置文件后一定要做语法校验，可以用 libxml2 的工具先验证一遍。
9.4 策略引擎的工作流程
为了让大家更直观地理解 AudioPolicyService 的工作流程，我画了一张图：
从图中可以看到，整个流程是自顶向下的。应用层发起音频请求，经过 AudioFlinger 转发到 AudioPolicyService，然后策略引擎根据配置做出决策，路由管理器执行设备切换，整个过程都是动态的、可配置的。
9.5 实战经验：策略调试技巧
最后分享几个我在调试 AudioPolicyService 时常用的技巧：
- 查看当前策略状态：通过
dumpsys audio_policy可以查看当前的路由状态、设备列表、音量曲线。这是最直接的调试手段。 - 模拟设备插拔：用
adb shell am broadcast -a android.intent.action.HEADSET_PLUG --ei state 1 --ei microphone 1可以模拟耳机插入事件，测试路由切换逻辑。 - 日志过滤：AudioPolicyService 的日志标签是
APM::AudioPolicyManager，用logcat -s "APM::AudioPolicyManager"可以只看策略相关的日志。
个人经验：我曾经遇到一个诡异的问题——手机在通话时，对方听不到我的声音。查了两天，最后发现是策略配置里把麦克风的采样率设成了 8kHz，而通话要求 16kHz。这种问题在代码层面完全看不出来，只有通过 dumpsys 查看当前的音频配置才能发现。所以，遇到音频问题，先 dumpsys，别急着改代码。
好了，关于 AudioPolicyService 的核心内容就讲到这里。策略决策、路由管理、动态策略加载，这三个能力构成了 Android 音频系统的「大脑」。理解了它，你就能理解为什么手机能智能地切换音频设备，为什么不同应用的声音会有不同的行为表现。
公众号:蓝海资料掘金营，微信deep3321