1. 问题现场与思路收敛：HDMI弹窗和消失的媒体声音并非两件事
手里这台RK3576 Android14设备是很典型的商显/盒子形态，平时跑在TP显示屏上一切正常，但只要一插上HDMI线，问题就扎堆冒出来：先是屏幕右上角弹出一个“HDMI已连接”之类的系统提示，紧接着系统界面开始申请权限弹窗，再往下，正在播放的媒体声音直接消失，进度条还在走，但就是听不到任何声音。
这种“插线即出问题”的现象，客户反馈过来的时候第一反应是弹窗和声音是两件事，要分开排查。但我做系统调试这些年有一个经验：在同一时刻爆发的多个异常，往往不是多个独立bug，而是同一次系统事件触发的多米诺骨牌。HDMI热插拔这个动作，在Android14里同时驱动了两条链路——一条是DisplayManager的显示设备变更链路，一条是AudioService的音频路由重估链路。弹窗是系统对这次变更的“显性反馈”，声音丢失则是路由重估过程某个环节出现了偏差。两个现象在时间轴上完全重叠，基本可以判定是同一个根因，只是表现不同。
先把问题面收回来看：我们要处理的不是“弹窗怎么办”和“声音怎么办”两个并列子任务，而是先搞清楚HDMI插拔后系统到底做了什么，弹窗是哪一层弹出的，声音路由在哪一步断了。这样排查起来才不会东一榔头西一棒子。
1.1 插线瞬间到底弹了什么窗
很多人一听到弹窗就往权限申请上想，但这其实是个误区。HDMI插拔后的弹窗至少分三类，处理方式完全不同。
第一类是最常见的系统提示弹窗，由SystemUI或者系统设置弹出，比如“HDMI已连接”“已切换到HDMI音频输出”之类。这类弹窗本质是系统对显示/音频切换的反馈，不涉及用户授权，处理上是“要不要显示”的问题。
第二类是权限申请弹窗，这在Android14上尤其需要注意。Android14对运行时权限的策略又做了收紧，尤其在通知权限、媒体权限、附近设备权限这几块，插上HDMI后如果有应用监听到设备变化并尝试访问对应资源，就可能触发权限申请。这属于“要不要弹、何时弹”的策略问题。
第三类是应用自绘弹窗，也就是应用自己在代码里监听HDMI插拔事件，然后弹自己的Dialog或者Toast。这种最隐蔽，也最容易和系统弹窗混淆。之前我就遇到过一个案例，产品方一口咬定是系统弹窗，最后抓窗口焦点发现是某个预装视频应用监听了HDMI事件后自己弹的“检测到外接显示”。
定位方法其实不复杂。设备接上HDMI线复现问题，同时执行下面这条命令看当前焦点窗口落在哪个进程：
adb shell dumpsys window windows | grep -E "mCurrentFocus|mFocusedApp"如果弹窗进程是com.android.systemui，那基本是系统级弹窗；如果焦点落在某个三方应用包名上，那就是应用自绘弹窗。再把logcat里带ActivityRecord或者ActivityTaskManager关键字的输出捞出来，能看到弹窗Activity的完整启动栈，直接定位到具体代码路径。
1.2 媒体声音消失的三种“假象”
再说声音。插上HDMI后“没媒体声音”这个描述其实很模糊，必须先分辨是真没了还是假没了。我把实际工作里遇到的情况归纳为三种：
第一种，所有声音都没了。媒体、通知、铃声全部静音，拔掉HDMI后也未必能恢复。这种情况通常是音频路由重估后没有正确回退到内置设备，或者底层HDMI音频通道占用了但没真正打开，属于典型的“路由卡死”。
第二种，只有媒体流没声音，通知音、按键音都正常。这是最典型的路由选择问题：Android音频策略引擎把媒体流策略切到了新插入的HDMI输出设备上，但HDMI设备的输出流并没有正常建立——比如音频HAL层在device switch时返回了错误，导致上层以为切过去了，底层实际没声音。
第三种，播放器的进度条正常走，但音量调整无效，声道信息变成了“未知”。这种往往是AudioTrack已经绑定到HDMI输出通道，但HDMI另一端（比如显示器或者电视）没有正确的音频解码能力，或者ARC/eARC通道没有协商成功。卡在链路物理层。
区分这三种情况很简单：插上HDMI后先别急着重启，打开系统设置里的声音页面，播放一个系统提示音测试。如果提示音有声音而媒体没声音，那么问题基本锁定在媒体策略的路由分配上；如果提示音也没声音，那就得从设备级路由和HAL层去查。
1.3 把两个现象放进同一条因果链
顺着“HDMI热插拔是同一个事件源”这个思路，我更喜欢用一张脑内的时序图来组织排查路径：插线动作触发内核的uevent事件，上层InputReader/DisplayManagerService/ AudioService几乎同时收到回调；DisplayManagerService更新显示设备列表之后，SystemUI通过监听ACTION_HDMI_PLUGGED更新UI提示或者弹窗；AudioService则触发setWiredDeviceConnectionState，对当前的音频设备矩阵做一次重新评估。
问题就出在这个“同时”。弹窗是否弹出，取决于SystemUI有没有正确监听显示事件；声音是否保持，取决于AudioService能不能在设备切换时保住当前音频流的路由会话。如果SystemUI和AudioService之间的状态同步出现偏差，比如SystemUI认为HDMI已经接管了音频输出，而AudioService实际没有把音频流迁移到HDMI设备上，就会出现“界面显示已切换、声音实际没过来”的割裂状态。
所以我的排查原则是：先抓事件链路本身的时序和状态，确认是哪一层掉了链子，而不是分别去“修弹窗”和“修声音”。这是一个系统工程问题，必须从根上把链路线理顺。
2. Android14音频策略变化：为什么“可剥离设备”成了HDMI断声的高发点
很多从Android11、Android12升级上来的开发和测试，会对Android14音频行为的变化感到陌生。最直观的感受是：插拔HDMI时声音设备的切换比以前更“敏感”了，有时候拔掉HDMI，声音却没有回到内置喇叭；有时候插上HDMI，媒体声音直接消失。这些现象背后，是Android14对音频设备生命周期管理策略的一次重要调整。
2.1 Android14里的“可剥离设备”是什么
先说一个关键概念：Android14在AudioService层引入了更严格的“可剥离设备”（strippable device）处理逻辑。所谓可剥离，指的是当某个物理端口上的连接被移除后，与该端口绑定的所有音频设备都要一起从可用设备集合中移除，包括那些逻辑上挂接在这个物理口上的子设备。
这个概念用大白话讲就是：以前系统认为“HDMI口拔了，HDMI音频设备就不可用了”，Android14把这个逻辑进一步收紧——不仅HDMI口自身要标记为移除，挂在这个HDMI链路下的所有派生设备（比如通过HDMI转出的音频接口）也要一并移除，而且在移除后不允许继续持有之前建立的路由状态。
这个设计出发点是好的，能避免设备状态残留导致的误路由。但在实际工程里，这个机制和不同厂商的音频HAL实现之间存在配合问题。尤其是RK3576这类平台，HDMI音频通常由专有的音频HAL节点管理，HAL在收到设备移除事件后需要主动释放对应的输出流。如果HAL层的释放时机比上层状态清理晚，就会短暂出现“上层已经标记设备移除、底层还在占用”的死角，最终表现为拔插之后音频路由卡死在半路。
2.2 HDMI在AudioPolicy中的身份与路由优先级
在Android的音频策略体系里，HDMI通常作为一个独立的输出设备（AUDIO_DEVICE_OUT_HDMI）声明在audio_policy_configuration.xml中，并且通过AudioPolicyManager里的策略路由表参与所有音频流的输出路由决策。
这里有一个很多人没注意到的优先级问题：在Android默认的音频策略里，HDMI设备的优先级并不比Speaker高多少，但它有一个特殊属性——它是“外部可见设备”。当HDMI插入时，系统的AudioPolicyManager确实会把媒体、系统、语音等策略的默认输出设备引导到HDMI上，但前提是这个设备在策略表里被正确关联到了对应的输出端口（mixPort）。
如果设备树里HDMI的mixPort和devicePort没有建立正确的映射关系，或者设备端口类型写错了（比如写成了AUDIO_DEVICE_OUT_HDMI但底层对应的声卡不是HDMI声卡），AudioPolicyManager在做路由决策时就会出现两种表现：要么平台切不过去，媒体流继续留在Speaker上但HDMI没有声音；要么平台切过去了，但切到的是一个伪造的“空”设备上，底层根本没有实际的输出流。
在RK3576的调试中，我见过最多的问题就是把HDMI配置成了AUDIO_DEVICE_OUT_HDMI，但声卡节点实际是HDMI_ARC或者HDMI_RX，类型不匹配导致路由判断失效。这种配置错误在Android11及以下通常还能靠兼容逻辑蒙混过关，到了Android14对设备类型校验更严格之后，就直接暴露成没声音了。
2.3 可剥离机制和媒体流的冲突点
再往深一层说，Android14可剥离机制对媒体流的冲击在这两年特别突出，原因是Android14的音频策略变化引入了更激进的“设备状态快速同步”：系统在热插拔事件中快速地把旧的音频会话拆掉，再尝试建立新会话。如果媒体应用没有及时响应会话重建，比如没有重新创建AudioTrack，就会停在“旧会话已销毁、新会话未建立”的真空期。
这个真空期对短促的事件来说通常只有几百毫秒，用户感知不强。但在HDMI插拔这类频繁触发设备重估的场景下，如果底层HAL的状态恢复又慢，真空期可能被拉长到几秒甚至永久丢失。解决这类问题，不能只在上层打补丁，得从HAL层和设备路由两个维度同时校验状态完整。
3. 弹窗来源定位：从SystemUI到应用自绘的层层剥茧
弹窗这个问题，定位起来其实比音频路由更讲究方法。因为“弹窗”是一个很笼统的产品描述，可能来自系统设置、SystemUI、权限管理服务，甚至是某个应用在后台自己绘制的界面。每一层有不同的处理手段和修复路径。
3.1 用窗口焦点与Activity栈抓“凶手”
我每次排查弹窗问题时，第一件事就是抓当前窗口的焦点归属，而不是直接去翻代码。命令刚才提过一次，这里再给一套更完整的组合拳：
# 查看当前焦点窗口和焦点应用 adb shell dumpsys window windows | grep -E "mCurrentFocus|mFocusedApp" # 查看顶层窗口的所有Window信息，包括Token和包名 adb shell dumpsys window windows | grep -E "Window #|package=" # 查看正在显示的Activity栈 adb shell dumpsys activity activities | grep -E "topResumedActivity|mResumedActivity"如果抓到弹窗包的包名后，需要进一步确认是谁启动了这个弹窗Activity，可以查看ActivityTaskManager的启动日志：
adb logcat -b events | grep -E "am_activity_launch_time|am_proc_start|am_create_activity"通过am_create_activity会打印出caller字段，这个字段明确记录了是谁调用了startActivity。有一次排查一个“HDMI插入后弹权限申请”的问题，通过这个字段发现弹窗并非系统权限管理主动弹出，而是某个媒体扫描服务在收到设备挂载事件后自己调用权限请求接口触发的。如果不看caller，就会误改系统权限策略那边，白忙活半天。
3.2 Android14上HDMI事件会触发哪些系统级弹窗
插上HDMI后，Android14系统本身通常会产生不了太多“系统级”弹窗。多数情况下，会触发的有这几种：
第一是HDMI/显示输出提示。这类提示一般由SystemUI里的DisplayManager监听实现，表现为顶部通知或短暂Toast，内容类似“已连接到外部显示”。Android14对这类提示做了限制，是否显示取决于显示策略配置。
第二是音频路由切换提示。插入HDMI时，如果当前有媒体播放，AudioService会发送ACTION_AUDIO_BECOMING_NOISY广播，接着媒体应用（比如播放器）可能弹出“音频输出已切换”之类的提示，或者直接走自己的错误处理逻辑弹出播放失败的对话框。这类弹窗在用户看来是系统弹窗，其实完全由应用自己控制。
第三是权限弹窗。Android14真正变的权限点是：如果应用需要在后台读取媒体信息或接收音频相关信息，必须合理声明权限并在合适时机弹出。但正常情况下，HDMI插拔不会主动唤起权限弹窗，除非某个应用在广播接收器里触发了需要权限的操作。
所以，看到“弹窗”不要急着去系统设置里关弹窗开关，先判断它是哪一层弹出的。这决定了后续修复是改SystemUI，还是改应用，还是改权限策略配置。
3.3 应用自绘弹窗的典型路径
再说一种我实际处理过多次的情况：某些预装应用在AndroidManifest.xml里注册了ACTION_HDMI_PLUGGED静态广播接收器，这个广播是系统发送的隐式广播，应用收到后在onReceive里直接弹出了自定义Dialog。
这种弹窗非常难缠，因为它不影响系统本身，但从用户角度看就是“系统在乱弹”。定位时需要把焦点窗口信息和logcat里的BroadcastQueue日志配合起来看：先确认应用的广播接收器有没有被触发，再看onReceive里有没有startActivity或者弹窗口的代码。找到之后通常的做法有两个——要么去掉这个静态广播注册，要么在代码里增加判断条件，仅在应用处于前台时才响应HDMI事件。
4. 一条完整的排查链路：从logcat、dumpsys到AudioPolicy配置
前面把弹窗和声音的问题面分别铺开了，但没有跑通一条完整的排查链路，问题还是悬着的。这一节把我在RK3576 Android14平台上处理这类问题的完整套路写出来，每一步都有可执行的命令和判断标准。
4.1 logcat关键字抓法
先不要急着翻全量日志，日志太多反而找不到重点。我通常按事件发生时间点前后各30秒抓一次日志，过滤关键字这样设置：
adb logcat -v threadtime | grep -E "HDMI|AudioService|AudioPolicyManager|AudioFlinger|DisplayManager|WiredDevice|setWiredDeviceConnectionState"这几个关键字分别对应：HDMI热插拔事件、音频服务状态变更、音频策略路由决策、音频Flinger内部状态、显示设备管理、有线设备连接状态。把日志抓回来后，我的关注顺序是：
- 先在
DisplayManager日志里确认HDMI插拔事件有没有被系统感知。 - 再在
AudioService日志里找setWiredDeviceConnectionState的调用记录，确认音频服务有没有响应这次设备变更。 - 然后在
AudioPolicyManager日志里看策略路由是怎么决策的，目标设备是谁。 - 最后在
AudioFlinger日志里看输出流的打开/关闭状态，确认HAL层有没有真正执行。
这四层都通了，问题一般就出在应用层没适配；哪一层断了，哪一层就是主嫌疑区。
4.2 dumpsys里最有价值的几个区段
logcat讲的是“发生了什么”，dumpsys讲的是“现在是什么状态”。两者要配合看。下面几个dumpsys是排查HDMI音频问题必须执行的：
# 查看全局音频状态，包括当前路由、音量、设备列表 adb shell dumpsys audio # 查看AudioPolicy的状态，包括策略路由表和活动设备 adb shell dumpsys media.audio_policy # 查看显示设备状态，确认HDMI是否被正确识别 adb shell dumpsys display | grep -E "HDMI|mDisplayDevices|mWifiDisplay"执行dumpsys audio后，重点看这两块：
STREAM_MUSIC的输出设备（Devices）是哪个。正常状态下插上HDMI时应该看到类似type: TYPE_HDMI的输出设备；如果还停在TYPE_BUILTIN_SPEAKER，说明路由策略没有正确迁移，那就是AudioPolicy层的问题。
再看AudioPolicyManager里的“策略路由表”部分，确认getDeviceForStrategy对STRATEGY_MEDIA返回的设备是不是HDMI。如果这里返回的是Speaker，但实际HDMI已经插入，说明策略表根本没把HDMI列进媒体策略的可选设备里。
4.3 复现一次并比对音频路由状态
单看一次dumpsys还不够。我会在插HDMI线前后各做一次状态快照，保持媒体播放不停，然后对比差异：
# 插线前 adb shell dumpsys audio > before.txt # 插上HDMI线，等待5秒 # 插线后 adb shell dumpsys audio > after.txt # 对比 diff before.txt after.txt插线后重点看几条差异：AudioPolicyManager中的活动设备是否从Speaker变成HDMI；AudioFlinger里的输出线程有没有新增HDMI相关的线程；AudioService的声卡管理里有没有注册新的声卡。有一次就是通过这个对比发现插线后AudioPolicyManager把活动设备切成了HDMI，但AudioFlinger层根本没生成对应的输出线程，说明音频HAL的so文件里HDMI输出对应的声卡没绑定上，问题直接锁定在HAL层驱动，绕开了上层所有猜测。
4.4 当“插上HDMI后就没媒体声音”的具体定位
针对开头热搜里那个“插上HDMI线后就没媒体声音”的高频问题，我按排查顺序给一套通用解法。
首先插上HDMI后，马上执行：
adb shell cat /proc/asound/cards看系统里有没有多出一张HDMI或显卡对应的声卡。如果声卡列表里根本没有新增节点，说明底层的ALSA驱动层面HDMI音频就没有被创建，这个问题不需要看Android上层逻辑，直接去查内核设备的HDMI audio bridge注册和声卡探测流程。
如果声卡列表里已经出现了HDMI声卡（通常名为HDMI或者card1之类），则继续执行：
adb shell cat /proc/asound/card1/stream0看这个声卡目前处于什么状态，是closed还是running。如果声卡已经被上层打开但stream状态异常，那问题就在音频HAL层；如果声卡完全没有被打开，问题就在AudioPolicy或AudioService层。
这层判断非常关键。我曾经因为跳过这个步骤，直接去改上层路由配置，折腾了两天一无所获，最后发现是内核设备树里HDMI音频节点的status被设置成了disabled，声卡压根没有注册。顶层系统再努力，底层没有设备也没有意义。
4.5 事件时序的隐性坑位
最后留意一个容易忽略的时序问题。插上HDMI后，Android系统的显示事件和音频事件不是完全同步到达的：DisplayManager通常先收到热插拔事件并更新显示状态；AudioService收到音频设备变更事件会有几十到几百毫秒的延迟，取决于内核上报事件的间隔。如果系统UI在收到Display事件后立刻弹窗提示“HDMI已连接”，而此时音频路由其实还没切换过来，用户看到的现象就是“弹窗先出现、声音后消失”，或者“弹窗出现后声音直接没了”。这是正常的时序差，不一定是bug。排查时建议把两次事件的时间戳记下来，判断延迟是否在合理范围内。
5. 修复与规避：从配置、代码到产品侧的三层处理
排查链路走完，问题点基本能锁定在某一层。修复思路也要分层来做——不是所有问题都适合改代码，有的改配置，有的改产品逻辑，有的需要应用侧配合。
5.1 audio_policy_configuration.xml里的设备声明检查
先检查配置文件，这是最基础的层面，也是很多问题的根源。在RK3576平台上，audio_policy_configuration.xml一般在/vendor/etc/目录下，它的结构里的devicePorts部分需要正确声明HDMI输出设备：
<devicePort tagName="HDMI Out" type="AUDIO_DEVICE_OUT_HDMI" role="source"> <profile name="" format="AUDIO_FORMAT_PCM_16_BIT" samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/> </devicePort>重点检查几个字段：
type必须是AUDIO_DEVICE_OUT_HDMI，不能写成HDMI_ARC或HDMI_RX，否则类型不匹配导致路由决策跳过这个设备。profile里的采样率和声道数要和实际HDMI接收端的能力匹配，如果只声明了48kHz但实际设备只支持44.1kHz，切换后可能出现“essentially无声”（音频流创建失败所以无声音）。samplingRates这一项不要太激进，宁可声明少一点，也不要声明超过实际能力的值。
另外检查mixPorts里有没有HDMI对应的输出端口，以及route里是否把mixPort和devicePort做了关联。很多配置漏了route关联，导致策略引擎看得到设备却选不中它。
5.2 代码层兜底
配置改完还没解决，就要上代码层。这里给两类方案。
第一类面向系统层修复，适合平台工程师。如果确认是AudioPolicyManager的路由决策异常导致切到HDMI后无输出流，可以在AudioPolicyManager::getDeviceForStrategy中增加HDMI热插拔状态判断，在设备状态未稳定前不要立刻把媒体策略切到HDMI，而是等AudioService确认底层输出流创建成功后再执行路由切换。这个做法需要对AOSP代码有深入了解，不适合普通应用开发者，但效果最直接。
第二类面向应用层，适合做播放器的同学。你可以在自己的播放器里监听ACTION_HDMI_PLUGGED和ACTION_AUDIO_BECOMING_NOISY广播，在收到设备切换事件后重新创建AudioTrack，并把路由重新指定到新的输出设备。
private final BroadcastReceiver hdmiReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { if (Intent.ACTION_HDMI_PLUGGED.equals(intent.getAction())) { boolean state = intent.getBooleanExtra(Intent.EXTRA_HDMI_PLUGGED_STATE, false); if (state) { // HDMI插入：重新初始化音频输出通道 restartAudioTrack(); } } else if (AudioManager.ACTION_AUDIO_BECOMING_NOISY.equals(intent.getAction())) { // 音频输出设备发生变化：暂停播放或重新路由 restartAudioTrack(); } } };这个办法看起来是“绕弯路”，但在系统问题没有彻底修复前，是保证用户基本体验的最稳妥方案。至少不要让播放器死在一个已经失效的音频会话上。
5.3 产品侧规避
最后是产品层面的规避。有些问题根因在硬件或者HAL层，短时间改不动，那就要靠产品策略来缓解。比如在系统设置里提供一个“HDMI音频输出”开关，默认不自动切换；或者把HDMI插入后的音频切换策略改为“提示用户，由用户选择”，而不是系统自动切换。Android原生没有提供这个开关，但可以通过修改SettingsProvider的默认值或者增加自定义设置项来实现。
对于商用设备，这块尤其重要。因为这些设备通常是7x24小时运行，用户不会去重启它，一旦路由卡死就是永久性故障，必须靠产品逻辑兜底。
6. RK3576平台专项：为什么这类问题在RK上更容易暴露
前面聊的很多问题在通用平台也可能出现，但RK3576这类瑞芯微平台有一些自己的特殊性，导致HDMI音频问题更容易暴露，也更容易让排查人员迷惑。
6.1 音频HAL与声卡注册的差异
RK平台的音频HAL通常是基于tinyalsa实现的，和主流高通平台基于音效框架的实现方式不同。RK的HDMI音频声卡往往是在内核里通过hdmi-audio节点和设备树配置创建的，声卡编号不稳定，可能每次开机后编号不同。如果上层audio_policy_configuration.xml里硬编码了声卡名称或者设备地址，就会因为编号漂移导致设备识别失败。
排查时先确认声卡情况和设备树里HDMI音频节点的状态：
adb shell cat /proc/asound/cards adb shell dumpsys media.audio_policy | grep -A5 "rkm" # 查看设备树里hdmi音频节点状态（需要root） adb shell cat /proc/device-tree/display-subsystem/route/hdmi/status如果设备树里该节点被禁用，内核的HDMI音频驱动就不会触发声卡注册，上层做再多事都没用。这个检查放在最前面做，能省下大量时间。
6.2 硬编码与兼容机制的坑
RK平台另一个常见问题是：厂商在适配Android14时，往往直接在低版本的基础上做了配置继承，把Android11或12的audio_policy_configuration.xml原封不动搬到Android14上。低版本的配置文件里，devicePorts的字段写得比较随意，比如没有声明profile、采样率只写一个，这在低版本上还能运行，但在Android14更严格的校验下直接就解析异常，导致HDMI设备参与不了路由决策。处理方法是重新按照Android14的schema梳理一遍配置，把所有devicePort和mixPort的完整属性补齐。
6.3 拔线恢复问题在RK平台上的特殊表现
再说一个RK平台的老大难——拔掉HDMI后媒体声音不恢复。这个问题和Android14的可剥离机制叠加后会变得更明显。复盘下来，核心原因是：拔线的瞬间，AudioPolicyManager把HDMI设备标记为不可用，但由于RK的HDMI驱动在拔线后会短暂保留声卡节点几百毫秒，底层声卡还没完全消失，上层就把“HDMI设备仍存在但不可用”当成可用设备来路由，媒体流被导向一个半死不活的设备上，产生类似“死锁”的效果。
这类问题在系统层还没有干净解法的前提下，我建议优先走应用层兜底方案：应用监听ACTION_AUDIO_BECOMING_NOISY广播，收到后延迟1~2秒重新设置媒体路由回Speaker。这个延迟窗口要设计好，太短声卡还没清理干净，太长用户感知明显，实测1.5秒左右在多数RK平台上体验最顺。
6.4 平台调音与采样率不匹配
RK平台的HDMI音频还有一个隐蔽但发生率很高的问题：采样率不匹配。很多RK3576方案的默认音频采样率是48kHz，但如果后端显示器/电视端的EDID里只声明了44.1kHz或32kHz，那么切换后音频流创建会静默失败，表现为“播放器正常但无声”。确认方法：
adb shell cat /sys/class/display/hdmi/edid重点看EDID里音频数据块声明了哪些采样率。如果EDID只支持44.1kHz，而Android配置里强制48kHz输出，就需要调整配置，或者在内核音频驱动里做重采样。这个问题在低版本Android上被驱动层的重采样逻辑掩盖了，但在Android14上由于对采样率匹配的校验更严格，会直接表现为断声。
最后再说几句实操体会
这套排查链路走了无数遍之后，我最大的感受是：HDMI弹窗和没声音这类问题，其实是在考验你对Android事件链路的整体把握能力。很多人一上来就翻代码、找弹窗组件、改音频配置，方向错了，花再多时间都没用。先确认事件有没有到，再确认服务有没有响应，然后确认策略有没有决策，最后确认HAL有没有执行——按这个顺序一层层排查，绝大多数问题能快速定位。
另外一个小技巧：排查这类问题时别只开一个logcat窗口，建议开四个独立终端，一个跟显示、一个跟音频、一个跟Activity生命周期、一个打dumpsys快照，这样能最大程度还原现场时序，很多“玄学问题”其实是事件穿插顺序造成的误判。这套方法不光适用于RK3576，其他平台的HDMI音频问题，也完全适用。希望这篇记录能帮到你少走一些弯路。
