企业官网建设流程全解析

插上HDMI线之后，盒子或者开发板上的媒体声音突然就没了，屏幕上还时不时弹一个音频输出切换的提示框，点掉也不行，重启有时候能好，有时候又复发。最近不少做RK3576方案的朋友都撞上这个问题，而且现象高度一致：Android 14系统，HDMI Hotplug事件一切换，媒体音频直接哑火。这篇东西不打算泛泛讲“什么是弹窗问题”，直接拆解我在这个平台上排查和修复的完整过程，包括音频路由机制、焦点抢占、Hal策略这几个真正藏雷的地方，手把手把日志分析和代码改法都过一遍，希望能帮正在调这块的同行省几天时间。

1. 问题表象拆解：这其实是个“弹窗+路由”的复合问题

1.1 弹窗类型与触发场景

很多人在RK3576开发板上遇到“弹窗问题”时，第一反应是去查PowerDialog、手机管家或者某个App的通知权限，但实际上在Android 14的TV/Box类设备上，真正频繁出现的弹窗就那么几类。

• 音频输出切换提示：插入HDMI后，系统检测到新音频输出设备，弹一个“音频输出已切换”或“当前使用HDMI输出”的提示，这类弹窗通常由SystemUI或AudioService触发，行为上更像“路由通知”，而不是传统意义的对话框。
• 权限申请弹窗：某些预置App申请“附近设备”或“通知使用权”，在Android 14里权限策略收紧后，插拔HDMI这种硬件事件反而容易触发连锁申请，干扰用户操作。
• 应用崩溃弹窗：HDMI插入导致音频焦点变化，部分不兼容的播放器在AudioManager接口异常时崩溃，出现“XX已停止运行”。

把视线拉回开发阶段，大家抱怨最集中的其实是：一插HDMI，媒体声音消失；伴随一个路由通知弹窗；焦点被通知类声音抢走，播放器暂停或静音。

1.2 无媒体声音的真正痛点

弹窗只是表象，核心痛点是“音频为什么没走HDMI”。在常见开发板上，HDMI既负责显示又承载音频信号，插上后理论上应该自动把媒体声音切换到HDMI声道。但Android 14对于音频策略做了一轮调整，加上RK3576的HAL层音频拓扑比较复杂，导致路由切换没有按预期执行，现象就是“电视有画面但没声音”。

这个问题的本质可以拆成两个层面：

• 系统层面：AudioPolicyManager在处理HDMI插拔时，是否需要真正切换设备？还是保持当前输出，同时让HDMI作为备用设备？
• 应用层面：当前媒体播放器是否响应AudioFocus变化，是否在失去/获得焦点时错误地暂停或调低音量。

1.3 为什么Android 14上更容易暴露

Android 14相比旧版本，在音频框架上引入了更多状态监听，特别是对设备切换事件的处理更激进：插入HDMI后，AudioPolicyManager会尝试建立新的输出流，如果新的AudioPatch创建失败或者路由策略里没有配置HDMI输出，系统会退回原输出路径，但是UI上已经把设备状态切过去了，这时候播放器收到异常回调，就会出现“设备显示已连接但无声”。

另外，Android 14对AudioManager的全局音量做了更严格的分区管理，媒体音量、铃声音量、闹钟音量彻底分离，很多定制ROM在适配时忘记给HDMI输出配置独立的音量曲线，导致硬件上已经切换了，但音量曲线映射到0，听起来就像完全没有声音输出。

2. 深入机制：HDMI插拔、音频焦点与路由策略

2.1 事件链路：从物理插拔到音频设备切换

先捋一下整个事件链路。当你插入HDMI线，底层驱动会触发一个uevent事件，经过AudioService的处理，最终反应到音频设备和路由状态。熟悉这条链路，后面的排查才有章法。

1. 底层检测：HDMI的Hotplug状态由显示驱动和音频驱动共同上报，通常是/dev/switch或/sys/class/switch/hdmi，RK平台一般会在drivers/video/rockchip/hdmi底层驱动里上报状态变化。
2. 框架层接收：WiredAccessoryManager或AudioService收到设备插拔广播后，会调用AudioSystem.setDeviceConnectionState。
3. 路由决策：AudioPolicyManager根据当前音频配置，决定新的音频输出设备组合。它需要查audio_policy_configuration.xml里是否有HDMI对应的输出端口和混音策略。
4. 输出流切换：如果决策结果是把HDMI加入活动输出设备，audio HAL层会打开对应的HDMI声卡设备，建立AudioPatch。
5. 应用感知：AudioService同步发送ACTION_AUDIO_BECOMING_NOISY等广播，并且处理AudioFocus变化，通知上层App。

