KernelSU v1.0.5 安裝教學與實測紀錄:LKM 與 GKI 模式操作指南

Magisk 推出後,成為 Android 裝置取得 root 權限的主流方式,支援性與模組生態也隨之蓬勃發展。然而,隨著 Android 系統架構持續演進,越來越多裝置採用 GKI(Generic Kernel Image)設計,使得 Magisk 的傳統做法在部分情境下開始顯得受限。

在這樣的背景下,開發者圈子出現了另一種選擇:KernelSU。這是一個由中國開發者 tiann 推出的專案,目的是透過 直接修改 Linux 核心行為 來取得 root 權限,跳過以往依賴 boot.img patch 的方式。相較於 Magisk,KernelSU 更加「Kernel(系統核心)導向」,特別適合用於開源核心或基於 GKI 架構的裝置,並逐漸受到 AOSP 玩家與Kernel自編譯使用者的關注。

KernelSU 發展初期以中國社群為主,後來逐步擴展至國際開發者圈。目前已能適用於多數開源Kernel或支援 GKI 架構的 Android 裝置,並持續有更多開發者針對 KernelSU 進行模組相容性調整與實作驗證,整體社群活躍度也在穩定成長中。不過實際使用仍須視設備Kernel版本與架構支援情況而定。

📎 其他可參考使用的 Root 工具:若是初次進行 Android 裝置的 Root 操作,或尚未確定使用哪一種工具,除本篇教學之外,也可參考本站整理的其他 Root 解決方案,各具特色與相容條件,請依照裝置類型與需求選擇適合的方式:

安裝與操作前的準備事項

裝置端操作條件與注意事項

進行 Root 操作與映像刷寫前,請先確認裝置處於可操作狀態,並完成以下準備,以降低操作風險並確保流程順利:

📌 必要條件

  • 裝置已解鎖 Bootloader:未解鎖的裝置無法進行映像刷寫或 Kernel 權限修改。
  • 開啟開發者選項並啟用 USB 除錯功能:確保可透過 ADB 正常與電腦端連線。

📌 建議操作(降低風險)

  • 關閉鎖屏密碼與指紋辨識:可避免進入 fastboot 模式或刷入映像後,發生解密錯誤或權限驗證異常。
  • 已備份裝置資料:Root 操作涉及系統變更,建議完整備份應用資料與個人檔案,以備不時之需。

📌 相容性提醒

  • 確認裝置當前的韌體版本:建議先從裝置中查明目前的韌體版本,作為後續下載原廠映像、並從中取得對應 boot.img 或 init_boot.img 的依據。請確保映像版本與裝置實際情況一致,避免在使用 [工具名稱] 處理時,因版本不符導致刷入後無法正常開機或進入 bootloop。

Windows 環境工具準備與操作路徑規範

本教學操作環境以 Windows 為主,過程中會使用 adb、fastboot 等指令與工具,請依照下列步驟完成前置準備:

KernelSU 系統需求

  • KernelSU officially supports Android GKI 2.0 devices (kernel 5.10+). Older kernels (4.14+) are also supported, but the kernel will need to be built manually.
  • With this, WSA, ChromeOS, and container-based Android are all supported.
  • Currently, only the arm64-v8a and x86_64 architectures are supported.

實際安裝紀錄與操作流程

KernelSU 提供兩種主要的安裝模式:LKM(Loadable Kernel Module)和 GKI(Generic Kernel Image)。

  • LKM 模式:透過可載入的 Kernel 模組方式,將 KernelSU 注入現有的 Kernel 中,無需替換原始 Kernel。此模式適合希望保留原廠 Kernel 或使用第三方 Kernel 的使用者。
  • GKI 模式:直接使用 KernelSU 提供的通用 Kernel 映像,替換裝置原有的 Kernel。此模式適用於需要更高通用性或在 LKM 模式無法運作的情況下。

根據 KernelSU 官方文件的建議:

如果你的裝置是手機,建議優先考慮 LKM 模式;如果是模擬器、WSA 或 Waydroid 等環境,則建議使用 GKI 模式。

不過,實際採用哪一種模式,仍應根據裝置特性、使用情境與個人需求彈性選擇。兩種方式在安裝過程中所需的工具與操作細節也有所不同。

