我们最近在 RK3576 平台适配 Android 14 的时候撞上了一个很典型的看电视学不来系列问题只要一插 HDMI 线媒体声音就没了屏幕上还会冷不丁弹出一个音频切换提示。刚接到这个问题的时候我下意识以为是 APP 兼容性问题后来顺着 Log 一路追到 AudioPolicy 和 HDMI 音频路由策略才发现这实际上是 Android 14 在音频设备切换和弹窗提示逻辑上的一次大改动跟硬件本身关系不大。这事的排查过程挺有代表性涉及弹窗机制、音频策略、HAL 层路由、EDID 解析好几个层面。今天我把完整过程拆开讲讲帮遇到类似问题的同行少走点弯路。1. Android 14 弹窗机制的变化先看懂它为什么要弹1.1 弹窗不是系统闹鬼是音频策略在插手很多人一听到弹窗问题就以为纯粹是 UI 层的东西其实 Android 14 里这玩意背后的逻辑链特别长。插 HDMI 后弹出的那个提示专业叫法是音频设备切换提示AudioDeviceChangeNotice它在系统里的正规英文名字是ACTION_AUDIO_DEVICE_CHANGE或者更常见的是DeviceSwitch通知。Android 14 对它做了一次重塑不再像 Android 12/13 那样只由 SystemUI 简单判断插入状态而是由AudioService 结合当前播放状态、焦点状态、策略结果综合决定。换句话说弹窗本身是果音频路由策略才是因。HDMI 插入后系统会做几件事探测新设备通过AudioDeviceCallback和 HAL 上报的onNewAudioDeviceAdded知道 HDMI 已经插上。重新计算路由AudioPolicyManager 会调用getDeviceForStrategy()核对当前正在播放的 stream 类型Music、Navigation 等对应到哪个 device 上。发起音区切换如果路由结果变化底层会调setOutputDevices()同时 Framework 会收到DeviceSwitch回调。弹窗通知SystemUI 的AudioDeviceSwitchDialog被拉起告诉用户当前音频输出设备变了。我在实际调试中发现这个弹窗能不能弹、什么时候弹取决于AudioPolicyEngine 的配置策略audio_policy_configuration.xml以及AudioService 的isInCommunication/isAppInFocus状态。如果当时有 APP 在持有音频焦点且处于媒体播放状态弹窗出现的概率会大很多。这里插一句Android 14 还引入了一个新的概念叫AudioPolicyManager::getDevicesForRole它会影响系统判断哪些设备可以参与自动切换尤其是 HDMI 这类外接设备。具体的差异非常细微下面我会展开。1.2 Android 14 跟 13 相比到底改了什么我们先看一张我自己整理的对比表把 Android 13 和 Android 14 在 HDMI 插入处理上的核心差异列出来方便大家理解为什么升级到 14 之后老问题会变新问题。对比项Android 13Android 14设备切换通知触发条件AudioService 简单监听ACTION_HDMI_PLUGGEDAudioService 结合 AudioPolicy 结果再决策弹窗展示逻辑SystemUI 直接根据 broadcast 显示增加AudioDeviceSwitchDialog的 focus 判断与冷却时间AudioPolicyEngine 路由规则同一策略里支持多个 device 并行强调role和forceUse机制HDMI 参与度更高音量带迁移逻辑切换后可能沿用上次设备音量切换会触发 stream volume 重置可能造成音量看似没变实际归零HAL 与 Framework 交互低延迟回调为主高频事件回调 AudioPolicyManager主动查询设备状态重点解释一下最后一行的差别。Android 14 里 Framework 会频繁向 HAL 发起getDeviceState之类的查询如果在HAL 层还没完成 EDID 解析时 Framework 就发起了路由计算可能拿到一个未就绪的 device id导致后续媒体音频走了错误的输出节点表现出来就是插上 HDMI 后电视没声音。这不是 RK3576 特有高通、联发科平台上同样会遇到只是概率和时序差异。还有一点值得注意的是Android 14 对AudioDeviceChange的弹窗做了节流throttle。也就是短时间内反复插拔 HDMI 时可能只会弹一次。很多人会在调试的时候发现我拔掉再插怎么不弹了这不一定是你代码改坏了可能是系统自动进入了冷却窗口。我在 RK3576 上验证过间隔大约 2 秒内的重复插拔会被忽略弹窗不会重复出现。这对产品形态来说其实是优化但对开发调试来说确实挺坑的。2. 问题现场RK3576 插上 HDMI 后媒体音频消失的全过程2.1 先复现再说结论我在 RK3576 开发板上跑的是 AOSP 14.0 的官方源码android-14.0.0_r15 分支电视端接的是一台普通 4K 显示器HDMI 线支持标准的 ARC 回传不过我在测试过程中一般会断开 ARC让问题更纯粹一点。复现步骤非常简单开机先用板载喇叭播放媒体音频一切正常。使用不带音频回传的普通 HDMI 线接入电视。屏幕正常点亮但媒体声音瞬间消失板载喇叭和 HDMI 都没有声音。界面弹出音频输出已切换到 HDMI的提示但电视并没有任何声音。拔掉 HDMI 线声音恢复。从用户视角看这就是弹窗惹的祸——弹窗出现了声音却没了。但作为系统工程师我们必须要分开看待这个现象弹窗是合法的声音消失才是异常。当时我第一反应是检查 Alsa 的声卡状态在板子上执行cat /proc/asound/cards能看到 HDMI 声卡节点是存在的这说明硬件链路没问题。接着执行tinymix查看 mixer path发现 HDMI 的 switch node 并没有被正确打开导致音频数据虽然在 Framework 层被投递到了 HDMI 声卡口但底层实际通路没打通。这个现象其实非常经典Framework 认为路由成功HAL 层却静默失败。2.2 分区排查先把问题劈成三瓣我习惯把问题拆成三层来看避免被现象带偏第一层弹窗逻辑。这个弹窗是谁发的判断依据是什么是不是因为 AudioService 觉得设备切换成功了才发第二层AudioPolicy 路由决策。Framework 认为音频应该去哪个设备为什么媒体声音没有选择板载喇叭而选择了 HDMI第三层HAL/内核音频通路。即使 Framework 把音频数据送到了 HDMI 声卡节点底层 mixer path 有没有真正打通EDID 解析有没有失败理清这三层之后我开始逐步抓 Log 和做实验一步步缩小范围。先说弹窗层。我在 logcat 里搜AudioService、AudioDeviceSwitch、AudioPolicyManager这些标签很快就看到了关键日志D AudioPolicyManager: getDeviceForStrategy force device 0x400 D AudioPolicyManager: switchOutputDevices() device 0x400, strategy 0 D AudioService: onAudioDeviceChangeListener, device HDMI D SystemUI: showAudioDeviceSwitchDialog这里0x400对应的是AUDIO_DEVICE_OUT_HDMI0x400 是 Android 音频 HAL 中的标准枚举值。这说明 Framework 侧的逻辑没有走错它确实认为音频应该给 HDMI。也就是说弹窗的产生是有依据的系统判断设备切换成功了。但问题来了既然设备切换成功为什么 HAL 层没有声音我又执行了dumpsys media.audio_flinger检查当前播放线程的Output设备节点发现一个很有意思的现象音频数据确实被送进了 HDMI 声卡但dumpsys audio里显示音量信息正常。也就是说Framework 到 HAL 这条链路是通的问题集中在 HAL 到 Codec/HDMI 发射器这条链路。这一步做完我已经基本确认Framework 侧一切正常问题在 HAL 层的设备状态管理和 EDID 初始化时机上。如果你也在调试类似问题掌握这个判断方向很重要别在 SystemUI 或者 AudioService 上死磕。2.3 为什么 IMX/高通平台没有 Render 这个 Bug唯独拉胯这里需要交代一下平台背景。RK3576 使用的是 Rockchip 自己的audio_hw对应 HAL 层模块名字是audio.primary.rk30board.so或新版audio.primary.rk3576.so这套 HAL 对 HDMI 接入事件的处理依赖于hdmi_audio_output和edid解析结果。在高通平台上HAL 内部有一个很成熟的AudioDeviceSwitch状态机不会因为 Framework 层的小变化而翻车但 Rockchip 的 HAL 从 Android 11 到 Android 14 一直在迭代状态机相对简单特别容易受 Framework 事件时序影响。具体表现就是当 Framework 在 EDID 未解析完成的窗口期发起输出切换HAL 可能直接进入了空转发状态。音频数据包在 ALSA 层面被写入但实际 MIXER 通路没连接于是一切都正常假装正常唯独没有真实声音。3. 深入调试日志、ALSA 路由和 EDID 时序分析3.1 关键日志提取方法在复现问题上我推荐先清空 logcat 再插线命令如下adb logcat -c # 插入 HDMI 线后立刻抓取 adb logcat hdmi_plug_issue.log抓完日志后不要着急看全部重点搜索以下关键词AudioPolicyManager看路由计算过程AudioService看设备切换事件AudioDeviceSwitch看 SystemUI 弹窗决策audio_hw/audio.primary看 HAL 层处理EDID看设备信息解析Error/Warn排查有没有被吞掉的异常当时我抓到的比较关键的异常是这一段W AudioFlinger: getOutput() failed, no output for device 0x400 E audio_hw_route: invalid route for device HDMI, fallback to default这个日志就是破案的关键之一。getOutput() failed说明AudioFlinger 在 HAL 中找不到一个可以同时支持当前采样率和 HDMI 设备的输出节点而 HAL 层的fallback to default又强制把音频路由回了板载喇叭对应的声卡。有意思的是Framework 并不知道 HAL 偷偷做了 fallback所以它以为仍然在 HDMI 上弹窗照常弹出实际上声音早已被 HAL 层的 fallback 逻辑改道而改道的路径又因为某些 mixer path 配置问题没打通最终形成无声。所以你看这个问题的本质不是弹窗本身有问题而是Framework 和 HAL 对同一个设备切换事件的决策结果不一致。Framework 说去 HDMIHAL 说切不了两者没对上最终就表现为弹窗出现但声音消失。3.2 ALSA 路由检查工具组合拳确认 Framework 和 HAL 不一致后我用 list 命令把系统中所有声卡和 PCM 节点过了一遍cat /proc/asound/pcm tinypcminfo -D hw:0,3 tinymix | grep -i hdmi在 RK3576 上一般会看到这样的声卡节点布局hw:0,0 板载 Speaker / HeadphoneRK809 或类似 codechw:0,2/3 HDMI 音频RK628 或 RK3399 HDMI TX 的 I2S 接口我试着手动打开 HDMI 的 mixer pathtinymix set HDMI_TX_MUTE 0 tinymix set HDMI_TX_SEL 1这样操作之后HDMI 终于有声音了。这说明底层 ALSA 通路是好的问题还是出在 HAL 层的自动路由上古化逻辑——它没有在合适的时机把 mixer path 配置成输出到 HDMI 的状态。为了进一步确认我直接执行adb shell dumpsys audio | grep -A 20 HDMI能看到Devices: 0x400说明 Framework 侧依然认为 HDMI 是 active device。但 HAL 的 ALSA route 实际上没有指到 HDMI。两者之间的矛盾就是无声的来源。3.3 EDID 初始化时序为什么跑得快反而没声音RK3576 平台对 HDMI EDID 的解析是在hdmi_tx驱动里完成的当插线事件上报到 HAL 时HAL 会立即调用edid_get_audio_info()去拿 HDMI 支持的音频参数采样率、通道数等。如果此时 EDID 还没解析完成HAL 可能拿到一个空的或者格式错误的参数进而选择不做任何配置直接把音频继续送往原来的输出设备。从时序上看Android 14 的 AudioPolicyManager 在收到onNewAudioDeviceAdded回调后几乎立刻就会开始计算新路由。而 Rockchip 的 HDMI 驱动在检测到插线到 EDID 解析完成之间往往有几十到几百毫秒的不确定延迟。在高速处理的 Android 14 上这两者的时间差被进一步放大BUG 就更容易暴露。为了验证我在 HAL 层打了几个临时的ALOGI日志把HDMI plug event和EDID ready的时间点打印出来。结果发现有时候两者差值达到 300ms。这意味着 Framework 的切换请求基本总是先到而 HAL 的 EDID 数据总是后到。先后顺序完全反转HAL 自然无法正确配置。4. Android 14 音频策略与弹窗联动机制的深度剖析4.1 AudioPolicyEngine 在干嘛为什么它决定了一切继续往底层拆。Android 14 的音频路由决策不再像早年那样写死在 HAL 的 if-else 里高通平台除外而是依赖一组 XML 配置和引擎解析。具体路径通常在/vendor/etc/audio_policy_configuration.xml /vendor/etc/audio_policy_engine_configuration.xml /vendor/etc/audio_policy_engine_default_stream_volumes.xml /vendor/etc/audio_policy_engine_product_strategies.xml其中audio_policy_configuration.xml定义了系统中有多少声卡、多少输出设备device port、哪些设备支持哪些采样率。插入 HDMI 后AudioPolicyEngine 会找到一个devicePort它对应的AudioProfile被激活进而影响Strategy的最终输出选择。在这个 bug 里我怀疑是audio_policy_configuration.xml没有为 HDMI 端口正确声明encapsulation或者channelMasks导致 AudioPolicyManager 认为 HDMI 设备无法承载当前的音频格式。但 HAL 的 route 逻辑又因为另一个判断误入了 HDMI 通路最终这一来一回就让整个音频链路半死不活。我在排查时做了个实验打开audio_policy_configuration.xml在 HDMI 的devicePort后面补全了24-bit和48kHz的 profile重新编进镜像后测试发现 HDMI 无声概率明显降低但并未完全根治。这也说明 EDID 时序问题才是主因profile 配置只是加剧了问题的表现。4.2 弹窗出现的判定逻辑为什么不能再靠插上就弹Android 14 对弹窗的出现时机做了一件很重要的事它把设备拔出/插入和音频路由真正切换解耦了。在 Android 13 及以前插上 HDMI 之后 SystemUI 可以单纯监听ACTION_HDMI_PLUGGED广播就弹窗提示但 Android 14 要求 SystemUI 再向 AudioService 查询一次当前实际路由结果只有确认了路由切换成功才会展示弹窗。在正常情况下这个机制没有任何问题甚至比原来更准确因为系统不会再出现插着 HDMI 文不对题弹窗的情况。但在静态逻辑层面上它引入了一个新的隐患如果 Framework 和 HAL 对路由结果出现上述的分歧Android 14 的系统里弹窗会照常显示因为 Framework 认为切换成功了而底层已经 fallback弹窗内容就变得失真了。所以在 Android 14 上排查弹窗问题一条很关键的思路是你可以从弹窗的出现反推 AudioService 已经做了一次成功的路由切换。既然它认为成功那就集中火力找 HAL 和 Framework 不一致的地方而不是怀疑弹窗本身的逻辑。4.3 音量迁移机制插上 HDMI 变成音量 0的坑除了无声Android 14 还有一个很容易被误判为弹窗问题的细节音量迁移volume migration。系统在切换音频设备时会将当前 stream 的音量从旧设备搬运到新设备。如果你板子的 HAL 对该 stream 不支持某个音量档位或者 HAL 没有正确响应setVolume请求可能出现新设备音量被设成 0 的情况。我当时在日志里看到一条很隐蔽的记录D AudioService: getStreamVolume music, device HDMI, volume index 0这条日志说明系统在为 HDMI 设备恢复媒体音量时取到的旧音量值本身就是 0。原因是播放器之前把音量设到 0而拔掉 HDMI 后板载 speaker 在历史缓存里没有这个值系统也不会再把音量恢复到非 0 状态。很多人碰到这种情况会误以为又是路由 bug其实单纯是音量迁移的问题。碰到这种情况建议在AudioService.java里打点或者查看stream_volume的持久化情况adb shell dumpsys audio | grep -A 50 Volume重点关注getStreamVolume返回的 index 和MAX值确认是不是出现了音量实际为 0的假象。如果确实是音量迁移问题在audio_policy_configuration.xml中检查该设备声卡的音量曲线或者 HAL 的setVolume实现即可。5. 解决思路与补丁方案从上层配置到底层 HACK5.1 方案一调整 AudioPolicy 配置推迟 HDMI 切换时间如果你暂时不打算大动 HAL 代码最实用的方案是在audio_policy_configuration.xml上做一些软配置让系统在 EDID 还没有解析完成之前不把 HDMI 当作可用的输出设备。具体做法是把 HDMI 设备端口的attachedDevices项改为依赖于某个延迟加载的属性或者直接移除默认的 Engineering 模式下的自动切换。在项目早期验证阶段我用的一个临时方案是把audio_policy_configuration.xml中 HDMI 的devicePort注册顺序挪到所有内置设备之后。这样 AudioPolicyEngine 在遍历设备时会优先匹配板载喇叭HDMI 只有在内置设备完全不满足策略要求时才会被选中。实测下来插 HDMI 后板载喇叭不会立刻切走媒体声音继续播放弹窗频率也降低了。这个方案可以解决插入即断声的绝大多数场景但缺点很明显用户明明插了 HDMI声音却仍然从喇叭出来用户体验比较怪。如果客户能接受插上不自动切需要在设置里手动选这种交互这个方案低风险高回报。5.2 方案二HAL 层处理 Plug 事件的时机更彻底的修复是在 HAL 层。在audio_hw.c或者新 SDK 里的audio_hw_ext.c中找到 HDMI 上线事件的处理入口一般在函数start_output_stream()或者adev_set_parameters()里面。需要做到的是当收到hdmi_plug_in参数时不要立刻执行路由切换而是先轮询等待 EDID 解析完成。参考一个典型的补丁思路static int wait_hdmi_edid_ready(void) { int retry 0; int edid_ready 0; while (retry 50) { usleep(10000); // 每次等待 10ms edid_ready hdmi_get_edid_audio_info(); if (edid_ready 0) { break; } retry; } if (!edid_ready) { ALOGE(HDMI EDID not ready after 500ms, fallback); return -1; } return 0; }在插拔事件回调中调用这个函数如果 EDID 未就绪就不去切换路由保持原状。这样可以完美避开 Android 14 的高频查询窗口期。实测下来HAL 层加等待后HDMI 插入后的无声问题基本消失弹窗内容的准确性也大幅提升。这套方案需要重新编译 HAL 库并 push 验证适合有一定系统定制能力的团队。如果你们用的是 Rockchip 提供的 BSP SDK可以在hardware/rockchip/audio目录下找到对应的实现改动完只需要mmm hardware/rockchip/audio -j32重新编译。5.3 方案三强制媒体输出不跟随 HDMI产品取舍如果你的产品场景里插入 HDMI 更多只是投屏显示而不是为了外放声音那么强制媒体音频输出固定在板载喇叭反而是最好的选择。可以通过在audio_policy_configuration.xml里给 Media 类 strategy 固定设备让它不参与 HDMI 自动切换。以 RK3576 的工程样板为例可以在策略配置中把 media 的preferredDevice强制指向 Speakerstrategy nameSTRATEGY_MEDIA deviceAddressSpeaker/deviceAddress /strategy这样做的好处是你完全不需要动 HAL 的代码系统会老实地把媒体音频保留在板载喇叭上。缺点是 HDMI 音视频同步场景比较难做如果要同时走 HDMI 的音频就没有自动切换了。个人建议是在产品开发早期先和产品经理确认清楚需求到底要不要支持 HDMI 音频自动切换。如果明确不需要方案三性价比最高。6. 常见问题速查与项目落地经验6.1 一张表解决你百分之八十的疑问现象直接原因解决方向插入 HDMI 后媒体声音消失弹窗照常出现Framework 和 HAL 路由结果不一致HAL fallback 后无声在 HAL 层等待 EDID ready 再切路由插上 HDMI 后弹窗提示切换成功但电视无声HAL 的 mixer path 没有被正确配置到 HDMI 声卡检查tinymix的 HDMI_TX_SEL 等节点设置插入 HDMI 后弹窗提示切换成功音量条显示 0音量迁移逻辑从旧设备取到 0 值检查 AudioService 的 stream volume 持久化拔插 HDMI 后弹窗只出现一次后续不出现Android 14 对弹窗做了节流属正常设计不需要修插 HDMI 后板载喇叭没声HDMI 有声但爆音音频格式没有正确匹配EDID 解析出来的格式受限在audio_policy_configuration.xml中补全 profile 格式画面正常声音时断时续EDID 音频信息刷新间隔较大导致采样率频繁切换在 HAL 层增加 HDCP/EDID 变化的事件去抖6.2 项目实操中的几条避坑经验不要只对着 dumpsys audio 看要结合 tinymix 一起看。dumpsys audio反映的是 Framework 层的理想路由tinymix才是硬件实际状态。两者一致才是真的没问题。抓日志时一定要带时间戳。Android 14 的事件处理速度太快没有时间戳你很难判断 Framework 的切换请求是不是真的发生在 EDID 解析完成之前。尽量用支持 ARC 的 HDMI 线和普通 HDMI 线各测一遍。Rockchip 平台对 ARC 和普通 HDMI 的设备类型枚举不同部分固件对 ARC 节点处理有历史遗留 bug如果不区分测试很容易把两类问题混在一起。如果你改了 audio_policy_configuration.xml记得检查 A/B 分区镜像。RK3576 经常使用 super 分区和 vendor_boot 分区单独改 system 下的 XML 大概率不会生效。改完后先用adb shell mount看下 vendor 分区是否可写再确认文件路径到底是挂在哪一层。6.3 最后分享一个我自己的调试习惯每次插拔 HDMI 之后我都会先执行一条三连命令把最核心的状态一次性抓出来adb shell dumpsys audio | grep -E Devices|Output -A 5 adb shell tinymix | grep -i hdmi adb shell cat /proc/asound/cards这三条命令 30 秒内就能让你对整个音频链路有一个相对完整的概念Framework 认为音频应该给谁ALSA 实际把音频路由到了哪里声卡节点是否活着。结合 logcat 的 AudioPolicyManager 输出基本可以搞定 80% 的 HDMI 音频问题。插入 HDMI 后没有媒体声音这个问题的尽头往往不是一个复杂的内核补丁而是 Framework 与 HAL 之间一次微妙的时序错配。Android 14 把规范做得越严格底层实现的细节就越容易被放大。以后大家再碰到类似问题别只盯着弹窗或者只盯着没有声音先把三层链路对一遍就成功了一半。