Linux 核心正準備把 Android 長期使用的 C 語言 Binder 驅動移除，改由 Rust 實作接手。這不只是「用新語言重寫舊程式」，而是核心維護者打算停止雙軌維護，將後續功能與最佳化集中到 Rust 版本。真正值得注意的訊號，是 Rust 已從 Linux 核心中的實驗選項，走到足以取代既有關鍵元件的位置。
事件進度：已進入整合流程，但尚非正式版本
來源事實：Phoronix 報導，Rust Binder 已在 Linux 6.18 納入上游；移除 C 版本的變更則被 Greg Kroah-Hartman 收進 char-misc-next 分支，預計提交 Linux 7.4 合併窗口。原始報導見 https://www.phoronix.com/news/Google-Binder-C-Goodbye。
Linux 核心郵件列表的補丁可進一步交叉驗證：這次變更涉及 20 個檔案、增加 9 行並刪除 11,470 行；其中 binder.c 本身占 7,186 行，其餘包括配置、記憶體配置器、binderfs、追蹤與測試程式。因此，把事件簡化成「刪除一萬多行 Binder 主程式」並不精確。補丁同時讓 CONFIG_ANDROID_BINDER_IPC 明確依賴 Rust，並把模組名稱由 rust_binder 改回一般性的 binder。原始補丁存檔見 https://lists.openwall.net/linux-kernel/2026/09/12/891。
仍須注意，「進入 -next 分支」代表已走到正式合併前的重要階段，不等於 Linux 7.4 已發布，也不保證其間不會因回歸或建置問題而調整。現階段最準確的說法是：C Binder 的退場已獲主要開發者支持並排入上游整合流程。
Binder 為何值得如此慎重
Binder 是 Android 的跨行程通訊機制。依 Android 官方文件，呼叫端會把目標、方法識別碼與參數包成交易，交給核心 Binder 驅動；驅動辨識接收端、將交易複製到另一個行程的位址空間，再喚醒執行緒處理與回傳結果。相機應用程式與相機服務、App 與 system server、系統服務與 HAL，都可能經過這條路徑。相關流程見 https://source.android.com/docs/core/architecture/ipc/binder-overview。
也就是說，Binder 同時面對不受信任的輸入、物件生命週期、參照計數、跨行程記憶體、執行緒配置及複雜鎖定關係，而且效能退步可能直接反映在介面延遲。Google 工程師 Carlos Llamas 在補丁說明中表示，C 版本經過十五年以上演進後，新增功能已變得痛苦，也容易碰觸安全弱點；Rust 版本則已達功能對等，並在 Android 裝置上運作一段時間。
工程與商業邏輯：重點是結束雙重成本
合理推論：Rust 的安全價值不只在阻擋部分越界存取或釋放後使用。對 Binder 這類具有複雜所有權關係的程式，型別系統可迫使開發者明確表達物件由誰持有、可以存活多久，以及哪些共享狀態需要同步。這會把部分原本依賴人工審查與隱含慣例的風險，提前轉成編譯期問題。
但真正的維護紅利要等 C 版本退出才會出現。兩套實作並存時，每項功能、修補與效能最佳化都可能需要重做、比對行為並維持測試矩陣。刪除舊版本等於停止支付這筆「相容保險費」，也讓團隊只需在一條主路徑上累積知識。Rust Binder 作者 Alice Ryhl 在最初公開重寫工作時，也把問題定位為 Binder 未來可維護性的工程選擇，而非單純追逐語言潮流：https://ryhl.io/blog/rust-binder/。
實際影響不會一夜抵達所有手機
對一般 Android App 開發者而言，若使用者空間介面與行為維持相容，這次替換理論上不需要改寫 AIDL 或應用程式。較直接受影響的是核心建置者、Android 平台團隊、晶片商與 OEM：啟用 Binder 的核心如今也必須具備受支援的 Rust 工具鏈、建置設定、除錯能力與持續整合環境。
此外，主線 Linux 的進度不能直接換算成既有手機的更新時程。Android 裝置通常以 LTS 核心和 Android Common Kernel 為基礎，再搭配 GKI 與硬體供應商模組；各產品何時採用，取決於其核心世代與供應鏈整合週期。Android 官方對 ACK、GKI 與供應商模組的說明見 https://source.android.com/docs/core/architecture/kernel。
容易忽略的限制
Rust 並不等於零漏洞。權限判斷、協定狀態、排程策略、資源耗盡與鎖定順序仍可能出錯；與核心 C API 交界處也需要人工證明安全條件。補丁保留名為 rust_binderfs.c 的 C 元件，更說明這不是把相關程式全部變成純 Rust，而是把高複雜度的主要驅動邏輯換掉。
效能方面，目前「相當或經常更快」主要來自維護者在補丁中的陳述，公開材料沒有提供足以代表所有 SoC、記憶體壓力與真實工作負載的完整統一數據。因此應把它視為移除舊版的工程依據，而不是 Rust 在所有 Binder 情境都必然更快的普遍結論。
對台灣產業的意義與觀察指標
作者觀點：對台灣手機、嵌入式設備、晶片與 ODM 供應鏈而言，最大的變化不是消費者立刻感受到速度提升，而是核心能力的門檻開始改變。未來能否維護 Rust 核心程式、分析跨語言堆疊、重現 Binder 延遲與記憶體問題，將逐漸成為平台工程能力的一部分。Rust 不再只是應用層選項，而可能進入產品核心的必要建置鏈。
- 移除補丁是否如期進入 Linux 7.4 主線，而非停留在 char-misc-next。
- 各架構與核心配置的建置、Binder 自我測試及 Android 相容性測試是否持續通過。
- Android Common Kernel 何時取消 C Binder 選項，OEM 與晶片商又何時跟進。
- 高負載、記憶體壓力、即時優先權與大量物件交易下，是否出現新的延遲或資源回收回歸。
- 新功能是否開始只提交到 Rust 路徑，以及後續安全公告中 Binder 記憶體錯誤的型態是否真正改變。
Binder 的案例不能證明所有成熟 C 驅動都適合重寫，卻建立了一個更務實的判準：當替代實作完成相容性、實機運行與效能驗證後，安全語言的最大紅利可能不是「多留一個選項」，而是有條件地讓高成本舊路徑正式退場。