企业官网建设流程全解析

音频系列写到第9篇，前面大多在AudioFlinger里打转，线程模型、混音链路、Effect链都翻得差不多了。今天换一个视角，讲一个在路由决策上真正说了算的角色：AudioPolicyManager。如果你调过插拔耳机不切声音、扬声器不出声这类问题，最后追到framework层，大概率都会停在它身上。它不直接碰硬件，也不负责混音，但它决定了你每次播放的音频该走哪条输出路径，是deep buffer还是低延迟，是扬声器还是蓝牙耳机。

这篇我用Android 11的源码做参照，带着你从整体定位、初始化链路、路由决策核心代码，一路看到一次普通播放里它到底参与了哪些环节。阅读前你最好已经了解AudioFlinger的PlaybackThread是什么，否则有些回调的动机不好理解，但我会尽量把前因后果交代完整。

1. 先从整体上认识：AudioPolicyManager是哪一层的大管家

1.1 它被谁调、它又调谁

你可以先把AudioPolicyManager理解成音频框架里的“调度中心”。上层的Java应用不会直接跟它通信，Java世界里的AudioService会通过Binder调用到AudioPolicyService，而AudioPolicyService真正的策略逻辑基本落在AudioPolicyManager内部。往下它也不会自己去操作声卡，真正执行输出、混音、线程管理的是AudioFlinger，AudioPolicyManager只把决策结果告诉AudioFlinger，再由AudioFlinger通过HAL去切硬件通路。

这个分工经常被搞混，我见过不少调试者一上来就抓AudioFlinger的日志，结果发现路由策略根本没变，还以为是AudioFlinger的问题。实际上AudioFlinger就是个“执行者”，它没有自己的意愿；而AudioPolicyManager才是那个“决策者”。两者都在audioserver进程里，一个偏向策略计算，一个偏向流调度和硬件管理。

1.2 它不是抽象名词，是一个真实C++类

AudioPolicyManager的源码路径一般在frameworks/av/services/audiopolicy/manager/下面，早期版本叫managerdefault，Android 11附近合并到了manager目录。头文件和cpp文件同名，类名就是AudioPolicyManager。

这里有个容易误解的点：AudioPolicyService和AudioPolicyManager是继承关系。AudioPolicyService不光是持有AudioPolicyManager，它本身就继承了AudioPolicyManager：

class AudioPolicyService : public BnAudioPolicyService, public AudioPolicyManager

所以你从Binder入口进入AudioPolicyService之后，很多方法其实直接调用的就是AudioPolicyManager里的实现。大家在IDE里搜代码时，如果点进了AudioPolicyService.cpp发现只有一层转发，别意外，真正的肉在AudioPolicyManager.cpp里。

1.3 配置XML就是它的“工作手册”

AudioPolicyManager启动时要读一个核心文件：audio_policy_configuration.xml。设备上位置通常在/system/etc或者/vendor/etc下，代码里由AudioPolicyConfig负责解析。这个XML定义了有哪些HAL模块、哪些设备、哪些mixPort、哪些route，以及策略与设备之间的对应关系。

路由决策基本可以理解为：读到某个事件（比如耳机插入），然后去配置表里查“当前可用的设备里，哪个设备符合这个stream/strategy的要求”。配置错了，代码逻辑再正确也没用。后面第5部分我会专门讲配置文件的坑，这里你先记住一件事：改路由之前，先看XML，它才是策略的基础输入。

2. 初始化链路：AudioPolicyManager是怎么“活过来”的

2.1 从AudioPolicyService的入口看起

AudioPolicyService是audioserver里注册的Binder服务，系统启动时会实例化它。初始化动作基本发生在服务创建后的onFirstRef阶段，大致链路是：服务创建 -> 初始化引擎 -> 加载音频策略配置 -> 扫描已有设备/输出 -> 准备好与AudioFlinger通信的客户端接口。

这段逻辑不在主线程上堆太多耗时操作，因为音频服务启动会影响整个系统音量相关能力，但也不至于阻塞到系统启动完成。平时我们觉得开机声音功能来得比较早，全靠这部分的初始化顺序比较靠前。