安裝 KernelSU Manager 以判斷裝置支援情況

  • 若顯示 Unsupported,代表官方不會提供該裝置任何形式的 Kernel,若要使用 KernelSU,則必須自行編譯 Kernel。
  • 若顯示 Not installed(尚未安裝),則表示該裝置為 KernelSU 官方認證支援的設備,可直接進行安裝操作。

LKM 模式安裝紀錄

在 KernelSU 提供的兩種安裝方式中,LKM(Loadable Kernel Module)模式 是較常見且風險較低的一種。此模式不會取代裝置原本的 Kernel,而是將模組動態載入現有的 Kernel 中,讓系統取得 root 權限。

修補啟動映像檔 (init_boot.img)

開啟 KernelSU Manager,畫面會顯示目前尚未安裝 KernelSU,請點選紅色區塊的「尚未安裝」來開始操作,接著選擇「init_boot 分區的映像檔」作為修補目標 (請參考韌體提取說明,將 init_boot.img 上傳至手機中的 Download 資料夾,供 KernelSU 選取使用)

💡 補充說明
Android 13 以前的裝置,KernelSU 會針對 boot.img 進行 patch;但從 Android 13 開始,引入了 init_boot.img 作為開機階段的獨立映像檔,因此後續操作將改為處理 init_boot.img

接下來,從手機的 Download 資料夾中選取先前上傳的 init_boot.img,確認後點擊「繼續」

KernelSU Manager 會自動進行 patch 作業,完成後會在同一資料夾中產生一個新的映像檔,檔名格式為 kernelsu_patched_製作日期_隨機字串.img,這就是稍後要刷寫回裝置的映像檔

刷入修補後的啟動映像檔 (patched boot/init_boot.img)

  1. 開啟「命令提示字元」,並切換工作目錄至先前解壓縮的 platform-tools 資料夾。使用 USB 數據線將手機與電腦連接後,輸入 adb devices 指令確認 ADB 是否連線成功,若連線正常,畫面將顯示裝置序號
  2. 輸入 adb pull /storage/emulated/0/Download/kernelsu_patched_20250506_131103.img 指令,將事前透過 KernelSU 修補產生的映像檔下載至目前的 platform-tools 資料夾
  3. 輸入 adb reboot bootloader 指令,讓手機重新啟動並進入 Fastboot 模式
  4. 在 Fastboot 模式下,輸入 fastboot devices 指令,確認手機是否與電腦保持連線,若成功,畫面會顯示裝置序號
  5. 輸入 fastboot getvar current-slot 指令,系統回傳 current-slot: a,代表目前使用的是 A 分割區
  6. 接著輸入 fastboot flash init_boot_a kernelsu_patched_20250506_131103.img 指令,將修補後的映像檔刷入對應分割區
  7. 最後輸入 fastboot reboot 指令,讓手機重新開機,完成KernelSU LKM Root 操作流程

驗證裝置是否成功取得 LKM 模式 Root 權限

完成刷寫並重新啟動裝置後,開啟 KernelSU Manager,畫面上應會顯示「已開始運作 」,代表目前系統已成功以 LKM 模式執行 KernelSU。為進一步確認是否成功取得 Root 權限,也可以安裝第三方工具,例如 Root Checker。啟動後點選「驗證 ROOT」按鈕,若顯示「Root 權限已正確安裝於此裝置」即表示操作成功,系統目前具備完整的 Root 權限。

GKI 模式安裝紀錄

KernelSU 除了支援透過 LKM 模式動態載入模組外,也提供了 GKI(Generic Kernel Image)模式作為另一種安裝方式。

📌 GKI 模式的安裝方式
根據 KernelSU 官方文件,目前 GKI 模式提供以下幾種安裝方式,不同情境可選擇對應作法:

  1. 使用 fastboot 搭配 KernelSU 提供的 boot.img 安裝
  2. 使用內核刷寫工具(如 Kernel Flasher)進行安裝
  3. 手動修補 boot.img 並刷入裝置
  4. 使用自訂 Recovery(如 TWRP)進行安裝

與 LKM 模式不同,GKI 模式一律針對 boot 分區進行修改,不需要依照 Android 系統版本額外考慮 boot 與 init_boot 分區的差異。也就是說,即便是在 Android 13 或以上版本,GKI 模式仍舊是處理 boot.img。

