我和 AI 一起修電視索尼 CEC 失效排查實(shí)錄TL;DR電視的 HDMI-CEC 全鏈路癱瘓根因是某根 HDMI 線把 CEC 總線13 腳拉死導(dǎo)致電視開機(jī)時(shí) CEC 初始化失敗。而mIsCecAvailable這個(gè)標(biāo)志一旦為 false 就不會(huì)自愈所以后續(xù)怎么重啟、怎么改設(shè)置都沒用。修復(fù)動(dòng)作只有一個(gè)組合拔光所有 HDMI 線 → 重啟電視不是待機(jī)→ 插回設(shè)備。順序不能反。這篇文章除了講技術(shù)還想講清楚一件事這整個(gè)過程是我和一個(gè) AI 智能體一來一回干完的。它負(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 沒反應(yīng)屏幕黑著電視遙控器按下去Apple TV 毫無響應(yīng)得先摸出 Siri Remote 按一下Apple TV 才醒按以前的習(xí)慣這種問題我會(huì)自己開終端一條條adb shell試。但那天太晚了我換了種干法——直接把電視的 adb 連接交給 WorkBuddy 里的智能體小智讓它自己查。我的開場(chǎng)白只有一句我我的電視的 HDMI3 連接的是 Apple TV分析一下為什么我將信號(hào)源切換到 HDMI3 的時(shí)候沒有喚醒 Apple TV。它回得也很干脆小智我先連電視把 HDMI-CEC 的實(shí)際配置和切換 HDMI3 時(shí)的日志抓出來再下結(jié)論。然后它就開始自己跑命令了。下面整個(gè)過程都是真實(shí)發(fā)生的交互。一、第一回合AI 交上來的體檢報(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è)備都沒有。以及報(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都沒有。它給我的解釋是小智CEC 是雙向總線協(xié)議。一條[R]都沒有意味著這塊電視從來沒有成功接收過任何 CEC 報(bào)文。這不是Apple TV 沒開某個(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 可能一直就沒工作過只是你之前沒用過這個(gè)功能。二、第二回合我的一句話把方向掰回來了它問了我一個(gè)關(guān)鍵問題小智順便問一句你用 Apple TV 遙控器能開關(guān)電視或者調(diào)電視音量嗎如果完全沒反應(yīng)基本就坐實(shí)是 CEC 整條鏈路的問題。我的回答同時(shí)也否掉了它前面的推測(cè)我能以前用電視遙控器切換到 HDMI3會(huì)喚醒 Apple TV然后用電視遙控器也能夠控制 Apple TV現(xiàn)在不行了。它立刻改了判斷小智這條信息很關(guān)鍵。既然以前能用那說明這不是出廠即壞我收回一直沒工作的判斷。CEC 硬件是好的現(xiàn)在處于卡死狀態(tài)。這是整個(gè)排查的轉(zhuǎn)折點(diǎn)。如果它繼續(xù)沿著硬件從來沒工作過推下去結(jié)論會(huì)變成主板故障送修而曾經(jīng)好過、現(xiàn)在壞了這個(gè)前提把方向引向了后來發(fā)生了什么變化——這才有了后面的隔離實(shí)驗(yàn)。我后來復(fù)盤時(shí)覺得這是人機(jī)協(xié)作里最值錢的部分AI 能看到我看不到的數(shù)據(jù)但它不知道我的生活史。有些信息只存在于人腦里必須由人補(bǔ)給它。三、第三回合AI 自己設(shè)計(jì)并執(zhí)行了五次搶救確認(rèn)是后天失效之后它沒有停在分析上而是自己列了一串恢復(fù)手段一條條試#手段命令結(jié)果1CEC 開關(guān)重置cmd hdmi_control cec_setting set hdmi_cec_enabled 0→1? 無效2ARC 通道重置cmd hdmi_control setarc off→on? 無效3重啟 CEC HAL 進(jìn)程kill -9 pid?Operation not permitted無 root4端口抖動(dòng)檢測(cè)10 秒 × 5 次采樣? 四口狀態(tài)恒定非接觸不良5整機(jī)重啟adb reboot? 無效其中第 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í)。這一條就夠了——問題與 Android 的 CEC 狀態(tài)機(jī)無關(guān)與 BRAVIA Sync 的設(shè)置無關(guān)是驅(qū)動(dòng)/物理層的持續(xù)故障。這是全篇最有說服力的一段證據(jù)。我自己想不到這么試一般人的思路是打開看看而它是關(guān)掉看看——如果關(guān)了還在報(bào)錯(cuò)說明報(bào)錯(cuò)的根本不是這一層。四、第四回合它給不了手于是給我造了把工具到這一步它已經(jīng)很明確了問題在物理層而物理層它碰不到。小智軟件層能試的全試完了四條路全堵死。剩下的必須動(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 次就說明有東西在拉著總線。這個(gè)設(shè)計(jì)讓我不用反復(fù)跑命令、翻日志只要看著屏幕拔線就行。這是我覺得 AI 在這類任務(wù)里最實(shí)用的能力它能把你去做物理動(dòng)作我盯著數(shù)據(jù)這種配合變成現(xiàn)實(shí)。五、第五回合我拔線它看數(shù)據(jù)我按它說的把四根 HDMI 線全拔了然后截了張監(jiān)控圖發(fā)過去。00:01:02 [總線異常] ... 00:02:12 [總線異常] 00:02:14 [總線正常] ← 從這里開始一次超時(shí)都沒有了 ... 00:03:01 [總線正常]它的反應(yīng)小智這個(gè)結(jié)果很關(guān)鍵四根線全拔掉后 TX 超時(shí)在同一瞬歸零了。說明電視的 CEC 控制器本身沒壞問題出在外部。它還注意到一個(gè)我沒在意的細(xì)節(jié)小智注意那個(gè)70 秒的延遲——拔線之后不是立刻恢復(fù)而是過了一分多鐘才徹底安靜。說明 CEC 控制器需要重新檢測(cè) HPD 狀態(tài)、重新初始化才能脫離異常態(tài)。這句話后來成了修復(fù)方案的關(guān)鍵。六、第六回合為什么之前那次重啟沒用在等我的過程中它自己去重啟了一次電視adb reboot然后查狀態(tài)——還是壞的。它當(dāng)時(shí)的解釋小智mIsCecAvailable是開機(jī)時(shí)一次性判定的一旦變成 false 就不會(huì)自愈只有重啟才能重新初始化。之前那次重啟時(shí)線還插著、總線還是壞的所以重啟后照樣失敗。必須先拔線、再重啟順序反了就是白折騰。這個(gè)因果鏈一說通整件事就閉環(huán)了某根線把 CEC 總線拉死 ↓ 電視開機(jī)時(shí) CEC 初始化失敗 → mIsCecAvailable false ↓ 這個(gè)標(biāo)志不會(huì)自愈只有重啟有機(jī)會(huì)翻盤 ↓ 重啟的那一刻如果總線還是壞的 → 依然失敗 ↓ 所以必須先拔線制造干凈環(huán)境再重啟它甚至主動(dòng)承認(rèn)了這個(gè)順序問題小智這也是我一開始沒讓你先拔線就重啟的原因——當(dāng)時(shí)我還沒排除是電視本身壞了。七、第七回合驗(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 ← 問 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)告里有一段我覺得最值得單獨(dú)拎出來的分析——為什么設(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語義能喚醒設(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è)備表本來就是空的。所以形成了雙重故障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ò)來證明問題不在這一層自己造工具發(fā)現(xiàn)需要人配合做物理動(dòng)作當(dāng)場(chǎng)寫了監(jiān)控腳本不漏細(xì)節(jié)從一堆日志里挑出 70 秒延遲、errorCode2、mConfigs變空這些線索不嫌煩凌晨一點(diǎn)反復(fù)采樣、反復(fù)對(duì)比沒有差不多就這樣吧只有人能做的部分能力為什么 AI 不行拔線 / 插線物理世界沒有 API補(bǔ)充生活史以前能用這句話決定了整個(gè)排查方向AI 無從得知質(zhì)疑結(jié)論它說可能一直沒工作過我一句以前能用就把它掰回來了看畫面“切過去了但黑屏和切過去了有畫面”只能人眼判斷量電壓萬用表是它碰不到的東西AI 在這件事里犯的兩個(gè)錯(cuò)寫出來才有參考價(jià)值過早下結(jié)論看到首次開機(jī)就失敗就推斷從沒工作過。它缺的是時(shí)間維度的信息用戶的使用史這個(gè)必須人補(bǔ)。順序搞錯(cuò)先提議重啟、后提出拔線。雖然它后來自己糾正了“必須先拔線再重啟”但這個(gè)順序問題導(dǎo)致了中間一次無效嘗試白等了 45 秒。規(guī)律是AI 在信息完備的確定性推理上極強(qiáng)在信息缺失時(shí)該不該下結(jié)論上容易冒進(jìn)。十、技術(shù)總結(jié)三條能省下幾小時(shí)的經(jīng)驗(yàn)1.mIsCecAvailable不會(huì)自愈這個(gè)字段在HdmiControlService初始化時(shí)一次性判定一旦為 false后續(xù)無論開關(guān) CEC、改設(shè)置、切輸入都不會(huì)翻回來。唯一出路是重新初始化也就是重啟?？吹絤IsCecAvailable: false別浪費(fèi)時(shí)間調(diào)設(shè)置。2. 必須先拔線再重啟順序反了等于白做。開著機(jī)的設(shè)備狀態(tài)是壞的快照重啟會(huì)把這個(gè)快照固化下來。推廣一下任何開機(jī)自檢 狀態(tài)鎖死型故障都要先制造干凈環(huán)境再重啟。3.cable_connection_status字段不可信排查中一度被它誤導(dǎo)明明線拔了還是顯示cable_connection_status1已連接。可靠的判斷依據(jù)是mConfigs數(shù)組mConfigs: [] ← 沒信號(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è)備表有沒有識(shí)別到下游設(shè)備adb shell dumpsys hdmi_control|sed-n/mDeviceInfos:/,/mCecController/p# 3. 報(bào)文歷史[S] 發(fā)送 / [R] 接收重點(diǎn)看有沒有 [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è)置問題“固件 bug”主板硬件故障一個(gè)個(gè)排除掉。而排除的過程是人和 AI 交替推進(jìn)的它挖數(shù)據(jù)我提供它拿不到的事實(shí)它試軟件手段我做物理動(dòng)作它下結(jié)論我負(fù)責(zé)質(zhì)疑它寫工具我負(fù)責(zé)用最有價(jià)值的兩個(gè)技術(shù)動(dòng)作也正好一人一半看[R]記錄AI 發(fā)現(xiàn)——一條接收都沒有比任何猜測(cè)都硬。隔離變量拔光所有線人執(zhí)行——有時(shí)候拔掉一切比任何高級(jí)命令都有效。至于到底是哪根線的問題目前還沒定論HDMI2 上還有一臺(tái)設(shè)備沒插回去可能是它也可能只是某次插拔導(dǎo)致 13 腳接觸劣化、重新插拔就恢復(fù)了。這類故障有復(fù)發(fā)風(fēng)險(xiǎn)先把流程記下來下次直接照做。