多数无声音的问题，都出在第3步和第4步之间：策略决策了，但HAL层操作失败，或者输出流参数不匹配。这部分在Android 14里比旧版更容易触发，因为新架构对音频设备组合的校验更严格。

2.2 弹窗如何“杀掉”媒体声音

弹窗本身不产生声音，但弹窗会引起AudioFocus请求。Android 14里，系统通知音和路由提示音往往使用AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK或AUDIOFOCUS_GAIN_TRANSIENT，如果某个App申请了AUDIOFOCUS_GAIN并且指定了延迟焦点，一场“焦点战争”就开始了。

常见的表现是这样的：用户插HDMI，系统弹出路由提示，同时播放一段提示音。提示音应用获得Transient焦点，正在播放的媒体App被迫暂停。提示音响完，焦点应该归还给媒体App，但如果媒体App在Android 14上使用了AudioFocusRequest的新接口而忘记设置setWillPauseWhenDucked等参数，就可能造成焦点归还失败，播放器一直处于暂停状态。媒体声音就这样消失了，不是硬件问题，而是焦点管理被弹窗打断。

2.3 Android 14的“路由通知”行为

Android 14在SystemUI里增加了一个“音频输出切换通知”的功能，类似手机上的媒体控制栏。它会在检测到新的音频设备时弹出一个小通知，用户可以手动切换输出设备。

在手机上这是加分项，但在TV/Box上反而是负担。尤其是RK3576这类方案，默认输出是HDMI，插入HDMI这种“开机就要用”的操作根本不需要弹窗提示，多余的交互反而把应用焦点带乱。调试阶段，系统弹出的设备切换通知会频繁暂停正在播放的视频，让测试人员误以为是没声音。

3. 定位实操：一份能直接落地的排查清单

3.1 复现与日志收集

不要一上来就改代码，先拿到完整日志。

复现步骤建议固定：开机 -> 启动媒体播放器（YouTube、本地播放器都可以）-> 播放一个连续音频/视频 -> 插入HDMI线 -> 观察声音消失时间点 -> 拔掉HDMI -> 再次观察。

日志收集分几路并行：

• logcat -s AudioService AudioPolicyManager AudioFlinger AudioTrack：跟踪音频服务和路由决策日志。
• dumpsys audio：查看当前音频设备连接状态、输出流和音频焦点持有者。
• dumpsys media.audio_policy：查看策略引擎里的设备组合和路由状态。
• cat /proc/asound/cards：确认HDMI声卡是否被内核识别。
• tinymix或tinyhal相关命令：检查HAL层声卡路由和Mixer控件状态。

日志要保留插入前后的完整片段，重点看从WiredAccessoryManager或AudioService收到设备连接变化，到AudioPolicyManager完成Mixer配置这一段。

3.2 复现场景中的关键日志解读

实际抓日志时，优先搜索这些关键字：

• setDeviceConnectionState：确认系统有没有收到HDMI设备插入事件。
• getDeviceForStrategy：确认决策引擎是否为媒体流选择了正确的设备。
• startOutput：确认音频输出流是否被建立。
• AudioPatch或createAudioPatch：确认底层patch有没有创建成功。
• focus或AudioFocus：确认焦点变化路径，谁申请了焦点、谁释放了焦点。

如果在日志里看到设备切换成功了，但startOutput用的device参数还是原来的Speaker或耳机，那说明策略配置有问题。如果createAudioPatch失败，需要检查audio_policy_configuration.xml里HDMI的端口定义和mixport配置。

3.3 快速检查设备与焦点状态的命令

# 查看当前音频设备连接状态 adb shell dumpsys audio | grep -E "Devices:|state:" # 查看音频策略设备组合 adb shell dumpsys media.audio_policy | grep -A 20 "strategies" # 查看当前持有音频焦点的应用 adb shell dumpsys audio | grep -A 30 "Audio Focus" # 查看声卡设备列表 adb shell cat /proc/asound/cards