然而,GKI 模式的核心重點在於 KMI(Kernel Module Interface)相容性。即使選擇正確的安裝方式,若所使用的 boot.img 與裝置實際執行的 KMI 不一致,Kernel 模組仍有可能無法正常載入。這是導致許多 GKI 安裝案例失敗的關鍵因素。

查詢裝置 Kernel 版本與對應的 KMI

在安裝 KernelSU Manager 後開啟,裝置核心顯示的就是目前手機的 Kernel 版本,以上圖為例,版本為 6.1.99-android14-11-gd7dac4b14270-ab12946699,KMI就會是 android14-6.1.99

接下來的段落將以實際操作為例,說明如何針對特定裝置(如 Pixel 7a)執行 GKI 模式的 KernelSU 安裝,並依照實際限制選擇合適的安裝方式。

方法一 : 透過 Fastboot 安裝 KernelSU 提供的 boot.img

假設使用者裝置的 boot.img 壓縮格式是RAW,這邊就下載 android14-6.1.99_2024-10-boot.img.gz,將壓縮檔內的 android14-6.1.99_2024-10-boot.img 解壓縮到 c:\platform-tools

  1. 開啟「命令提示字元」,並切換工作目錄至先前解壓縮的 platform-tools 資料夾。使用 USB 數據線將手機與電腦連接後,輸入 adb devices 指令確認 ADB 是否連線成功,若連線正常,畫面將顯示裝置序號
  2. 輸入 adb reboot bootloader 指令,讓手機重新啟動並進入 Fastboot 模式
  3. 在 Fastboot 模式下,輸入 fastboot devices 指令,確認手機是否與電腦保持連線,若成功,畫面會顯示裝置序號
  4. 輸入 fastboot getvar current-slot 指令,系統回傳 current-slot: a,代表目前使用的是 A 分割區
  5. 接著輸入 fastboot flash boot_a android14-6.1.99_2024-10-boot.img 指令,將修補後的映像檔刷入對應分割區
  6. 最後輸入 fastboot reboot 指令,讓手機重新開機,完成 KernelSU GKI Root 操作流程

方法二 : 手動修補 boot.img

準備修補所需檔案
使用 magiskboot 修補 boot.img 的完整流程

在命令提示字元 c:\platform-tools 下執行 magiskboot unpack boot.img 指令來將原廠韌體中的 boot.img 給解壓縮,這時候後看到 KERNEL_FMT 顯示的壓縮格式為 lz4_legacy

繼續執行 dir kernel*,會看到 c:\platform-tools 資料夾下方多出一個 kernel 檔

  1. 這時輸入 move /Y Image kernel 指令,這時會將 AnyKernel3 安裝包中的 Image 檔取代原廠 kernel
  2. 接著輸入 magiskboot repack boot.img,這時會重新封裝成 new-boot.img 檔
  1. 開啟「命令提示字元」,並切換工作目錄至先前解壓縮的 platform-tools 資料夾。使用 USB 數據線將手機與電腦連接後,輸入 adb devices 指令確認 ADB 是否連線成功,若連線正常,畫面將顯示裝置序號
  2. 輸入 adb reboot bootloader 指令,讓手機重新啟動並進入 Fastboot 模式
  3. 在 Fastboot 模式下,輸入 fastboot devices 指令,確認手機是否與電腦保持連線,若成功,畫面會顯示裝置序號
  4. 輸入 fastboot getvar current-slot 指令,系統回傳 current-slot: b,代表目前使用的是 B 分割區
  5. 接著輸入 fastboot flash boot_b new-boot.img 指令,將手動修補後的映像檔刷入對應分割區
  6. 最後輸入 fastboot reboot 指令,讓手機重新開機,完成 KernelSU GKI Root 操作流程

完成刷寫並重新啟動裝置後,開啟 KernelSU Manager,畫面上應會顯示「已開始運作 」,代表目前系統已成功以 GKI 模式執行 KernelSU。為進一步確認是否成功取得 Root 權限,也可以安裝第三方工具,例如 Root Checker。啟動後點選「驗證 ROOT」按鈕,若顯示「Root 權限已正確安裝於此裝置」即表示操作成功,系統目前具備完整的 Root 權限。

補充:其他 GKI 模式安裝選項

