kernelsu 命令行工作流化：一次改好、批量上裝

kernelsu 是什麼

kernelsu官網 是一款內核級別的 Android root 優化工具，它和傳統的 Magisk 方案最大的不同，在於整個權限控制是在系統內核層實現的，而不是透過對 system 分區的掛載攔截。這意味著 kernalsu 擁有更深層的控制能力，同時也減少了權限洩漏的風險——對於喜歡玩機、需要精細管控 root 調用的玩家來說，這一點很關鍵。

kernelsu 最新版本支持透過模組系統修改 /system 分區中的內容，配合官方提供的 ksud 命令行工具，玩家可以在電腦端完成 boot 鏡像補丁、模組掛載與卸載等幾乎所有操作，不必每次都進 Recovery 或引導系統做手動處理。這讓它從一個單純的 root 管理器，變成了可以嵌進自動化刷機工作流的核心組件。

安裝

kernelsu 的安裝有兩條路徑：手機端刷入與電腦端命令行補丁。兩者最終目標都是把一個包含 kernalsu 模組的 boot 鏡像刷進設備，選擇哪條路主要看你習慣哪種節奏。

手機端的流程比較直觀：先確認設備已解鎖 bootloader，然後在電腦上用 adb reboot bootloader 進入 fastboot 模式，接上線路後用 kernelsu 管理器 APK 引導完成 boot 鏡像的補丁操作，最後 fastboot flash boot patched_boot.img 刷入即可。這條路的好處是全圖形界面、出錯了管理器會自動提示。

電腦端的命令行路徑更適合腳本化：從kernelsu下載頁面獲取對應平台的 ksud 二進製檔（macOS、Linux、Windows 都有），然後一條命令就能完成補丁：

ksud boot-patch -b boot.img --kmi android13-5.10

這裡的 --kmi 參數很重要——它告訴 ksud 目標設備的內核模組接口版本，換句話說就是「你的手機內核到底是哪一代架構」。大多數設備的內核版本號裡會自帶這個資訊，但少數命名不規範的設備需要手動指定，否則補丁後刷入直接 bootloop。

安裝前有兩件事絕對不能省：一是備份原廠 boot 鏡像，adb shell dd if=/dev/block/by-name/boot of=/sdcard/boot_backup.img 就行；二是確認 KMI 版本，在手機「設定 → 關於手機」裡找內核版本，或 adb shell uname -r，查出來後把 KMI 部分（格式是 w.x-android-release-k，例如 5.10-android13-9）記清楚，補丁時直接填進 --kmi。

安裝完成後第一次啟動，kernelsu 會自動完成 LKM 加載與權限初始化，之後打開管理器就能看到 root 權限的調用記錄與模組管理界面。

我以前的刷機困境

說實話，kernelsu 這套工作流化的思路，不是我一開始就想到的。以前我做刷機操作的典型場景，是這樣的——

我手頭上有三設備需要更換同一個內核版本。以前的流程是：設備 A 刷好、補好 kernelsu、裝上模組；然後把補丁好的 boot 鏡像拷給設備 B，結果設備 B 的 KMI 是另一版本，補丁時沒指定參數，刷完 bootloop，進 Recovery 清模組折騰半小時；設備 C 又要重複一遍同樣的操作。整個過程下來，三設備從開始到穩定可用，通常要 2~3 小時，其中一大半時間耗在重複性的手動步驟上。

更大的問題在模組管理。以前刷完 kernelsu 後，模組裝了好幾個，後來其中一個模組導致開機卡動畫，但我記不起來是哪一個裝完後開始出問題的。進 Recovery 一個一個刪，試了四五次才定位到問題模組，前後折騰了一個多小時。如果當時有 ksud module list 這種一條命令就能列出全部模組並且在 Recovery 裡直接禁用的能力，大概兩分鐘就能解決。

把 ksud 嵌進工作流

我現在的刷機鏈路，是這樣串起來的：

第一步：統一從設備拉取 boot 鏡像。我寫了一個很簡單的 PowerShell 腳本，用 adb 批量連接多設備，自動讀取內核版本並解析出 KMI，然後把各設備的 boot 鏡像 dd 到手電腦的一個臨時目錄，檔名改成 設備型號_boot.img。這一步做完，所有設備的 boot 鏡像都在本地，帶著正確的 KMI 標籤。