2.2 构造函数里三件大事

AudioPolicyManager构造函数的核心工作可以拆成三块：

第一，创建策略引擎。现在策略引擎已经独立出来，代码在frameworks/av/services/audiopolicy/engine/下，AudioPolicyManager通过AudioPolicyEngineInterface来调用。早期Android版本没有这个独立引擎，策略算法全在AudioPolicyManager内部，后来为了满足不同产品的策略定制，才抽成了可替换的引擎接口。

第二，加载配置。这里会去解析audio_policy_configuration.xml，把所有HwModule、OutputProfile、DeviceDescriptor、Routes都建立成内存对象。加载失败会导致后续没有可用输出设备，这种情况下系统很可能直接听不到声音。

第三，扫描当前已有的输出设备和输入设备。给每个device建立Descriptor，标记状态。为什么要这一步？因为设备连接状态是“增量更新”的，初始化时要先把存量设备都登记上，后面事件来了才能比对状态变化。

// 简化逻辑，实际代码里更复杂 status_t AudioPolicyManager::loadConfig() { AudioPolicyConfig config(mHwModulesAll); // 解析XML到config对象 // 再将config中的module、mixPort、route、device挂载到策略管理器里 mOutputs = new OutputCollection(); // 根据attachedDevices构建输出描述符 return NO_ERROR; }

2.3 解析XML时真正关心的数据结构

读XML时不要只盯着标签名，要关注它映射出来的C++结构。几个最核心的：

• HwModule：对应一个音频HAL模块，比如primary、a2dp、usb。每个module下会有输出或输入的mixPort。
• OutputProfile：描述一个mixPort支持的标志、采样率、通道数。比如低延迟输出通常有AUDIO_OUTPUT_FLAG_LOW_LATENCY。
• DeviceDescriptor：描述一个物理或逻辑设备，比如耳机、扬声器、蓝牙A2DP。
• Route：把mixPort和Device关联起来，代表“这个mixPort输出后能通向这些设备”。

初始化时AudioPolicyManager会构建一个默认输出描述符。设备上通常会有一个primary输出，对应着扬声器或耳机通路，它一般是默认路由的兜底。如果XML里primary module没有配置好，你会发现dumpsys audio里输出列表空空的，路由也没法建立。

我自己在调一个新平台时，总是先做一件事：开机后马上dumpsys audio看输出设备列表和策略表，确认初始化有没有把XML全部吃进去。这一步能过滤掉一大半“底层没声音但上层看起来正常”的伪故障。

3. 路由决策的核心链路：从“耳机插入”到“声音改道”

3.1 setDeviceConnectionState到底做了什么

设备连接状态变化是路由更新的最常见触发源。上层不管是通过AudioManager还是通过HAL上报，最终都会来到AudioPolicyManager的setDeviceConnectionState。

这个方法的入参值得注意：

