Android AudioTrack设备选择源码解析：从setPreferredDevice到AudioPolicyManager

1. 设备选择问题的真实场景与核心链路

先从一个我实际调试过的现场说起。有个播放器项目，用户反馈在Android 11手机上插上3.5mm耳机后声音还是从扬声器出来，我们通过AudioTrack.setPreferredDevice()指定了有线耳机设备，日志里getPreferredDevice()也返回了预期设备，但出声设备就是不对。查了几天，最后定位到问题根本不在应用层，而是整个AudioTrack设备选择链路的一环被绕过了。

这个case让我意识到，很多做播放器、做Framework定制、做车机音频的开发者，对AudioTrack的“设备选择”理解都停留在API层面：以为调了setPreferredDevice就万事大吉。实际上，这个接口只是把你想要的设备作为“期望值”传到底层，底层AudioPolicyManager有一整套策略来决定最终用哪个输出设备，你的期望可以被接受，也可以被忽略，甚至可以在播放过程中被随时改变。

这篇内容适合三类人看：一是做音频播放器、音视频SDK，遇到设备路由诡异问题的应用层开发者；二是做Android Framework或HAL定制，需要深入AudioPolicy引擎的系统开发；三是刚接触Android音频源码、想理清AudioTrack到AudioFlinger再到AudioPolicyManager这条调用链的学习者。我会从源码调用路径、设备路由策略、常见问题排查三个维度来拆，尽量把这条链路讲透。

这条链路的核心其实就一句话：AudioTrack只是发起方，真正的路由决策权在AudioPolicyManager手里。你指定设备，底层策略引擎会根据策略、设备状态、输出能力来“重新算一遍”，算出最终设备，然后建立或匹配对应的PlaybackThread和Output。搞清楚这个“重新算一遍”的规则，所有诡异问题就都有了解释。

2. 源码调用链：device_id到底是怎么穿越Client和Server的

2.1 Java层到Native层：期望设备如何进入Track

先说应用侧的入口。AudioTrack.java里，setPreferredDevice(AudioDeviceInfo deviceInfo)最终调用的是native方法，进入libaudioclient库的AudioTrack类。在native构造时，核心函数是AudioTrack::set()，而设备ID作为audio_attributes_t的一部分或者独立参数被传入。

从源码看，set()内部会先把各种参数（采样率、声道、format、flags、deviceId）整理好，然后调用createTrack_l()。createTrack_l()做的事很关键：它负责和AudioFlinger建立连接，申请创建真正的Track对象。这个函数会组装一个audio_track_cblk_t共享内存块，同时把请求参数通过IAudioFlinger::createTrack()Binder调用发到system_server进程的AudioFlinger服务。

这里有个容易忽略的点：setPreferredDevice设置进去的deviceId，在native层会写入mAttributes的mDeviceId字段，并在createTrack_l时作为参数传给AudioFlinger。但是，这个参数在AudioFlinger那边并不会被直接当作“最终输出设备”，它只是被原样带下去，交给后续策略引擎判断。所以从这个角度看，setPreferredDevice更像是给底层策略引擎的一个“参考意见”。

// AudioTrack.cpp 简化逻辑 status_t AudioTrack::set() { ... if (deviceId != AUDIO_DEVICE_NONE) { mAttributes.mDeviceId = deviceId; } ... return createTrack_l(); }

createTrack_l()里有一段特别关键，它决定了Track走哪种创建路径。如果请求的是Offload播放（比如AUDIO_FLAG_COMPRESS_OFFLOAD），AudioTrack会尝试创建DirectTrack；如果是普通播放，创建常规Track。设备和输出选择的差异也正是从这开始分叉的。

2.2 AudioFlinger侧：createTrack如何处理设备参数

AudioFlinger的createTrack()收到客户端请求后，不会立刻为这个Track选一个PlaybackThread。它会先分析参数，调用AudioPolicyService的getOutputForAttr()来决策输出。

这里展示一下AudioFlinger::createTrack()的核心逻辑路径：它会根据请求的audio_output_flags_t和属性，从当前已存在的PlaybackThread列表中寻找匹配的输出，如果找不到匹配输出，则调用AudioPolicyManager创建新的输出。这个“匹配输出”的判断条件非常严格：采样率、通道数、format、flags、设备都要对齐。

我们之前遇到过一个情况：App设置了AUDIO_FLAG_FAST请求快速路径，但指定的采样率和当前PlaybackThread不匹配，系统干脆给它新建了一个独立的fast mixer线程。线程是新建了，设备却还是用的线程默认设备，不是App期望的那个设备。这暴露出一个问题：fast路径下，设备往往由线程绑定，而不是由track决定。

2.3 设备决策的“临门一脚”：getOutputForAttr