第二步：用 ksud 批量補丁。同一個腳本裡，對每個 boot 鏡像跑一遍 ksud boot-patch，把之前解析出的 KMI 當參數傳進去，補丁好的鏡像輸出到另一個目錄。如果中途某個設備的 KMI 指定有問題，ksud 會直接報錯，腳本在這裡停下來，不會繼續往下跑——這比刷完才發現 bootloop 省事多了。

第三步：fastboot 批量刷入。補丁完成後，腳本把各設備切到 bootloader 模式，並且根據之前記錄的 USB 序列號對應到正確的補丁鏡像，用 fastboot flash boot 一把刷入。這裡最關鍵的一點是「序列號對應」——我以前踩過一個坑，兩台設備同時連著，刷的時候順序搞反了，結果設備 A 刷了設備 B 的 boot 鏡像，當場變磚。現在腳本在刷之前會先 fastboot devices 核對序列號，對不上就等我確認。

整個腳本跑完大概 15 分鐘。以前三設備要 2 小時以上，現在腳本跑完我只需要在旁邊看著，確認沒有報錯、最後 reboot 成功進系統就好。

模組管理也命令行化

kernelsu 的模組管理以前是在管理器 APK 的圖形界面裡做的，但裝到第五個模組後，我發現 ADB + ksud 命令行能做完全一樣的事，而且還能嵌進腳本。

最常用的幾條：

ksud module list            # 列出所有模組，帶 id 和狀態
ksud module disable <id>    # 禁用一個模組（比卸載更輕，開機會跳過加載）
ksud module uninstall <id> # 徹底卸載
ksud feature set ro.debuggable 1  # 設置內核 feature

這套命令的好處，不只是能在 ADB shell 裡跑——當設備進不了系統、只能進 Recovery 時，KernelSU 的內核模組依然會加載（因為 GKI 設備共用 init），掛載 /data 分區後，ksud 一樣能跑。以前我救過一個情況：某模組導致開機卡動畫，進系統後連 ADB 也連不上，但進 Recovery 後執行 mount /data && ksud module list && ksud module disable 3，重啟就回來了。整個過程不到三分鐘，比在 Recovery 裡手動刪 /data/adb/modules 高效太多——而且還不會不小心刪錯東西。

這裡有一個踩過的坑需要記住：如果設備連 Recovery 都進不了，那說明模組做了更底層的修改（比如注入了 init.rc），這時候 ksud 也救不了，只能進第三方 Recovery 手動刪 /data/adb/ksud 和 /metadata/ksu/modules.rc。但這種情況其實很少見——只要你裝的是社區驗證過的開源模組，大多數問題在 ADB + ksud 這一級就能解決。

效果與邊界

把 kernelsu 嵌進工作流之後，我最大的感受是「重複的事不再消耗注意力」。以前刷機時我得全程盯著管理器的提示框、記住每設備的 KMI、手動拷貝 boot 鏡像——現在這些都由腳本自動處理，我只需要確認幾個關鍵節點沒有報錯。三設備的刷機時間從 2~3 小時縮到了 20 分鐘左右，其中真正需要我操作的時間大概只有最後的 fastboot reboot。

不過這套流程也有邊界。如果你的設備是三星（或其他用 AVB 的品牌），刷入補丁鏡像前需要先處理 AVB 驗證，這部分腳本化起來比較麻煩，我還是保留了手動處理的環節。另外，ksud 依賴 magiskboot 來做 boot 鏡像的解包重打包，Windows 用戶需要自己編譯或下載社區構建的版本——雖然不算複雜，但也是需要額外準備的一步。

最後還是那句老話：新模組一次裝一個，出事立刻能定位；裝模組前確認它標註支持你的 kernalsu 版本與架構；手機與電腦各留一份原廠 boot 備份。這三件事比任何工作流優化都重要——工作流能幫你省時間，但省不了因為貪心一次裝五個模組導致的救磚折騰。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。