KernelSU 懶人術：讓機器幫你搞定模組刷入與權限配置

KernelSU 是什麼

KernelSU 是一套跑在 Android 內核層的 root 解決方案。跟老牌的 Magisk 在 ramdisk 層打補丁不同，它直接改寫 kernel，把權限控制鑽到最底層去——好處是權限洩漏的風險更低，也更難被應用檢測到。從 Magisk 遷過來的玩家第一個撞到的差異就是它的授權模型：完全沒有彈窗，應用請求 root 一律默認拒絕，想要授權必須自己進管理器手動開關。這個設計把主動權收得很死，但也意味著你得自己把權限這扇門把關好——完整的整合指引在 kernelsu下載。

v3.0.0 版本之後，KernelSU 引入了 LKM 構建方案，模組系統也更成熟了——通過 meta-overlayfs 之類的元模組，你可以把自定義的 system 內容疊加進 /system 分區，從卸載預裝軟體到替換系統字體都能搞定。對喜歡折騰的人來說，這套體系最大的魅力不在功能多強，而在於它留給了你大量自動化的縫隙——腳本系統、環境變量、安裝鉤子，每個重複操作都有機會交給機器跑。

安裝

KernelSU 的安裝跟普通 APK 完全是兩碼事。下載到手機上的那個 7.46MB 的 APK 只是管理器界面，真正的 root 能力需要把 KernelSU 構建進你的設備內核。

如果你用的是 GKI 設備（Android 12 之後的大多數新機），最省事的路徑是用 kernelsu官網 提供的 setup.sh 腳本一鍵集成：下載對應你設備型號的內核源碼，在源碼根目錄跑 setup.sh，它會自動拉取 KernelSU 合併進去，然後編譯出帶內核的 boot.img。非 GKI 老設備就得自己補丁打進 boot 鏡像，這條路徑麻煩得多，官方也在 v3.0 起開始弱化這條線。

刷入完成後重啟設備，安裝 APK 打開管理器，如果顯示「KernelSU 正常運行」就成功了。初次進入會要求你給 su 二進制安裝位置——選 /data/adb/ksu/bin 就行，別碰系統分區。安裝完別急著刷模組，先確認你裝了 meta-overlayfs 這個元模組——大多數模組掛不上 system 就是因為漏了這個步驟。

它內建了哪些自動化能力

從 kernelsu文檔 的模組開發入門一節就能看到，KernelSU 的腳本體系對 Magisk 用戶來說幾乎是平移過來的——post-fs-data.sh（分區掛載後立即執行）、service.sh（系統啟動服務後執行）、customize.sh（模組安裝階段執行），執行時機和語義跟 Magisk 一模一樣，甚至 BusyBox 二進制都是直接編譯 Magisk 項目那個版本。但 KernelSU 在這個基礎上補了兩個新腳本：post-mount.sh（元模組掛載完成後觸發）和 boot-completed.sh（系統完全啟動後觸發），這兩個鉤子給了你更精確的自動化掛載點。

變量層面也有增量——REMOVE 和 REPLACE 兩個變量讓卸載系統應用變成了純配置活。以前你得手寫 mknod 命令觸發 whiteout，現在只要在 customize.sh 裡寫：

REMOVE=" /system/app/YouTube /system/app/Bloatware "

安裝器就會自動幫你執行對應的隱藏操作。環境變量也細化了——腳本裡判斷宿主環境用 KSU=true 而不是 MAGISK_VER，後者在 KernelSU 裡會恆返回一個假值，踩過一次坑就記住了。

另外，setup.sh 本身就是一個自動化的典範——它支持三種模式（最新穩定 tag、main 開發分支、指定 tag），一條命令就能把 KernelSU 合併進內核源碼，省去了手動 cherry-pick 補丁的麻煩。

值得交給機器的兩件事

批量卸載預裝軟體

這是我最受益的一項。換新機第一件事就是卸預裝——以前每次都要 adb shell 進去逐個 pm uninstall，一台新機跑下來半小時沒了。現在只要寫一個模組，customize.sh 裡用 REMOVE 變量列出所有要卸的包，刷入重啟搞定。而且模組會自動保留卸載清單，下次刷完 OTA 補丁後模組重新掛載，卸載動作也會跟着生效——不用再跑一遍手動腳本。