getOutputForAttr()是整个设备选择链路里最核心的函数，定义在AudioPolicyManager中。它的调用时机有两个：一是Track创建时，二是系统策略变化（如插拔耳机、蓝牙连接）时。它接收的属性包括audio_attributes_t（包含usage、content_type等信息）、audio_config_t（采样率、通道数、format）、请求的flags和设备ID，然后输出一个最终的audio_io_handle_t（输出句柄）和设备ID。

// AudioPolicyManager.cpp 关键路径 status_t AudioPolicyManager::getOutputForAttr( const audio_attributes_t& attr, audio_io_handle_t* output, audio_session_t session, audio_stream_type_t* stream, uid_t uid, const audio_config_t* config, audio_output_flags_t* flags, audio_port_handle_t* selectedDeviceId, bool* isFormatSupported) { ... // 根据usage计算routing strategy routing_strategy strategy = getStrategyForAttr(attr); ... // 根据strategy和设备状态选择输出设备 audio_devices_t device = getDeviceForStrategyAndClass(strategy, ...); ... // 查找或创建匹配的output *output = getOutputForDevices(device, session, stream, config, flags, ...); ... }

注意getStrategyForAttr()这一步。每个AudioTrack不管你有没有显式指定设备，都会先根据usage算出一个策略标识（routing strategy），比如STRATEGY_MEDIA、STRATEGY_SONIFICATION、STRATEGY_PHONE、STRATEGY_DTMF等。这个strategy决定了后面所有路由规则。换句话说，你创建Track时填的AudioAttributes已经悄悄决定了你将来会被分配到哪一类设备池。

很多应用开发者不明白为什么指定了设备不生效，其中一大原因就是usage和device不匹配。比如你拿一个USAGE_MEDIA的Track指定DEVICE_OUT_EARPIECE（听筒），策略引擎按STRATEGY_MEDIA的规则算，听筒根本不在媒体策略的候选设备列表里，你的指定自然就被丢弃了。

3. 路由策略引擎：设备到底是怎么“算”出来的

3.1 strategy与device_category：听筒、扬声器、耳机、蓝牙的优先级

Android从8.0开始把策略引擎独立到audio_policy_engine模块，设备选择逻辑主要在Engine类的getDeviceForStrategy()中。不同策略对应不同设备候选集，而且有明确的优先级顺序。

这里我根据AOSP源码整理一份简化的策略设备优先级表，不同厂商HAL可能微调，但大逻辑基本一致：

源码里这个逻辑写得很直白：getDeviceForStrategy()返回的不是一个具体设备，而是一个audio_devices_t位掩码，代表本策略当前“可用”且“最匹配”的设备集合。它内部会检查每个候选设备是否已连接（isDeviceConnected）、是否处于可用状态（音量不为0、未被其他策略独占等）。

3.2 默认路由计算规则：为什么你的指定会被“盖掉”

重点来了：getOutputForAttr()拿到你传入的selectedDeviceId后，并不直接采用。它会先通过getDeviceForStrategy()算出一个策略默认设备，然后做一次“期望设备 vs 策略设备”的匹配判断。

源码里对应逻辑大致是这样的：如果调用方指定了设备，且这个设备在当前策略的候选设备列表里，同时这个设备处于已连接状态，那么getDeviceForStrategy()会优先返回你指定的设备；否则，返回策略默认设备。这个“如果”条件看着简单，实际使用时踩坑点非常多。

第一个坑：指定设备时必须是AudioDeviceInfo对应的完整设备类型。有些开发者会把AudioDeviceInfo.getId()和一个audio_devices_t混淆，传入的是一个port id而不是device type，底层比较时压根匹配不上。

第二个坑：设备已连接但策略不可用。比如蓝牙耳机连上了，但你连接的是HFP（通话）profile，而不是A2DP，那么在STRATEGY_MEDIA的候选设备列表里，该设备不可用，策略引擎照样会fallback到扬声器。你指定蓝牙耳机，得到的还是扬声器。

第三个坑：多个AudioTrack抢占时的策略竞争。系统里永远不只你一个Track，可能出现两个Track同时播放，分别属于不同strategy的情况。比如导航语音用USAGE_ASSISTANCE_NAVIGATION_GUIDANCE，音乐App用USAGE_MEDIA。当导航语音开始播放时，策略引擎可能会根据声音事件切换到听筒或耳机通道，等导航语音结束再切回来。这时你的setPreferredDevice会因为其他策略的临时介入而被临时“盖掉”。

3.3 fast/direct路径：绕开策略引擎的特殊通道

Android的音频播放请求除了普通模式，还有两种特殊路径：fast mixer路径和direct output路径。这两条路径的设备选择逻辑和普通路径完全不同。