拿到这些信息，基本能判断声音是死在HAL层、死的策略层还是死在应用层。

4. 修复思路：RK3576平台上的几个落地方向

4.1 调整audio_policy_configuration.xml的HDMI输出声明

如果日志显示媒体流没有路由到HDMI，多半是策略配置里媒体策略没有声明HDMI输出设备。在RK3576的Android 14 SDK里，默认配置一般在device/rockchip/rk3576/audio/audio_policy_configuration.xml。

需要确认：

• audioPolicyConfiguration里包含hdmi输出端口（AUDIO_DEVICE_OUT_HDMI）。
• mixPorts里定义了hdmi输出，并且全局配置中允许Media策略使用该端口。

常见配置片段如下：

<mixPort name="hdmi" role="source"> <profile name="" format="AUDIO_FORMAT_PCM_16_BIT" samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/> </mixPort> <devicePort tagName="HDMI Out" type="AUDIO_DEVICE_OUT_HDMI" role="sink"> <profile name="" format="AUDIO_FORMAT_PCM_16_BIT" samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/> </devicePort> <route type="mix" sink="HDMI Out" sources="hdmi"/>

然后检查attachedDevices里有没有HDMI Out。如果没有，加上：

<attachedDevices> <item>HDMI Out</item> </attachedDevices>

改完配置后，要重新编译并push到/vendor/etc/，然后重启音频服务或整机重启。这类修改影响整机路由，千万别只改一半就上产线，很容易把不插HDMI时的Speaker声音也搞坏。

4.2 修改或抑制AudioFocus抢占

如果日志显示焦点管理混乱，更直接的办法是减少系统中不必要的焦点申请。

首先，检查是否有预置应用在插入HDMI时触发语音助手或通知音。这类应用往往用旧接口requestAudioFocus来申请不需要的焦点。若有代码权限，建议去掉这层请求。

其次，定制SystemUI时，可以在AudioOutputDialog或相关路由通知组件里，移除自动播放提示音的逻辑。这是最多余的设计，插入HDMI本来就是常用操作，每次插都“叮”一声，听感不好，还会把媒体播放器焦点带走。

如果不想改Java层代码，可以尝试在AudioService里把路由提示音的声音流类型改成STREAM_SYSTEM，并设置低音量，但这种方式收益有限，焦点冲突的本质问题还在。

4.3 处理音量曲线映射问题

前面提到设备切换后无声，还有一种可能是音量曲线映射异常。RK平台一般会在vendor/rockchip/hardware/audio或hardware/rockchip/audio下有一个音量曲线相关的参数文件，比如AudioVolumes.xml。

确认STREAM_MUSIC的默认音量映射有没有覆盖HDMI设备。如果配置了不同设备使用不同音量曲线，而HDMI对应的一列是空的或者数值为0，那么即使在UI上调大音量，底层实际衰减仍是0，声音出不来。

对比一下正常Speaker设备和HDMI设备的volume映射：

<volume stream="STREAM_MUSIC" deviceCategory="DEVICE_CATEGORY_OUTPUT"> <point>0,0</point> <point>100,100</point> </volume>

如果写入100还是没声音，多半不是曲线问题，而是Hal层Mixer控制没打开。

4.4 验证HDMI ARC与Passthrough的特殊场景

如果你验证的时候发现普通PCM有声音，但插上支持ARC的电视后没声音，那问题可能是出在音频直通（Passthrough）配置上。

HDMI ARC模式下，电视会把音频回传给盒子或开发板处理，如果Android 14配置了passthrough的音频滤镜，但rk3576 HAL不支持某些格式，就会出现“直通格式无声音”。这种场景下，可以尝试在audio_policy_configuration.xml里为HDMI输出禁用或减少Passthrough格式：

<profile name="vedio" format="AUDIO_FORMAT_E_AC3" samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_5_1"/>

如果电视回传的是E-AC3但系统没有license，输出就静音。调试阶段可以先把这类直通格式注释掉，强制走PCM验证基础链路。

4.5 从HAL层确认声卡路由

如果代码层确认都没问题，就要下沉到HAL层。用tinymix查一下HDMI声卡的路由寄存器，重点看I2S或者DP音频输出是否被静音。