配置路徑就是模組的 customize.sh，變量值要注意前後空格（這是 KernelSU 解析的習慣），別寫成緊緊的一串。如果要替換系統應用（比如把自帶瀏覽器換成 F-Droid 版），用 REPLACE 變量指向你的 apk 目錄，掛載時自動疊上去。

啟動時自動執行的維護腳本

我在 service.sh 裡掛了兩件事：一個是自動備份當前的模組清單到 /data/local/tmp/ksu-backup/，另一個是用 resetprop（不是 setprop——setprop 在 post-fs-data 階段會死鎖，這是個要記住的坑）把一些調試用的 prop 改掉，讓 logcat 更乾淨。boot-completed.sh 裡再掛一個延遲執行的清理任務，刪掉上次 OTA 殘留的臨時文件。

這些腳本寫好就再也不用管了——重啟時自動跑，失敗了 KernelSU 會在日誌裡標註，不會卡死開機流程。唯一要注意的是 post-fs-data.sh 階段絕對不能用 setprop，這是文檔裡明確寫死的禁區。

不值得自動化的事

應用授權

KernelSU 的默認拒絕模型本身就是在反對自動化授權——你不能寫腳本讓某個應用自動獲得 root，也不能批量導入授權清單（目前沒有這個接口）。每個應用的權限都得在超級用戶頁手動開關，甚至開關之後你還得進 App Profile 去進一步收窄 capabilities。

這個設計看起來麻煩，但實際上是對的——應用請求 root 時彈窗詢問本身就會被應用繞過（重複請求、偽裝彈窗），自動化只會放大這個風險。我試過在 service.sh 裡用 su 命令行授權，結果發現 App Profile 的設置根本沒生效——命令行授權是粗粒度的，等於繞過了 KernelSU 最核心的權限收窄機制，乾脆作罷。

元模組切換

切換元模組的正確順序是：卸所有常規模組 → 卸當前元模組 → 重啟 → 裝新元模組 → 重裝常規模組 → 再重啟。這個流程有嚴格的順序依賴，跳步會導致模組狀態不一致。我曾經想寫個腳本自動跑，結果在卸載階段就卡住了——KernelSU 卸載元模組需要確認對話框，沒有命令行接口能繞過。而且元模組本身影響所有模組的掛載狀態，自動化出錯的代價太大，手動跑六步雖然麻煩但出錯可控。

翻車了怎麼救

模組不生效

按文檔的自檢清單來：先看元模組是不是啟用了（模組頁會有特殊標識），再看常規模組自己有沒有 disable 標記，有沒有 skip_mount 標記。如果剛做過 OTA，分區對不上也會導致掛載失敗——這時得用 ksud 命令看日誌，定位是掛載階段失敗還是腳本執行階段失敗。

腳本執行死鎖

post-fs-data.sh 裡調用了 setprop 是最常見的死鎖原因。解決方法就是全部換成 resetprop -n，這個命令不會觸發 service 重啟，不會卡。如果是其他腳本掛起，進 recovery 或用 fastboot 刷回備份的 boot.img 就能救回來——所以前面說的自動備份模組清單才重要，重裝時有得參考。

環境變量判斷錯了

KernelSU 裡 MAGISK_VER 會恆等於 25.2，如果你在腳本裡用它來判斷宿主環境，所有條件分支都會走偏。統一改成 KSU=true 判斷，這是 KernelSU 專屬的變量值。

結語

KernelSU 的自動化能力是為「重複勞動」設計的——卸預裝、啟動維護、批量模組配置這些事，寫好腳本就一勞永逸。但在權限這種安全敏感的環節，它刻意把自動化的門焊死了，留給你手動把關。我現在的體會是：把自動化用在「步驟固定、頻率高、出錯代價低」的地方，把手動留給「每個應用都不同、後果要自己擔」的地方，這套體系才不會變成另一件麻煩事。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。