我和 AI 一起修電視索尼 CEC 失效排查實錄TL;DR電視的 HDMI-CEC 全鏈路癱瘓根因是某根 HDMI 線把 CEC 總線13 腳拉死導致電視開機時 CEC 初始化失敗。而mIsCecAvailable這個標志一旦為 false 就不會自愈所以后續(xù)怎么重啟、怎么改設置都沒用。修復動作只有一個組合拔光所有 HDMI 線 → 重啟電視不是待機→ 插回設備。順序不能反。這篇文章除了講技術還想講清楚一件事這整個過程是我和一個 AI 智能體一來一回干完的。它負責敲命令、讀 dumpsys、分析日志我負責拔線、看畫面、以及在關鍵時刻糾正它的誤判。〇、開場我把 adb 交給了 AI事情很簡單家里的 SONY XR-65X91J 接 Apple TV 4K以前電視遙控器切到 HDMI3Apple TV 自動亮遙控器還能直接控制它。某天開始這套流程全廢了切到 HDMI3Apple TV 沒反應屏幕黑著電視遙控器按下去Apple TV 毫無響應得先摸出 Siri Remote 按一下Apple TV 才醒按以前的習慣這種問題我會自己開終端一條條adb shell試。但那天太晚了我換了種干法——直接把電視的 adb 連接交給 WorkBuddy 里的智能體小智讓它自己查。我的開場白只有一句我我的電視的 HDMI3 連接的是 Apple TV分析一下為什么我將信號源切換到 HDMI3 的時候沒有喚醒 Apple TV。它回得也很干脆小智我先連電視把 HDMI-CEC 的實際配置和切換 HDMI3 時的日志抓出來再下結論。然后它就開始自己跑命令了。下面整個過程都是真實發(fā)生的交互。一、第一回合AI 交上來的體檢報告它做的第一件事不是猜是分層取證——先查 settings 三層再查服務再查 dumpsys 狀態(tài)機最后翻 logcat。幾分鐘后它給出的核心結論只有一行mIsCecAvailable: false再往下是設備表mDeviceInfos: CEC: logical_address: 0x00 device_type: 0 ... display_name: TV只有電視自己地址 0x00一個下游設備都沒有。以及報文歷史CEC message history: [S] time2026-06-05 18:35:46 messageReport Physical Address 0F:84:00:00:00 [S] time2026-06-05 18:35:48 messageDevice Vendor Id 0F:87:08:00:46 [S] time2026-06-05 18:35:54 messageActive Source 0F:82:00:00 ...12 條記錄全是[S]Send一條[R]Receive都沒有。它給我的解釋是小智CEC 是雙向總線協(xié)議。一條[R]都沒有意味著這塊電視從來沒有成功接收過任何 CEC 報文。這不是Apple TV 沒開某個開關能解釋的。同時它發(fā)現(xiàn) HAL 層在刷屏E/CEC_HAL: Tx notify NOT coming, Timeout return W/HdmiCecController: Failed to send Active Source 0F:82:00:00 with errorCode2到這里它給了一個初步判斷而且是錯的小智從首次開機起每條發(fā)送就都是errorCode2……這臺電視的 CEC 可能一直就沒工作過只是你之前沒用過這個功能。二、第二回合我的一句話把方向掰回來了它問了我一個關鍵問題小智順便問一句你用 Apple TV 遙控器能開關電視或者調(diào)電視音量嗎如果完全沒反應基本就坐實是 CEC 整條鏈路的問題。我的回答同時也否掉了它前面的推測我能以前用電視遙控器切換到 HDMI3會喚醒 Apple TV然后用電視遙控器也能夠控制 Apple TV現(xiàn)在不行了。它立刻改了判斷小智這條信息很關鍵。既然以前能用那說明這不是出廠即壞我收回一直沒工作的判斷。CEC 硬件是好的現(xiàn)在處于卡死狀態(tài)。這是整個排查的轉折點。如果它繼續(xù)沿著硬件從來沒工作過推下去結論會變成主板故障送修而曾經(jīng)好過、現(xiàn)在壞了這個前提把方向引向了后來發(fā)生了什么變化——這才有了后面的隔離實驗。我后來復盤時覺得這是人機協(xié)作里最值錢的部分AI 能看到我看不到的數(shù)據(jù)但它不知道我的生活史。有些信息只存在于人腦里必須由人補給它。三、第三回合AI 自己設計并執(zhí)行了五次搶救確認是后天失效之后它沒有停在分析上而是自己列了一串恢復手段一條條試#手段命令結果1CEC 開關重置cmd hdmi_control cec_setting set hdmi_cec_enabled 0→1? 無效2ARC 通道重置cmd hdmi_control setarc off→on? 無效3重啟 CEC HAL 進程kill -9 pid?Operation not permitted無 root4端口抖動檢測10 秒 × 5 次采樣? 四口狀態(tài)恒定非接觸不良5整機重啟adb reboot? 無效其中第 1 條實驗是它自己想到的而且做得非常聰明23:52:19 setCecSettingIntValue hdmi_cec_enabled 0 ← CEC 已關閉 23:52:20 E/CEC_HAL: Tx notify NOT coming, Timeout ← 照樣超時 23:52:22 E/CEC_HAL: Tx notify NOT coming, Timeout ← 照樣超時 23:52:24 setCecSettingIntValue hdmi_cec_enabled 1 ← 再打開 23:52:26 E/CEC_HAL: Tx notify NOT coming, Timeout ← 還是超時它的解讀是小智CEC 在軟件層都關掉了驅(qū)動層還在每 2 秒報一次發(fā)送超時。這一條就夠了——問題與 Android 的 CEC 狀態(tài)機無關與 BRAVIA Sync 的設置無關是驅(qū)動/物理層的持續(xù)故障。這是全篇最有說服力的一段證據(jù)。我自己想不到這么試一般人的思路是打開看看而它是關掉看看——如果關了還在報錯說明報錯的根本不是這一層。四、第四回合它給不了手于是給我造了把工具到這一步它已經(jīng)很明確了問題在物理層而物理層它碰不到。小智軟件層能試的全試完了四條路全堵死。剩下的必須動手了。我做了個實時監(jiān)控讓你拔線的瞬間就能看到結果。然后它寫了兩個腳本扔進項目目錄./cec_live.sh# 實時監(jiān)控每 2 秒一行./cec_probe.sh10# 單次采樣輸出完整體檢報告cec_live.sh的輸出長這樣23:58:19 -- [重連中] 23:58:22 1 [總線異常] 23:58:24 1 [總線異常]它的原理很簡單——把Tx notify NOT coming的出現(xiàn)頻率當成 CEC 總線的健康度指標。正常應該是0 次每當 2 秒出現(xiàn) 1 次就說明有東西在拉著總線。這個設計讓我不用反復跑命令、翻日志只要看著屏幕拔線就行。這是我覺得 AI 在這類任務里最實用的能力它能把你去做物理動作我盯著數(shù)據(jù)這種配合變成現(xiàn)實。五、第五回合我拔線它看數(shù)據(jù)我按它說的把四根 HDMI 線全拔了然后截了張監(jiān)控圖發(fā)過去。00:01:02 [總線異常] ... 00:02:12 [總線異常] 00:02:14 [總線正常] ← 從這里開始一次超時都沒有了 ... 00:03:01 [總線正常]它的反應小智這個結果很關鍵四根線全拔掉后 TX 超時在同一瞬歸零了。說明電視的 CEC 控制器本身沒壞問題出在外部。它還注意到一個我沒在意的細節(jié)小智注意那個70 秒的延遲——拔線之后不是立刻恢復而是過了一分多鐘才徹底安靜。說明 CEC 控制器需要重新檢測 HPD 狀態(tài)、重新初始化才能脫離異常態(tài)。這句話后來成了修復方案的關鍵。六、第六回合為什么之前那次重啟沒用在等我的過程中它自己去重啟了一次電視adb reboot然后查狀態(tài)——還是壞的。它當時的解釋小智mIsCecAvailable是開機時一次性判定的一旦變成 false 就不會自愈只有重啟才能重新初始化。之前那次重啟時線還插著、總線還是壞的所以重啟后照樣失敗。必須先拔線、再重啟順序反了就是白折騰。這個因果鏈一說通整件事就閉環(huán)了某根線把 CEC 總線拉死 ↓ 電視開機時 CEC 初始化失敗 → mIsCecAvailable false ↓ 這個標志不會自愈只有重啟有機會翻盤 ↓ 重啟的那一刻如果總線還是壞的 → 依然失敗 ↓ 所以必須先拔線制造干凈環(huán)境再重啟它甚至主動承認了這個順序問題小智這也是我一開始沒讓你先拔線就重啟的原因——當時我還沒排除是電視本身壞了。七、第七回合驗證四根線全拔 重啟之后我按它的要求只插回 Apple TV 那一根。它一查電視立刻識別到了mDeviceInfos: CEC: logical_address: 0x04 device_type: 4 cec_version: 5 vendor_id: 4346 display_name: Apple TV physical_address: 0x3000 port_id: 3logical_address 0x04→ Playback Device 1vendor_id 43460x10FA→ Apple Inc.physical_address 0x3000→ HDMI3它自己的評價是小智vendor_id 4346、physical_address 0x3000、device_type 4——它是一個完整、合法的 CEC 設備被電視正常納管了。然后它直接發(fā)了個 intent 切到 HDMI3抓下了修復后的完整握手00:08:55 [S] Give Device Power Status 04:8F ← 問 Apple TV 狀態(tài) 00:08:55 [R] Report Power Status 40:90:00 ← 答我開著 00:08:56 [S] Set Stream Path 0F:86:30:00 ← ★ 關鍵報文之前根本發(fā)不出去 00:08:56 [R] Image View On 40:04 ← Apple TV收到醒了 00:08:56 [R] Active Source 4F:82:30:00 ← Apple TV我接管畫面 mActiveSource: (0x04, 0x3000) ← Apple TV 是當前活躍源 mActiveRoutingPath: 0x3000 ← 路由鎖定 HDMI3一步不缺教科書級的 One Touch Play。八、被忽略的技術細節(jié)Routing Change和Set Stream Path不是一回事報告里有一段我覺得最值得單獨拎出來的分析——為什么設備表為空的時候切信號源更不容易喚醒設備。它抓到了故障期間切 HDMI3 的軌跡23:43:52.995 TIS_HdmiControlHelper: portSelect() id: 3 23:43:53.006 HdmiControlService: portSelect: portId: 3 23:43:54.001 addAndStartAction RoutingControlAction 23:43:54 [S]: Routing Change 0F:80:00:00:30:00 ← 只發(fā)了這一條 23:43:56.003 removeAction: RoutingControlAction ← 2 秒后放棄兩條報文的區(qū)別是致命的報文Opcode語義能喚醒設備嗎Routing Change0x80“我的路由要變了通知你們一聲”? 只是告知Set Stream Path0x86“我要顯示 3.0.0.0 的畫面”? One Touch Play 的觸發(fā)點原因在HdmiControlService的邏輯目標地址上的設備已知就發(fā)Set Stream Path精準投遞未知就只能廣播Routing Change讓設備自己宣告。而故障期間設備表本來就是空的。所以形成了雙重故障CEC 物理層發(fā)不出報文即使發(fā)得出發(fā)的也是通知而不是喚醒指令這一點在中文資料里幾乎查不到是它逐行對比修復前后的日志才發(fā)現(xiàn)的。九、復盤人機怎么分工才高效這件事做完我認真想了想這種協(xié)作的邊界在哪。AI 做得好、人做不了的部分能力具體表現(xiàn)批量取證十幾分鐘內(nèi)跑了上百條 adb 命令翻了 setting/secure/global 三層、包列表、dumpsys、logcat 全量交叉驗證從設備表為空和零條[R]兩個獨立證據(jù)推出同一個結論反向?qū)嶒炘O計主動把 CEC 關掉用關了還報錯來證明問題不在這一層自己造工具發(fā)現(xiàn)需要人配合做物理動作當場寫了監(jiān)控腳本不漏細節(jié)從一堆日志里挑出 70 秒延遲、errorCode2、mConfigs變空這些線索不嫌煩凌晨一點反復采樣、反復對比沒有差不多就這樣吧只有人能做的部分能力為什么 AI 不行拔線 / 插線物理世界沒有 API補充生活史以前能用這句話決定了整個排查方向AI 無從得知質(zhì)疑結論它說可能一直沒工作過我一句以前能用就把它掰回來了看畫面“切過去了但黑屏和切過去了有畫面”只能人眼判斷量電壓萬用表是它碰不到的東西AI 在這件事里犯的兩個錯寫出來才有參考價值過早下結論看到首次開機就失敗就推斷從沒工作過。它缺的是時間維度的信息用戶的使用史這個必須人補。順序搞錯先提議重啟、后提出拔線。雖然它后來自己糾正了“必須先拔線再重啟”但這個順序問題導致了中間一次無效嘗試白等了 45 秒。規(guī)律是AI 在信息完備的確定性推理上極強在信息缺失時該不該下結論上容易冒進。十、技術總結三條能省下幾小時的經(jīng)驗1.mIsCecAvailable不會自愈這個字段在HdmiControlService初始化時一次性判定一旦為 false后續(xù)無論開關 CEC、改設置、切輸入都不會翻回來。唯一出路是重新初始化也就是重啟?？吹絤IsCecAvailable: false別浪費時間調(diào)設置。2. 必須先拔線再重啟順序反了等于白做。開著機的設備狀態(tài)是壞的快照重啟會把這個快照固化下來。推廣一下任何開機自檢 狀態(tài)鎖死型故障都要先制造干凈環(huán)境再重啟。3.cable_connection_status字段不可信排查中一度被它誤導明明線拔了還是顯示cable_connection_status1已連接。可靠的判斷依據(jù)是mConfigs數(shù)組mConfigs: [] ← 沒信號 mConfigs: [TvStreamConfig {mStreamId0;...}] ← 有信號前者是緩存值只在特定事件刷新后者反映真實的流配置狀態(tài)。十一、附排查命令速查# 1. CEC 總體狀態(tài)先看這個adb shell dumpsys hdmi_control|head-5# 2. CEC 設備表有沒有識別到下游設備adb shell dumpsys hdmi_control|sed-n/mDeviceInfos:/,/mCecController/p# 3. 報文歷史[S] 發(fā)送 / [R] 接收重點看有沒有 [R]adb shell dumpsys hdmi_control|sed-n/CEC message history/,/mCec/p# 4. 發(fā)送失敗日志adb shell logcat-d|grepFailed to send# 5. 物理層超時CEC 總線健康度核心指標adb shell logcat-d|grep-cTx notify NOT coming# 6. HDMI 端口真實狀態(tài)看 mConfigs別看 cable_connection_statusadb shell dumpsys tv_input|grepTvInputHardwareInfo|grephdmi# 7. 切換輸入時抓 CEC 報文adb shell logcat-c# ...在電視上切到目標輸入...adb shell logcat-d|grep-EHdmiCecController|portSelect健康基線指標正常值故障值Tx notify NOT coming0 次/分鐘每 2 秒 1 次Failed to send0每條報文都失敗[R]接收記錄有零mDeviceInfos含下游設備只有 TV 自己mIsCecAvailabletruefalse需重啟恢復十二、后記這次真正花時間的不是找答案而是證偽——把Apple TV 設置問題“固件 bug”主板硬件故障一個個排除掉。而排除的過程是人和 AI 交替推進的它挖數(shù)據(jù)我提供它拿不到的事實它試軟件手段我做物理動作它下結論我負責質(zhì)疑它寫工具我負責用最有價值的兩個技術動作也正好一人一半看[R]記錄AI 發(fā)現(xiàn)——一條接收都沒有比任何猜測都硬。隔離變量拔光所有線人執(zhí)行——有時候拔掉一切比任何高級命令都有效。至于到底是哪根線的問題目前還沒定論HDMI2 上還有一臺設備沒插回去可能是它也可能只是某次插拔導致 13 腳接觸劣化、重新插拔就恢復了。這類故障有復發(fā)風險先把流程記下來下次直接照做。