adb root adb shell tinymix -D 0 adb shell tinymix -D 3

我遇到过的情况是：HAL层打开了HDMI声卡，但某个Mixer控件（比如HDMI/DPTX Audio Switch）没有使能，导致信号根本没送到编码器。RK平台每块板子声卡布局不一样，用tinymix先把所有控件状态打印出来，和正常工作时的状态做对比，很快能找到差异。

5. 常见问题与排查技巧实录

5.1 插入HDMI后弹窗正常但完全没有声音

这种情况优先怀疑“音量曲线”和“Mixer开关”。先去设置界面调大媒体音量，同时切到HDMI输出通道；再用dumpsys audio看当前实际音量数值是不是为0。

注意：Android 14里TV设备需要在设置里开启“固定音量”，否则HDMI通道可能被CEB（Consumer Electronics Control）相关逻辑静音。

若音量数值正常还是无声，去查HAL层的Mixer状态。大多数情况下，问题出在HDMI声卡的Playback Switch或Audio Select控件没有打开。

5.2 插HDMI后弹窗不出现，也没有媒体声音

弹窗不出现说明设备连接事件可能没传到AudioService，优先排查HDMI Hotplug事件是否真的上报到了框架层。可以在串口终端使用getevent或者在内核日志里查dwc-hdmi相关输出。

如果上层根本没收到事件，那问题在显示驱动和音频驱动的联动逻辑，这部分和具体BSP关系很大，需要结合你们的SDK版本去看hardware/rockchip/audio里有没有监听显示状态变化。

5.3 拔掉HDMI后扬声器声音变很小

这多半是音量曲线联动出了问题：HDMI插入时，系统将音量映射到了HDMI曲线，HDMI曲线和Speaker曲线不一致，拔掉HDMI后没有重新映射回来。可以在AudioService的setWiredDeviceConnectionState里检查音量持久化逻辑，或者在Hal层通过setParameters做音量校准。

5.4 HDMI插上后媒体播放器自动暂停，无法恢复

典型焦点抢占问题。使用dumpsys audio查看当前焦点持有者。如果持有者是AudioService或某个系统组件，说明路由通知或提示音抢占焦点后没有释放。建议直接移除/禁用系统路由提示音，并把媒体应用升级为使用AudioFocusRequest.Builder正确设置setAcceptsDelayedFocusGain和setWillPauseWhenDucked(false)。

5.5 音频输出切换异常频繁

有开发者在调试时发现，插入HDMI后，系统反复弹“音频输出已切换”，状态在两个设备间抖动。这通常不是策略问题，而是HDMI的Hotplug状态不稳定，建议用示波器或串口日志看HPD引脚的电平抖动，如果是硬件问题，软件上再怎么调也是白费。可以先用dumpsys audio确认设备状态是否真在切换。

6. 一些值得记录的实操心得

RK3576这个平台在Android 14下的音频框架改动比较大，修这种“插HDMI没声音”的问题，最忌讳的就是没定位就直接改HAL。我建议的核心排查顺序是：先看AudioService日志确认事件到了没有，再看AudioPolicyManager确认策略选对了没有，最后才轮到HAL层和音量曲线。

日志要抓完整，别只看插入后一段。很多问题的根源在插入前的音频状态上，比如已经处于通话模式，或者焦点被某个后台应用持有，插入事件只是压垮骆驼的最后一根稻草。

另外，Android 14的路由弹窗在TV类设备上确实没什么正面作用，定制系统时可以直接裁剪掉。这部分逻辑在SystemUI的AudioOutputMonitor相关代码里，删掉后不会影响音频路由，只是没有了提示音和UI切换，媒体声音不会被抢焦点，体感会稳定很多。

如果你们产品需要支持HDMI ARC，那就要额外关注音频Hal层对ARC回传格式的处理，不要只看PCM通路。我见过用默认配置跑ARC导致电视端没声音的案例，排查到最后发现是回传的E-AC3格式没拿对，Hal层直接丢弃了。

最后再分享一个小技巧：调试期间不要频繁整机重启，用adb shell stop、adb shell start重启安卓框架会比冷启动快得多，而且很多路由状态是保存在AudioServer进程里的，重启框架就能清掉异常状态，复现和验证的效率都会高很多。