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