fast路径对应AUDIO_FLAG_FAST，主要给低延迟场景用，比如游戏、实时K歌。当AudioTrack请求fast标志，且采样率/通道数/format与当前fast mixer线程匹配时，系统会把Track直接挂到已有的fast mixer线程上。而fast mixer线程是在启动时就绑定了一个固定的输出设备（通常是primary output），这个设备不会因为单个Track的setPreferredDevice而改变。这就是为什么低延迟模式下指定设备常常无效。

direct路径对应AUDIO_FLAG_HW_AV_SYNC、AUDIO_FLAG_DIRECT、AUDIO_FLAG_COMPRESS_OFFLOAD等场景。这类Track通常在HAL层就有独立的输出流，由真正的音频DSP/解码器直接处理。direct output匹配时，系统会遍历所有direct输出profile，查找支持对应采样率、格式、通道数和设备的输出。如果你指定的设备没有注册对应的direct profile，创建直接输出就会失败，或者fallback到普通路径，设备自然也不是你指定的那个。

我个人调试过的一个案例：某款USB DAC在指定DEVICE_OUT_USB_DEVICE播放DSD时，因为该DAC没有注册Direct PCM profile，系统直接放弃了direct路径，走普通混音输出，结果DSD变成了PCM播放，设备也“看起来像是”没有生效。实际上设备是生效的，只是路径和预期完全不同。

4. 设备变化时的路由更新机制

4.1 设备插拔后，AudioPolicyManager做了什么

前面讲的主要是Track创建时的设备选择，但设备选择还有另一半：播放过程中设备发生变化，比如插拔耳机、蓝牙断开、USB DAC插拔。这部分由AudioPolicyManager::setDeviceConnectionState()驱动。

设备连接状态变化会触发一个完整的路由重算流程：先更新系统的设备连接表（记录哪些设备在线），然后遍历所有策略，调用getDeviceForStrategy()重新计算每个策略的最新设备，再遍历所有活动的PlaybackThread，看当前线程绑定的设备是否需要切换。如果发现某个播放线程的设备已经不匹配，AudioPolicyManager会调用AudioFlinger的setOutputDevice()来切换输出。

这里有个值得注意的点：切换设备不一定会中断播放。如果新旧设备在同一个PlaybackThread的scenario内，系统可能直接调整HAL参数，让音频流无缝切到新设备；如果跨越了线程（比如从speaker切到A2DP，需要新的A2DP输出线程），AudioFlinger会做一次“冷切换”，表现上就是播放断了几十毫秒。

很多播放器App遇到的“拔出耳机后声音还在继续”或“蓝牙断开后播放直接STOP”，就是这个切换过程引发的问题。具体表现为：设备拔掉后，策略引擎把strategy设备改成speaker，但原来的Track可能因为AudioTrack内部状态机判断“输出不可用”，自动进入paused/stopped状态。

4.2 客户端如何感知路由变化：两个回调用途不同

对应用层来说，设备变化有两种监听方式，容易混淆。

第一种是AudioManager.registerAudioDeviceCallback()，它监听的是系统音频设备列表的变化，即插拔事件本身。回调里会给你一个AudioDeviceInfo[]数组，你可以从中获取当前所有已连接设备。这个接口适合做UI展示、设备列表刷新，它不关心你的Track是否正在使用这些设备。

第二种是AudioTrack.addOnRoutingChangedListener()，它监听的是你的Track的实际路由变化。每当系统策略引擎把你的Track的输出设备切换时，回调会触发。这个接口才是判断“我的播放是否被切走了”的正确途径。

源码里，AudioTrack.addOnRoutingChangedListener()注册后，native层会设置一个routing callback，AudioFlinger在输出设备变化后，通过IAudioTrack::onRoutingChanged()的Binder回调通知客户端。客户端收到回调后会重新获取当前路由信息，判读最新的设备ID。

我建议所有做播放器的开发者：主界面监听AudioDeviceCallback用于展示，播放引擎内部监听OnRoutingChangedListener用于处理播放状态。很多开发者只加了前者，导致UI显示耳机已经断开，但播放引擎不知道设备变了，出现“插着耳机暂停，拔了耳机还在暂停”之类的状态错乱。

4.3 新版本API：更高层的路由控制

Android 12之后，系统提供了AudioManager.setCommunicationDevice()和AudioManager.setPreferredDeviceForStrategy()接口，允许应用不直接操作某个Track，而是按strategy级别做路由控制。前者主要面向通话/通信类音频，指定通话音的输入输出设备；后者可以给某个strategy全局设置偏好设备，相当于对整类音频生效。