status_t AudioPolicyManager::setDeviceConnectionState( audio_devices_t device, // 设备类型，例如DEVICE_OUT_WIRED_HEADSET audio_policy_dev_state_t state, // 连接/断开 const char *device_address, // 设备地址，蓝牙很重要 const char *device_name, // 设备名字，log里可见 audio_format_t encoded_format); // 编码格式，aptX/AAC等

方法内部做的事情可以概括为几步：先根据device枚举找到或创建对应的DeviceDescriptor，然后检查状态是不是真的变了。如果设备已经是连接状态，又一次上报连接，这次事件通常会被直接忽略，避免无效刷新。如果确实是新状态，就需要更新descriptor里的state字段，并且触发一次全量路由更新。

关键不见得在函数开头，而是在中间那一行updateDevicesAndOutputs调用。这个调用才是路线重算的入口。很多厂商定制的时候也爱在setDeviceConnectionState里加自己的判断逻辑，比如某些设备不允许路由到外接声卡，就会在这里直接return，导致连接没效果，这属于典型的产品策略覆盖。

3.2 决策引擎：getDeviceForStrategyInt是怎么选终端的

更新完设备状态后，AudioPolicyManager会遍历所有策略，逐个问引擎：这个策略现在该走哪个设备。引擎里的核心函数是getDeviceForStrategyInt，不同版本名字略有差异，但思路稳定。

所谓strategy，可以理解成“播放类型的大分类”。媒体、铃声、语音通话、系统声音各有自己的strategy，每个strategy又可能在XML里绑定一组允许的设备和对应的音量曲线。选设备时引擎会做这样几件事：

第一，从strategy允许的设备集合出发。比如媒体策略允许的设备可能包含扬声器、有线耳机、蓝牙A2DP。如果当前蓝牙已连接，就会被纳入候选。

第二，排除不可用的设备。连接状态为false的设备直接出局；有些设备虽然连接了，但对应HAL模块还没起来或者没有可用的输出流，也会被排除。

第三，考虑“强制使用”的覆盖逻辑。Android有一个setForceUse系统，常见的有媒体场景按home/按dock强制外放、通话强制耳麦等。这些配置会直接影响最终选择，引擎在遍历候选设备时会把forceUse策略带进去。

最终引擎返回的是一个audio_devices_t掩码，后面就能拿着这个掩码去匹配输出描述符了。

3.3 执行阶段：setOutputDevices是怎么生效的

策略引擎选出了理想设备，AudioPolicyManager接下来要找到能承载这条路由的output。一个output对应AudioFlinger里的一条播放线程，比如低延迟一条、深缓冲一条。Manager会检查现有output列表，看有没有一个output当前可用且设备匹配；如果没有合适的，可能就要让AudioFlinger新开一个输出流。

这个过程在updateDevicesAndOutputs里成串完成。我习惯把它理解成“先计算，再对账，最后下发”。计算是问引擎要设备；对账是比对old/new状态、找出需要stop的output和需要start的output；最后下发是调用mAudioFlingerClient的接口，让AudioFlinger去setOutputDevices。

// 伪代码：updateDevicesAndOutputs的大致骨架 status_t AudioPolicyManager::updateDevicesAndOutputs(const RoutingUpdate& update) { // 1. 遍历所有策略，获得每个strategy的目标设备 // 2. 检查现有output的路径是否匹配 // 3. 如果有output不再使用，触发stopOutput或release输出 // 4. 如果需要新output，调用openOutput去创建 // 5. 给需要改变路由的output执行setOutputDevices return NO_ERROR; }

注意一点：AudioPolicyManager这里说的“执行setOutputDevices”，并不是直接写寄存器，而是把路由结果同步给AudioFlinger。AudioFlinger的PlaybackThread在后续循环里会把路由信息通过HAL侧参数下发，最终由HAL打开对应的MixerPath。所以从事件发生到声音物理切换，中间是有一个时间差的，日志里看起来route已经变了，但HAL还没反应过来，这种情况不算bug，属于异步执行。

4. 业务侧视角：一次普通播放，AudioPolicyManager参与了哪些环节

4.1 getOutputForAttr：决定你的Track用哪个output

应用通过AudioTrack播放时，真正跟策略层发生的第一次深度交互是getOutputForAttr。AudioFlinger要创建播放线程前，会拿着音频属性来问策略层：我这个播放请求应该放到哪类output上去。

流程大概是：AudioTrack把audio_attributes_t传下来，AudioFlinger把请求转发给AudioPolicyService，AudioPolicyManager在getOutputForAttr里先根据usage和content_type确定stream type，再推导出strategy，然后拿着strategy和flags去找匹配的OutputProfile。找到后返回给上层一个output handle和portId；如果没找到能复用的output，就会让AudioFlinger新开一条播放线程。

这里有一个经常被忽略的细节：除了output handle，getOutputForAttr还会返回一组output flags，比如AUDIO_OUTPUT_FLAG_LOW_LATENCY、AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD。这组flags直接决定了这个Track后续走的链路特点。

开发者在自定义输出时要特别注意flags的匹配关系。比如某设备默认不定义offload profile，音乐软件一旦尝试offload播放就会失败，日志里经常出现“no output found for offload”之类的线索。

4.2 startOutput与stopOutput：引用计数与优先级管理

拿到output handle之后，播放真正开始时，AudioFlinger会调用startOutput，播放结束会调用stopOutput。这一步看着简单，实际作用是对output内部各个stream的引用计数做加减。

为什么要管引用计数？因为一个output可能同时服务多个Track。比如同一个低延迟output上，游戏背景音乐和按键音可能同时存在。AudioPolicyManager必须知道这个output什么时候从“无人使用”变成“有人使用”，这样才能在策略更新时决定要不要把它切到新的设备上，或者进行强制性的静音、ducking处理。

在Android 11源码里，startOutput会更新AudioOutputDescriptor上的refCount，然后触发一次策略更新检查。如果某个output的refCount降到0，它就会被认为可以释放，节省资源。释放output的权利也在策略层，不在AudioFlinger主动决定。

这层逻辑常被调侃成“管分配的不管执行，管执行的不管分配”，实际上两者的分工很清晰：AudioPolicyManager负责分配和回收，AudioFlinger负责运转和混音。

4.3 耳机案例走读：从插入到出声的完整链路

把上面的链路串起来看一个具体场景：正在用扬声器放音乐，插入有线耳机。

第一步，底层耳机检测触发。不管是耳机插拔中断上报到HAL，还是通过其他机制，最终框架层收到的回调会走到AudioPolicyService的setDeviceConnectionState，配的设备类型是DEVICE_OUT_WIRED_HEADSET。这里建议你在dumpsys audio里确认状态是否已经从0变成连接，如果这里就没到，说明问题在驱动层或HAL上报层，策略层是无辜的。

第二步，AudioPolicyManager更新DeviceDescriptor状态，触发updateDevicesAndOutputs。策略引擎重新为媒体策略选路由，这次符合条件的候选设备包括扬声器、有线耳机、蓝牙等，有线耳机优先级排在扬声器前面，所以返回结果变为有线耳机。

第三步，AudioPolicyManager检查现有output是否还适用于这个新设备。如果当前媒体output当初创建时对应的设备集合不包含耳机，策略层会让这个output的路由切换过去，通过AudioFlinger的setOutputDevices下发给HAL。

第四步，HAL收到路由参数变化，重新配置Codec的通路，声音从耳机出声，扬声器静音。

这个案例排查的时候，最有效的分界点就在第二步和第三步之间。如果dumpsys audio里策略已经显示设备是HEADPHONE，但声音还在扬声器，那就是AudioFlinger到HAL这段没执行干净；如果策略层压根没变，那问题就在上报和XML配置。

5. 常见问题排查与源码定位技巧

5.1 插拔设备后路由不切换，先看日志还是先看配置

很多工程师一上来就搜AudioPolicyManager的log，但系统默认很多ALOGD是不开或者被过滤掉的，光刷log效率很低。我自己的习惯是三步走：

第一次，确认策略层有没有感知到事件。用adb shell dumpsys audio看设备连接状态和策略输出结果，这一步能判断问题在策略层之下还是之上。

第二次，确认HAL层到底有没有切换物理通路。用adb shell tinymix查看当前声卡mixer路径，或者看HAL自己的log。很多设备明显route已经切了，但HAL没真正操作codec，这会表现为“软件层正常、物理层没声音”。

第三次，确认配置与硬件是否一致。比如设备实际只有耳机和扬声器两个通路，但XML里给某个策略配了USB设备，看似无害，一旦路由根据策略选中USB，HAL找不到对应通路就会静音。

5.2 dumpsys audio与dumpsys media.audio_flinger的搭配用法

这两个命令一定要搭配着看，分开都容易误判。

dumpsys audio输出里重点看三个部分：设备状态（Devices）、策略表（Strategies）、输出描述符（Outputs）。设备状态能告诉你“系统当前认为哪些设备连着”，策略表能告诉你“每种播放类型应该走哪个设备”，输出描述符能告诉你“当前有哪些output、每个output的设备和flags”。

dumpsys media.audio_flinger主要看output threads和对应HAL流状态。我遇到最多的情况是这样的：dumpsys audio显示策略已经选中A2DP，但audio_flinger里那条输出线程还停在Primary输出上，说明策略层到AudioFlinger的同步出了问题，或者output线程的路由刷新没有完成。

两条命令都正常却依然没声音，再去看HAL层mixer状态和音量曲线，不要死磕框架层。

5.3 配置XML最常见的三类错误

第一类，route没有连起来。mixPort和device之间没有定义的route连接，相当于策略层根本不知道某个输出能到达某个设备。这类错误在dumpsys audio里通常表现为设备存在但没有对应的output路径。

第二类，profile缺失或flags不匹配。比如底层明明支持48kHz播放，但XML里的profile只写了44.1kHz，一旦播放48kHz内容，上层找不到匹配profile就会降级或失败。更常见的是低延迟、offload这类特殊flags没有声明，导致系统根本不创建相应类型的输出。

第三类，attachedDevices和实际硬件不一致。XML里写了某个设备，但硬件上根本没有这条通路。这会让策略层认为设备可用，实际HAL上报却无此设备，最终声音丢失。

改配置后最好先语法校验，再推送设备重启。adb remount后替换XML，重启后立刻dumpsys audio看解析是否成功，别省这一步。

5.4 在源码里临时加日志的三个建议

有些厂商代码把ALOGI/ALOGD都关了，想要定位只能自己加日志。我建议加日志的位置不要乱放，选这三个信息量最大的点：

第一个是setDeviceConnectionState，打印device、state、address。这里能立刻区分问题在事件上报层还是策略处理层。

第二个是getOutputForAttr，打印usage、flags、返回的output、portId。这里能看出播放请求是否被正确分类，也是排查“某类音频走错输出”的关键位置。

第三个是updateDevicesAndOutputs，打印每个策略的目标设备列表和最终选择。这里能看到完整的路由重算过程，比散落到各个函数里日志管用得多。

加日志可以用已有的ALOGW临时验证，虽然带有警告级别容易混在错误流里，但胜在默认开启、不需要额外开关。生产版本记得清理，否则大量重复打印会把logcat塞满。

6. 源码阅读顺序与进一步深挖方向

6.1 建议按这个顺序读源码

如果这篇看完你还想动手跟一遍，我建议按下面这个顺序读，不要从文件开头往结尾硬看。

先看AudioPolicyManager.cpp里的setDeviceConnectionState和updateDevicesAndOutputs，把路由更新主脉络抓住。再看engine目录里的getDeviceForStrategyInt，搞清楚策略引擎怎么选设备。然后回到AudioPolicyService.cpp，看Binder入口怎么把请求转给Manager，特别关注ClientInterface回调，那是Manager调AudioFlinger的通道。最后去AudioFlinger的Threads.cpp看PlaybackThread怎么响应路由变化，虚实结合把整个链路闭合。

源码路径大致是：

frameworks/av/services/audiopolicy/manager/AudioPolicyManager.cpp frameworks/av/services/audiopolicy/engine/... frameworks/av/services/audiopolicy/service/AudioPolicyService.cpp frameworks/av/services/audioflinger/Threads.cpp

6.2 我的一点观察

跟音频路由问题打交道久了会发现，大多数疑难杂症并不是策略算法本身复杂，而是配置、硬件、策略三者之间的边界经常被搞混。很多开发者觉得AudioPolicyManager像黑盒，其实它的行为逻辑非常固定：事件进来，查配置，问引擎，选设备，下发执行。你只要能确认这四个环节在哪一段断开，问题就解决了一半。

我个人经验里，最花钱买教训的就是“先改代码后看配置”这个习惯。80%的路由异常，最后定位到根因都在audio_policy_configuration.xml的某条route或者某个profile上，真正要改到AudioPolicyManager核心逻辑的反而很少。所以如果你现在正准备为一个新硬件调试音频路由，我的建议很简单：先把dumpsys audio的完整输出保存一份，再把XML逐行和硬件通路对照一遍，最后再谈要不要动源码。这个顺序，能帮你省下大量无效debug时间。