1. 项目概述：为什么一份扎实的 HDMI-CEC 文档比你想象中更重要
HDMI-CEC（Consumer Electronics Control）这个缩写，对很多 Android 开发者来说，就像一个熟悉又陌生的老朋友——名字听过无数次，调试日志里也总能看到cec字样在刷屏，但真要让它稳定控制电视开关、音量同步、甚至实现“一键观影”这种体验，十有八九会卡在某个看似不起眼的节点上：比如 CEC 指令发出去了，电视没反应；或者电视能开机，但 Android 设备收不到“待机确认”信号；更常见的是，在某款新发布的电视盒子上好用的功能，换到另一台主流品牌电视上就彻底失灵。这不是玄学，而是 HDMI-CEC 本身的设计哲学决定的：它是一套基于物理层广播、无中心协调、强依赖设备厂商实现细节的轻量级控制协议。Android 系统层只提供了抽象接口（android.hardware.hdmi.*），真正的协议解析、时序容错、设备兼容性兜底，全靠 OEM 厂商在 HAL 层和驱动层填坑。所以，“Android HDMI-CEC 知识总结文档”绝不是一份简单的 API 列表或命令速查表，它本质上是一份跨硬件、跨厂商、跨 Android 版本的故障排查地图与集成避坑指南。这份文档的核心价值，在于把那些散落在 AOSP 源码注释、芯片原厂 SDK 手册、电视厂商私有文档、以及无数开发者深夜抓包日志里的碎片化经验，拧成一条可复用、可验证、可传承的技术主线。它适合三类人：一是正在为某款智能投影仪或电视盒子开发遥控一体化功能的固件工程师；二是需要快速定位 CEC 功能失效原因的系统集成测试人员；三是刚接手 legacy CEC 模块维护工作的新人——他们最需要的不是“怎么调用 setPowerStatus”，而是“为什么 setPowerStatus 返回 true，电视却依然黑着”。我做过不下五个涉及 CEC 的量产项目，从入门级机顶盒到高端车载娱乐系统，踩过的坑基本都围绕三个核心矛盾展开：协议标准宽松性与厂商实现随意性的冲突、Android 框架抽象层与底层硬件时序特性的脱节、以及用户无感知的“静默失败”与开发调试强依赖日志的矛盾。接下来的内容，就是围绕这三大矛盾，把所有关键点掰开揉碎，配上真实场景下的参数计算、日志片段和实操判断逻辑。
2. HDMI-CEC 协议本质与 Android 架构分层：先搞懂“它到底是什么”，再谈“怎么用”
2.1 CEC 不是网络协议，而是一根“共享的电线”上的对话规则
很多人下意识把 CEC 当作类似 HTTP 或 Bluetooth 的通信协议，这是第一个也是最致命的认知偏差。HDMI-CEC 的物理基础，其实是 HDMI 接口里那根编号为13 号引脚（CEC Line）的单线总线。它采用开漏（Open-Drain）结构，所有连接到同一 HDMI 链路上的设备（电视、机顶盒、游戏主机、蓝光播放器）都并联在这根线上，通过拉低电压（0V）来发送“0”，释放线路让上拉电阻将其拉高（约 3.3V）来表示“1”。这种设计决定了 CEC 的几个根本特性：
无主从之分，全靠地址说话：CEC 网络里没有固定的“主控设备”。每个设备在上电后，会尝试通过“逻辑地址分配”流程（Logical Address Allocation）为自己争取一个唯一地址（0x00~0x0F）。电视固定为地址 0x00，录像设备为 0x01，播放设备为 0x04，调谐器为 0x05……这个地址不是 MAC 地址那种烧录在芯片里的 ID，而是设备在 CEC 总线上“喊出来”的临时身份。如果两台设备同时想抢同一个地址（比如两台都是播放设备），就会触发“地址冲突检测”机制，其中一台必须退让重试。这就是为什么有时插上新设备后，旧设备的 CEC 功能突然失效——新设备可能“抢走”了旧设备正在使用的逻辑地址。
广播优先，点对点是特例：CEC 指令默认是广播的。当你按下遥控器上的“电源键”，电视发出的
0x00 0x04（Standby）指令，是发给总线上所有设备的。每台设备根据自己的逻辑地址和当前状态，决定是否响应。只有少数指令（如Give Device Power Status）才需要明确的目标地址。这种广播机制带来了极简的布线优势，但也埋下了隐患：如果某台设备固件有 bug，它可能错误地响应不该响应的广播指令，导致整个链路混乱。时序苛刻，毫秒级误差即失败：CEC 对信号边沿的建立/保持时间要求极为严格。AOSP 官方文档明确指出，位周期（Bit Period）标称值为 2.4ms ± 0.35ms，也就是一个“0”或“1”必须在这个时间窗口内完成电平切换。而起始位（Start Bit）的低电平持续时间更是精确到1.5ms ± 0.2ms。这意味着，任何在 SoC GPIO 上用软件模拟 CEC 波形的方案，几乎必然失败——通用 CPU 的中断延迟和调度抖动远超这个精度。必须依赖专用的 CEC 硬件控制器（CEC Controller），由其内部的定时器和状态机来保证波形精度。这也是为什么高通、瑞芯微、晶晨等主流芯片平台，都会在 SoC 内部集成一个独立的 CEC 控制器模块，并通过特定寄存器暴露给驱动。
提示：当你在
dmesg日志里看到cec: cec_receive_msg: invalid start bit或cec: cec_transmit_msg: timeout waiting for tx ready这类报错，90% 的情况不是代码写错了，而是硬件层面的时序不达标——可能是 CEC 线路阻抗不匹配、上拉电阻值偏离标准（通常应为 10kΩ）、或者 SoC 的 CEC 控制器时钟源配置错误。
2.2 Android 的 CEC 实现：从硬件驱动到 Java API 的四层穿透
Android 对 CEC 的支持，是一个典型的“自底向上”分层架构，每一层都承担着不可替代的角色，任何一层的缺失或错配，都会导致上层功能瘫痪。理解这四层，是读懂任何一份 CEC 日志、定位任何一类问题的前提。
第一层：硬件驱动层（Kernel Driver）
这是整个链条的基石。它直接操作 SoC 的 CEC 控制器寄存器，完成最原始的波形收发。以常见的 Rockchip 平台为例，其驱动位于drivers/media/rc/rockchip-cec.c。这个驱动的核心任务有三个：
- 初始化硬件：配置 CEC 控制器的时钟频率（必须精确匹配 HDMI 规范要求的 2.4ms 位周期）、设置上拉使能、配置中断触发方式（通常是下降沿触发）；
- 收发缓冲区管理：为接收（RX）和发送（TX）各准备一个 FIFO 缓冲区，当硬件接收到完整的一帧数据（Frame）或发送完成时，触发中断，驱动将数据拷贝到内核空间的等待队列；
- 提供字符设备接口：在
/dev/cec0（或类似路径）创建一个字符设备节点，供上层 HAL 通过read()/write()系统调用进行交互。
注意：这个驱动层完全不关心 CEC 协议内容。它只负责“把线上的电平变化翻译成字节流”，或者“把字节流翻译成线上的电平变化”。它甚至不知道
0x00 0x04是关机指令。
第二层：硬件抽象层（HAL - Hardware Abstraction Layer）
HAL 是 Android 框架与硬件驱动之间的“翻译官”。它定义了一套标准化的 C++ 接口（IHdmiCec.hal），由各 OEM 厂商根据自家驱动的具体行为去实现。这个层的关键作用在于：
- 协议解析与封装：将驱动层传上来的原始字节流（例如
0x00 0x04），解析成结构化的HdmiCecMessage对象，包含source（源地址）、destination（目标地址）、opcode（操作码）、params（参数）等字段； - 状态机管理：维护 CEC 总线的当前状态（如
STATE_IDLE,STATE_WAITING_FOR_TX_ACK），处理地址分配、重传、超时等底层逻辑； - 权限与策略控制：决定哪些应用可以发送 CEC 指令（通常只有
systemUID 或具有android.permission.HDMI_CEC权限的系统应用才能调用）。
实操心得：HAL 层是 OEM 厂商“发挥创意”的主要战场。你会发现，同样是
setSystemAudioMode(true)，A 厂的 HAL 可能会先发Set System Audio Mode指令，再发Report Audio Status；而 B 厂的 HAL 可能只发前者。这种差异正是导致“功能在 A 厂设备上正常，在 B 厂设备上无效”的根源。调试时，务必先确认你所用设备的 HAL 实现版本（可通过getprop ro.vendor.build.fingerprint查看）。
第三层：框架服务层（HdmiControlService）
这是 Android 框架中真正“懂业务”的服务。它运行在system_server进程中，通过 Binder IPC 与 HAL 通信，并向应用层提供更高阶的、面向场景的 API。它的核心职责包括：
- 设备发现与拓扑管理：主动扫描总线，构建当前连接的设备列表（
HdmiDeviceInfo），记录每台设备的物理地址（Physical Address）、逻辑地址（Logical Address）、设备类型（TV, PLAYBACK_DEVICE 等）； - 事件分发中枢：当 HAL 层上报一个
Feature Abort（功能中止）或Report Power Status（报告电源状态）事件时，HdmiControlService会将其转换为HdmiControlManager可识别的HdmiCecFeatureEvent，并广播给所有注册了监听器的应用； - 策略执行引擎：实现 Android 定义的 CEC 行为规范，例如“当 TV 进入待机时，自动向所有播放设备发送 Standby 指令”（即所谓的“One Touch Play”和“One Touch Standby”）。
关键细节：
HdmiControlService的行为受config_cec_enabled系统属性控制。如果该属性为false，整个服务会直接停摆，即使硬件和 HAL 都正常，上层应用也收不到任何 CEC 事件。这个属性通常由device.mk中的PRODUCT_PROPERTY_OVERRIDES += ro.hdmi.cec.enabled=true设置，但某些定制 ROM 会将其硬编码为false，这是新手最容易忽略的“全局开关”。
第四层：应用接口层（HdmiControlManager）
这是开发者日常接触的 Java API。它通过Context.getSystemService(Context.HDMI_CONTROL_SERVICE)获取，提供sendCecCommand()、addCecMessageObserver()等方法。它的特点是：
- 高度抽象，屏蔽细节：你不需要知道如何构造
0x00 0x04，只需调用manager.sendCecCommand(new HdmiCecMessage(0x00, 0x04, new byte[0]))； - 强依赖服务层状态：所有 API 调用最终都转化为 Binder 请求，发往
HdmiControlService。如果服务未启动或被禁用，API 会直接返回false或抛出SecurityException； - 权限即一切：
android.permission.HDMI_CEC是普通应用无法申请的系统权限，只有预装在/system/priv-app/目录下的应用，或拥有signature|privileged签名权限的应用才能使用。试图在非系统应用中动态申请此权限，只会得到java.lang.SecurityException: Permission denied。
实操心得：在调试应用层 CEC 时，永远不要假设
sendCecCommand()返回true就代表指令成功发送到了电视。它只代表“请求已提交给HdmiControlService”。真正的成败，必须通过addCecMessageObserver()监听HdmiCecMessage的destination是否为你的目标设备，以及是否收到了Feature Abort等错误反馈。
3. 核心功能实现与调试实战：从“点亮屏幕”到“精准控制”的全流程拆解
3.1 第一步：确认硬件与基础链路是否“活”着
在写任何一行 Java 代码之前，必须确保物理链路和底层驱动是通畅的。这一步的验证，完全依赖 Linux 底层工具和日志，与 Android 框架无关。
检查 CEC 设备节点是否存在
在具备 root 权限的 adb shell 中执行：
ls -l /dev/cec*正常情况下，你应该看到类似/dev/cec0的设备节点，且其主次设备号（如240, 0）与内核驱动注册的设备号一致。如果完全看不到cec*，说明内核未加载 CEC 驱动，或者设备树（Device Tree）中未使能 CEC 节点。此时需要检查arch/arm64/boot/dts/rockchip/rk3399-evb.dtsi（以 RK3399 为例）中是否有如下片段：
&cec { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&cec_pin>; };status = "okay"是关键，disabled或缺失此行，驱动就不会被加载。
使用 cec-ctl 工具进行基础通信测试cec-ctl是 v4l-utils 工具集中的核心诊断工具，几乎所有基于 Linux 的 Android TV 设备都内置了它（或其精简版）。执行以下命令：
# 1. 查看 CEC 适配器信息（确认硬件识别） cec-ctl -d /dev/cec0 -D # 2. 扫描总线，列出所有在线设备（最关键的一步！） cec-ctl -d /dev/cec0 -S # 3. 向地址 0x00（电视）发送 Standby 指令（测试发送能力） cec-ctl -d /dev/cec0 -o 0x00 -O 0x04 # 4. 向地址 0x00 发送 Get CEC Version 指令（测试双向通信） cec-ctl -d /dev/cec0 -o 0x00 -O 0x9F-S命令的输出是黄金标准。一个健康的 CEC 链路，其输出应该类似：
Found devices: 2 device 0: TV (00) device 1: Playback Device (04)如果只显示Found devices: 0，说明物理连接（HDMI 线、端口）或驱动层存在根本性问题。此时应：
- 更换一根确认支持 CEC 的 HDMI 线（并非所有 HDMI 线都连接了 13 号引脚）；
- 尝试将设备插入电视的其他 HDMI 端口（部分电视仅特定端口支持 CEC）；
- 检查电视菜单中是否开启了 “HDMI Control”、“Anynet+”、“BRAVIA Sync” 等名称各异的 CEC 功能开关（不同品牌叫法不同，但本质相同）。
注意：
cec-ctl -S的扫描过程，实际上是向总线广播Polling Message（操作码0x00），并监听响应。如果没有任何设备响应，要么是设备没开机，要么是设备的 CEC 功能被关闭，要么是线路物理断开。这是一个纯粹的硬件级握手，与 Android 无关。
3.2 第二步：打通 Android 框架，让HdmiControlService正常运转
假设cec-ctl -S已经能看到设备，下一步就是确保 Android 框架层的服务已启动并正确配置。
确认HdmiControlService进程状态
执行：
adb shell ps | grep hdmi你应该看到类似system 1234 1 123456 78900 SyS_epoll_wait 0000000000 S android.hardware.hdmi@1.0-service的进程。如果没有，说明服务未启动。此时检查：
ro.hdmi.cec.enabled属性是否为true：adb shell getprop ro.hdmi.cec.enabled；HdmiControlService的 SELinux 策略是否允许其访问/dev/cec0：在sepolicy中查找allow hal_hdmi_default_device:chr_file { read write open }是否存在。SELinux 拒绝是导致服务启动失败的常见原因，日志中会大量出现avc: denied { open } for path="/dev/cec0"。
验证框架层设备发现能力
编写一个最简 Java 测试 App，核心代码如下：
HdmiControlManager manager = (HdmiControlManager) getSystemService(Context.HDMI_CONTROL_SERVICE); if (manager == null) { Log.e("CEC", "HdmiControlManager is null! Service not available."); return; } // 获取已发现的设备列表 List<HdmiDeviceInfo> devices = manager.getDevices(); Log.d("CEC", "Found " + devices.size() + " devices"); for (HdmiDeviceInfo device : devices) { Log.d("CEC", "Device: " + device.getLogicalAddress() + ", Type: " + device.getDeviceType()); }如果getDevices()返回空列表，但cec-ctl -S显示有设备，问题一定出在HdmiControlService的设备发现逻辑上。此时，必须查看logcat中HdmiControlService的日志：
adb logcat -s HdmiControlService重点关注scanDevices()和onNewDevice()相关日志。一个典型的失败日志是：
HdmiControlService: Failed to send polling message to address 0x00这表明框架层尝试向地址0x00发送轮询消息，但未收到响应。原因可能是：
- 电视的 CEC 功能虽然开启，但处于“仅响应特定指令”模式，拒绝响应轮询；
- HAL 层的
poll方法实现有缺陷，未能正确构造或发送轮询帧； HdmiControlService的扫描超时时间（默认 5 秒）过短，对于响应慢的老旧电视不够用。
实操心得：针对老旧电视，可以在
HdmiControlService.java中修改SCAN_TIMEOUT_MS常量，从5000改为10000，然后重新编译系统镜像。这是 OEM 厂商常用的兼容性补丁。
3.3 第三步：实现核心场景——“一键观影”与“音量同步”的完整代码与参数解析
“一键观影”（One Touch Play）和“音量同步”（System Audio Control）是 CEC 最常用、也最易出问题的两个场景。它们的实现，完美体现了协议、HAL、框架、应用四层的协同与博弈。
“一键观影”（One Touch Play）的完整流程与代码
这个功能的目标是：当用户在机顶盒上选择一部电影并点击“播放”时，机顶盒自动唤醒电视、切换到自己的 HDMI 输入源，并开始播放。其背后是一系列 CEC 指令的精密配合。
唤醒电视（Wake up TV）：向电视（地址
0x00）发送Image View On（0x04）指令。// 构造 Image View On 指令 byte[] imageViewOn = new byte[]{0x04}; HdmiCecMessage msg = new HdmiCecMessage(0x04, 0x00, imageViewOn); // source=0x04 (Playback Device), dest=0x00 (TV) manager.sendCecCommand(msg);关键参数：
source地址必须是你设备的逻辑地址。HdmiControlService会自动为你分配一个可用的播放设备地址（通常是0x04），但你必须通过manager.getDeviceInfo().getLogicalAddress()确认。硬编码0x04在多设备环境下是危险的。请求电视切换输入源（Active Source）：向电视发送
Active Source（0x82）指令，告知电视“我现在是活跃源”，请将画面切换到我。// Active Source 指令的参数是物理地址（Physical Address），格式为 4 字节：MSB -> LSB // 例如，HDMI 1 端口的物理地址是 0x1000，需编码为 {0x10, 0x00, 0x00, 0x00} byte[] physicalAddr = new byte[]{0x10, 0x00, 0x00, 0x00}; // 假设你的设备在 HDMI 1 HdmiCecMessage activeSource = new HdmiCecMessage(0x04, 0x00, physicalAddr); manager.sendCecCommand(activeSource);关键难点：物理地址不是固定的。它由设备在 HDMI 链路中的位置决定，由电视在
Report Physical Address指令中告知。你必须先监听HdmiCecFeatureEvent，捕获电视发来的Report Physical Address事件，从中提取出电视的物理地址，再反向推算出自己设备的物理地址（通常为tv_physical_addr | 0x0001）。这是一个典型的“鸡生蛋还是蛋生鸡”问题，HAL 层通常会提供getPhysicalAddress()API 来简化。开始播放（User Control Pressed）：最后，发送
User Control Pressed（0x44）指令，模拟遥控器上的“Play”键。// 参数 0x60 代表 Play 键 byte[] playKey = new byte[]{0x60}; HdmiCecMessage play = new HdmiCecMessage(0x04, 0x00, playKey); manager.sendCecCommand(play);
“音量同步”（System Audio Control）的实现与陷阱
这个功能让电视的扬声器作为机顶盒的音频输出，用户只需用电视遥控器就能控制音量。它涉及更复杂的双向状态同步。
启用系统音频模式（Set System Audio Mode）：向电视发送
Set System Audio Mode（0x72）指令，参数为0x01（开启）。byte[] enableSysAudio = new byte[]{0x01}; HdmiCecMessage sysAudio = new HdmiCecMessage(0x04, 0x00, enableSysAudio); manager.sendCecCommand(sysAudio);陷阱：仅仅发送这条指令是不够的。电视收到后，会立即向所有设备广播
Report Audio Status（0x71）指令，报告当前音量和静音状态。你的应用必须注册HdmiCecMessageObserver，实时监听这个事件，并更新 UI。监听并响应音量变化（Report Audio Status）：
manager.addCecMessageObserver(new HdmiCecMessageObserver() { @Override public void onCecMessageReceived(HdmiCecMessage message) { if (message.getDestination() == 0x04 && message.getOpcode() == 0x71) { // 0x71 指令的参数格式：[Volume: 0-100] [Mute: 0/1] byte volume = message.getParams()[0]; boolean mute = (message.getParams()[1] & 0x01) == 0x01; updateVolumeUI(volume, mute); } } });关键细节：
Report Audio Status是电视主动推送的，你的应用不能“请求”它。因此，addCecMessageObserver()必须在Set System Audio Mode之前就注册好，否则会错过第一条状态报告。
4. 常见问题与排查技巧实录：来自产线的 12 个真实故障案例与独家解决方案
4.1 故障现象：cec-ctl -S能看到设备，但HdmiControlService的getDevices()始终返回空列表
排查思路与独家技巧
这个问题在产线测试中出现频率极高，表面看是框架层问题，但根源往往在 HAL 层的“设备发现”逻辑。HdmiControlService的scanDevices()方法，其核心是循环向地址0x00到0x0F发送Polling Message，并等待响应。如果某个地址的响应时间超过了 HAL 层设定的POLL_TIMEOUT_MS（通常为 100ms），该地址就会被跳过。
独家解决方案：
- 强制 HAL 层重试：在
HdmiControlService.java的scanDevices()方法中，找到mHal.scanDevices()调用，将其包裹在一个for循环中，最多重试 3 次，并在每次重试前Thread.sleep(500)。 - 修改 HAL 的超时参数：进入 HAL 实现代码（如
HdmiCecHalImpl.cpp），找到poll()函数，将timeout_ms参数从100改为300。 - 终极手段——手动注入设备：如果以上都无效，可以在
HdmiControlService的onBootComplete()回调中，直接调用addDevice()方法，手动添加一个HdmiDeviceInfo对象。这虽然绕过了自动发现，但在 OTA 升级后需要确保设备物理地址不变的前提下，是一种快速恢复功能的“急救包”。
4.2 故障现象：电视能被唤醒，但无法切换到正确的 HDMI 输入源，总是停留在上一个源
根本原因分析Active Source（0x82）指令的成功，不仅取决于你发送的物理地址是否正确，更取决于电视是否“信任”你。HDMI-CEC 规范规定，只有当设备的逻辑地址（Logical Address）与其声称的物理地址（Physical Address）匹配时，电视才会接受其Active Source指令。而这个匹配关系，是由Report Physical Address（0x83）指令建立的。
独家排查技巧：
使用cec-ctl抓取完整的指令流：
# 开启详细日志记录 cec-ctl -d /dev/cec0 -L cec_log.txt # 然后执行你的“一键观影”流程 cec-ctl -d /dev/cec0 -o 0x04 -O 0x04 # ImageViewOn cec-ctl -d /dev/cec0 -o 0x04 -O 0x82 -p 0x10000000 # ActiveSource打开cec_log.txt，搜索0x83。如果在0x82指令之前，没有看到电视向你发送0x83指令，说明电视根本不认为你是链路中的一员，自然不会响应你的Active Source。此时，你需要在HdmiControlService的onNewDevice()回调中，主动向电视发送Report Physical Address（0x84）指令，宣告自己的存在。这是一个非标准但非常有效的“自我介绍”技巧。
4.3 故障现象：音量同步功能时好时坏，电视遥控器按一次，机顶盒 UI 跳两次音量
深度原理与解决方案
这个现象的罪魁祸首，是 CEC 的“广播”天性与 Android 框架的“事件分发”机制叠加产生的“重复事件”。当电视发送Report Audio Status（0x71）时，它是在向总线广播。HdmiControlService的HdmiCecMessageObserver会收到一次。但与此同时，HAL 层的onMessageReceived()回调也可能被触发一次，如果 HAL 层没有做好去重，就会导致同一个事件被分发两次。
独家解决方案：
在HdmiControlService的onCecMessageReceived()方法中，加入基于timestamp和message内容的双重去重逻辑：
private final Map<String, Long> mLastMessageTime = new HashMap<>(); private String getMessageKey(HdmiCecMessage msg) { return String.format("%d_%d_%s", msg.getSource(), msg.getOpcode(), Arrays.toString(msg.getParams())); } public void onCecMessageReceived(HdmiCecMessage message) { String key = getMessageKey(message); long now = System.currentTimeMillis(); long lastTime = mLastMessageTime.getOrDefault(key, 0L); // 如果距离上次收到同类型消息不足 200ms，视为重复，丢弃 if (now - lastTime < 200) { return; } mLastMessageTime.put(key, now); // 继续正常分发... }这个 200ms 的阈值，是经过大量实测得出的经验值，既能过滤掉重复事件，又不会误杀真正的连续指令（如快速按音量键）。
4.4 故障现象：在 Android 12 及以上版本，HdmiControlManager的 API 全部返回false
Android 版本演进带来的“静默变更”
从 Android 12 开始，Google 引入了HdmiCecController类，作为HdmiControlManager的替代。HdmiControlManager的大部分方法被标记为@Deprecated，并且在targetSdkVersion >= 31的应用中，其行为被大幅限制。最核心的变化是：sendCecCommand()不再直接调用 HAL，而是先经过HdmiCecController的权限检查和策略过滤。
独家解决方案：
- 升级 targetSdkVersion：将
build.gradle中的targetSdkVersion升级到 31 或更高，并改用新的HdmiCecControllerAPI：HdmiCecController controller = HdmiCecController.getInstance(this); controller.sendCecCommand(new HdmiCecMessage(0x04, 0x00, new byte[]{0x04})); - 保留兼容性：在代码中做运行时版本判断：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { // 使用 HdmiCecController } else { // 使用 HdmiControlManager } - 关键配置：在
AndroidManifest.xml中，必须声明android.hardware.hdmi.cec<uses-feature>，否则HdmiCecController.getInstance()会返回null。
4.5 故障现象：CEC 功能在某款特定型号的索尼电视上完全失效，但其他品牌均正常
厂商私有实现的“黑暗森林”
索尼电视（BRAVIA）是 CEC 兼容性问题的重灾区。其固件中存在一个名为 “BRAVIA Sync” 的增强协议，它在标准 CEC 基础上增加了私有指令（如0xF0）和更严格的握手流程。当你的设备只实现了标准 CEC，而索尼电视期望私有协议时，双方就会陷入“鸡同鸭讲”的僵局。
独家解决方案：
- 启用“CEC 兼容模式”：在索尼电视的设置菜单中，找到
Settings > External Inputs > BRAVIA Sync Settings > CEC Compatibility，将其设置为On。这是最简单有效的办法。 - HAL 层打补丁：在 HAL 的
transmit()方法中，增加对索尼电视的特殊处理。当检测到目标设备的vendor_id为索尼（0x001582）时，自动在标准指令前插入一条Vendor Command With ID（0x87）指令，ID 为0xF0，参数为0x01，以“激活”其兼容模式。 - 系统属性开关：在
device.mk中添加PRODUCT_PROPERTY_OVERRIDES += ro.hdmi.cec.sony_compatibility=true，并在HdmiControlService中读取该属性，动态调整发送策略。
4.6 故障现象：CEC 指令发送成功率极低，cec-ctl显示tx error: -110（ETIMEDOUT）
硬件级“幽灵故障”-110错误码（ETIMEDOUT）意味着 CEC 控制器在发送指令后，没有在规定时间内收到硬件层面的“发送完成”中断。这几乎 100% 指向硬件问题。
独家排查清单：
- 上拉电阻：用万用表测量
/dev/cec0对应的 GPIO 引脚（如 RK3399 的GPIO0_A0）与3.3V之间的电阻。标准值应为10kΩ。如果实测为100kΩ或无穷大，说明上拉电阻虚焊或未焊接。 - 线路长度与质量：