这些新接口内部依然走的是AudioPolicyManager的设备选择流程，只是把“设备偏好”挂到了strategy上，而不是单个Track上。对开发者的意义是：你可以更粗粒度地控制路由，而不用追踪每个Track的生命周期。但副作用也很明显——如果多个App同时设置了不同偏好，后设置的可能覆盖先设置的，系统里并没有一套公开的“偏好冲突仲裁”机制，结果基本靠后写覆盖。

5. 高频问题排查实录：设备选择不生效的几种典型情况

5.1 一套快速定位的方法论

遇到设备选择不生效，我建议按这个顺序排查，不要一上来就改代码。首先用adb shell dumpsys media.audio_policy看当前策略引擎的设备状态和路由表，确认目标设备是否真的处于已连接状态、是否进了候选列表。然后用adb shell dumpsys media.audio_flinger看Track实际挂在了哪个PlaybackThread上，确认最终输出句柄。

如果前两步还不能定位，就在源码层加日志：logcat -v threadtime过滤AudioPolicyManager、getOutputForAttr、getDeviceForStrategy这三个关键位置，看清楚策略引擎最终返回的设备ID和你预期的差异。这一步能直接告诉你，到底是指定被丢弃了，还是指定根本就没传到底层。

5.2 三个高频Case复盘

Case 1：TWS耳机连接后，媒体声音不从耳机出。

这类问题多发生在蓝牙耳机只连接了HFP/HSP，没有建立A2DP流的时候。策略引擎在STRATEGY_MEDIA的候选设备列表里找不到DEVICE_OUT_BLUETOOTH_A2DP，自然fallback到speaker。解决方式是使用BluetoothA2dp主动请求连接A2DP profile，或者在App里检测到当前蓝牙只有SCO设备时，提示用户到蓝牙设置里手动连接“媒体音频”。

Case 2：指定了USB声卡，声音仍在扬声器。

USB声卡在Android里的路由比较特殊。很多USB DAC需要系统注册对应的mixPort并声明支持direct输出。如果你只是setPreferredDevice而底层没有匹配的output profile，系统会静默fallback。处理办法是确保USB DAC的profile在audio_policy_configuration.xml里配置了，且声卡的输出采样率和format被策略引擎认可。还有一点，部分设备只有插拔瞬间会重新扫描路由，插上之后才创建Track，可能匹配不到新设备，需要在onAudioDeviceAdded回调后再设置设备。

Case 3：导航语音播放时，音乐被“挤”到扬声器或听筒。

这个其实是策略引擎的正常行为，STRATEGY_SONIFICATION播放会临时抢占并改变策略切换向量。尤其是AUDIO_USAGE_ASSISTANCE_NAVIGATION_GUIDANCE这类低延迟提示音，在设计上优先保证可听性，路由到电话通道或听筒是预期行为。作为音乐App你改变不了这个，但可以通过监听OnRoutingChangedListener感知变化，等导航音结束后重新setPreferredDevice恢复自己的设备偏好。

5.3 一个底层调试技巧：用systrace抓Track创建时延

如果怀疑设备选择耗时过长导致播放建链慢，可以用systrace来分析。在Track创建前加一个trace点，setPreferredDevice是一个，createTrack_l是一个，然后看AudioFlinger侧createTrack到getOutputForAttr返回的耗时。正常来说，如果设备已在候选列表，这段耗时应该在微秒级；如果出现几十毫秒的耗时，多半是策略引擎在枚举direct output profile，或者HAL层在做设备探测。这个对做低延迟场景优化特别有用。

6. 留给自己和后来人的一些笔记

AudioTrack设备选择这条链路，最大的认知陷阱就是“指定设备=强制设备”。基于源码，我们可以确认：

• setPreferredDevice设置的deviceId最终传给getOutputForAttr，只是策略引擎的一个参考输入。
• getDeviceForStrategy才是真正决定设备的函数，它根据strategy、策略优先级、设备连接状态、设备可用性来综合判断。
• fast/direct路径有自己独立的设备绑定逻辑，不一定走主策略。
• 设备插拔后，策略引擎会重算所有strategy的设备，影响的是所有活动Track。

如果做Framework定制，想真正改变设备选择行为，比起在App层堆代码，更推荐直接修改策略引擎的设备优先级映射表，或者修改getDeviceForStrategy里的候选设备判断逻辑。这个方向是所有设备路由问题的总闸门，改一层，所有App都跟着变。

最后分享一个笨但可靠的学习路径：在任何Android源码版本上，从AudioPolicyManager::getOutputForAttr开始，打断点到getDeviceForStrategy，再看Engine类的具体实现，跟着一条Track从创建到播放完整走一遍，比读十篇源码分析文章都有效。设备选择这件事，纸上谈兵没意义，亲自跑一遍就全通了。