除了本文所介紹的兩種主要方式外,KernelSU 官方也列出了另外兩種可用於 GKI 模式的安裝方法:

  • 使用 Kernel Flasher:適用於已取得 root 權限,或可透過 fastboot boot 臨時啟動取得權限的裝置,搭配第三方 Kernel 安裝工具(如 Kernel Flasher)將對應 KMI 的 AnyKernel3 安裝包刷入系統。
  • 使用 custom Recovery(如 TWRP):若裝置本身已安裝客製化 Recovery,亦可直接透過該環境刷入對應 KMI 的 AnyKernel3 安裝包完成 KernelSU GKI 模式。

這兩種方法在部分特定場景中是可行選項,但因操作條件與適用對象較不一致,本文不進行詳細說明。

啟用 Zygisk 功能:需額外安裝 ZygiskNext 模組

KernelSU 是一套以 Kernel 層為核心的 root 權限方案,與 Magisk 最大的差異在於它僅作用於 Kernel 層,不介入 Android 使用者空間(user space)來管理模組或進行程式碼注入。因此,KernelSU 本身不內建 Zygisk 機制,也無法直接對 Zygote 進行操作。

Zygisk 是 Magisk 中用來將程式碼注入 Zygote 的機制,常見用途包括隱藏 root、提供模組 API、支援 Xposed 類模組等功能。若希望在 KernelSU 環境中使用這類功能,則需額外安裝 ZygiskNext 模組,以補足這層 user space 支援。

ZygiskNext 是由社群所維護的獨立實作版本,不僅能與 KernelSU 完整整合,近版本更可作為 Magisk 內建 Zygisk 的替代實作,提供相同的 Zygisk API 支援。其官方說明也明確標示:「Standalone implementation of Zygisk, providing Zygisk API support for KernelSU and a replacement of Magisk’s built-in Zygisk.」如需安裝 Zygisk-Next,可前往其 GitHub Releases 頁面下載最新版模組:

下載後將 ZIP 檔透過 KernelSU Manager 安裝,並重新啟動裝置,即可啟用 Zygisk 功能,讓依賴 Zygote 注入的模組得以在 KernelSU 架構下正常運作。

移除 KernelSU:依安裝模式進行清除操作

KernelSU 的移除方式會依照安裝時所採用的模式而有所不同。LKM 模式因為不修改 boot 區塊,移除操作相對簡單;而 GKI 模式則涉及 boot.img 的替換,因此需要透過刷回原始映像檔來還原。為避免操作失誤,建議依照實際安裝模式選擇正確的移除方式。

LKM 模式移除流程與注意事項

開啟 KernelSU Manager 後,點擊右上角齒輪圖示進入設定選單,即可找到「解除安裝」功能

點選「永久性解除安裝」選項,即可徹底移除 KernelSU,包含 Root 權限本體及所有已安裝的模組。解除安裝並將裝置重新啟動後,變更才會生效。

GKI 模式移除與 boot.img 還原注意事項

在 GKI 模式下,KernelSU Manager 並不會顯示「解除安裝」選項。若要反安裝,建議透過刷回原始 boot.img 的方式完成。操作流程如下:

  1. 將原廠 boot.img 放置於 c:\platform-tools 目錄,並將手機進入 fastboot 模式
  2. 執行 fastboot getvar current-slot,確認目前啟用中的分割區(例如回傳 current-slot: b 代表使用的是 B 分區)
  3. 根據查得結果,執行 fastboot flash boot_b boot.img (或 boot_a),將原始 boot.img 刷入對應分區
  4. 刷寫完成後輸入 fastboot reboot,重新啟動裝置
  5. 系統啟動後,將 KernelSU Manager 移除,即完成 GKI 模式反安裝流程

當 Magisk 無法應對時,KernelSU 或許是另一種選擇

雖然 KernelSU 的出現並非為了取代 Magisk,而是採用不同層級的權限實作方式,但在開發者社群與使用者之間,越來越多人開始分享其在「隱藏 root」方面有著更優異的表現。與 Magisk 相較,KernelSU 因為直接在 Kernel 層提供 root 權限控制,更難被常見的 App 偵測手法察覺,對於一些偵測機制特別嚴格或刁鑽的應用來說,確實能提供更高的成功率。

如果你已經遇到 Magisk 無法再滿足需求的情況,或是在某些應用環境下無法繞過偵測,不妨試試看 KernelSU。雖然安裝流程略為繁瑣,需要一些對映像檔與分區操作的熟悉,但實際上手後會發現它提供的是另一種更底層、更穩定的 root 探索方向。

主機服務:金城事務所