企业官网建设流程全解析

KernelSU 非 GKI 设备支持指南：社区内核清单、集成路径与风险控制

【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU

本篇文章聚焦 KernelSU 官方文档中「非官方支持设备」（Unofficially supported devices）页面，该页面汇集了由社区开发者维护、面向非 GKI 设备的 KernelSU 内核源码清单。读完本文，你将掌握：如何理解该清单的定位与三条核心警告、如何借助 website/docs/repos.json 按设备代号查找对应内核源码、非 GKI 设备上集成 KernelSU 的两种底层方式（kprobe 与手动打补丁），以及使用社区内核时必须承担的风险与安全措施。

一、文档定位：一份"仅存档、不再维护"的社区清单

原始文档（website/docs/vi_VN/guide/unofficially-support-devices.md，英文原版见 website/docs/guide/unofficially-support-devices.md）开篇即用三条警告框划定了这份清单的性质：

1. 仅供存档参考，不再维护：自 KernelSU v1.0 起，官方已放弃对非 GKI 设备的支持，本文档仅作为历史资料留存，不会随项目更新。
2. 列表内容由第三方维护：页面中列出的都是"其他开发者"维护的、支持 KernelSU 的非 GKI 设备内核，并非 KernelSU 官方产物。
3. 源码未经官方审查，风险自担：页面只用于帮你找到与设备匹配的源码，完全不意味着该源码经过 KernelSU 开发者审查，使用时需自行接受风险。

这三点划清了"官方支持"与"社区支持"的边界：官方支持只覆盖 GKI 内核（Linux 5.10+），而非 GKI 设备要想用上 KernelSU，只能依赖社区编译的内核或自行集成。

二、为什么会有"非官方"支持：GKI 与非 GKI 的分水岭

要理解这份清单的价值，需要先理解 GKI（Generic Kernel Image，通用内核映像）与非 GKI 的差异。官方安装文档 website/docs/guide/installation.md 中解释了核心概念KMI（Kernel Module Interface，内核模块接口）：内核版本中w.x-zzz-k这一节即为 KMI 版本，KMI 相同的内核互相兼容，KMI 不同则互不兼容，刷入 KMI 不匹配的内核映像可能直接导致无法开机。

• GKI 设备：内核版本形如5.10.101-android12-9-g30979850fc20，其 KMI 为5.10-android12-9。官方为 GKI 设备提供可直接刷写的通用 boot.img，覆盖面广。
• 非 GKI 设备：内核碎片化严重（不同厂商、不同平台、不同内核版本各自为政），官方无法提供统一的非 GKI boot.img，只能由社区按设备逐个适配。

FAQ（website/docs/guide/faq.md）进一步说明：官方支持的设备需要满足"出厂即 Android 12 + GKI 5.10 内核"；而旧内核（如 4.14）属于"可支持但需自行编译"的范畴。官方文档 website/docs/guide/how-to-integrate-for-non-gki.md 中明确：KernelSU 1.0 及以后版本不再支持非 GKI 内核，最后一个支持的版本是 v0.9.5——这也是为什么这份设备清单标注为"不再维护"。

三、清单的工作机制：一份 JSON 驱动的动态表格

页面的表格并非手工维护的静态 HTML，而是通过 Vue 的<script setup>从仓库内的数据文件动态渲染：

<script setup> import data from '../../repos.json' </script> <table> <thead> <tr> <th>维护者</th> <th>仓库地址</th> <th>支持设备</th> </tr> </thead> <tbody> <tr v-for="repo in data" :key="repo.devices"> <td><a :href="repo.maintainer_link" ...>{{ repo.maintainer }}</a></td> <td><a :href="repo.kernel_link" ...>{{ repo.kernel_name }}</a></td> <td>{{ repo.devices }}</td> </tr> </tbody> </table>

数据源为 website/docs/repos.json，每一条记录含四个字段：

该文件目前共收录106 条内核记录。若你想为文档页补充或核对数据，只需编辑这一个 JSON 文件，页面表格会自动刷新。

四、如何使用清单：按设备代号精准定位内核源码

表格第三列是定位设备的关键。Android 社区习惯用设备代号（codename）指代机型，例如：

• alioth= Redmi K40 / POCO F3 / Mi 11X
• munch= Redmi K40S / POCO F4
• raphael= Xiaomi Redmi K20 Pro / Mi 9T Pro
• ginkgo/willow= Redmi Note 8 / 8T
• avicii= OnePlus Nord

使用步骤：先在手机设置中确认机型与内核版本 → 在表格第三列中搜索你的机型或代号 → 找到匹配项后，通过第二列的kernel_link进入内核源码仓库 → 按仓库 README 说明编译刷入。注意，同型号设备可能有多个维护者的内核（如 raphael 有 5 个以上版本、alioth 有 3 个），它们的差异通常体现在内核版本基线（Linux 4.x/4.19）、适配的 ROM（MIUI / AOSP / LineageOS）与附加特性上，需按自己当前 ROM 环境选择。

五、完整清单：106 条社区内核速查表

以下为 website/docs/repos.json 中收录的完整条目（维护者 / 内核仓库名 / 支持设备），便于直接检索：

六、生态概览：设备与平台的分布规律

对 website/docs/repos.json 的 106 条记录做统计，可以清晰看出这份社区清单的生态特征：

• 高通的骁龙平台是绝对主力：仅sm8250（骁龙 865 系，8 条）、msm8998（骁龙 835 系，6 条）、sdm845（骁龙 845 系，5 条）、sm8150（骁龙 855 系，4 条）就占去近四分之一，另有sm8350、sm6150、sdm660、sdm710、sm6250、sm7250、sm7325、sm7125等多个平台。
• 机型高度集中于小米/POCO 生态：alioth、munch、raphael、ginkgo、apollo 等热销机型往往同时有 3～5 个不同维护者的内核，竞争充分、选择丰富。
• 三星是第二大阵营：覆盖 Exynos 9610/9810/9820、Exynos 1380、以及骁龙平台的 A5x/M5x/S10 系列等。
• 老内核版本大量存在：多条记录明确标注 Linux 4.4.302、4.9、4.14、4.19 等基线，印证了 KernelSU 曾被移植到 4.14 及更早版本的历史（见 website/docs/guide/faq.md）。
• 特殊平台亦有覆盖：包括 Android-x86 的通用 x86_64 内核（Darkmatter-kernel）、Pixel 2/2XL（wahoo）、Pixel 3a（msm-4.9）、Pixel 4 XL（coral）等。

七、风险与安全措施：使用社区内核前必须做的事

文档第三条警告强调：清单中的源码未经过 KernelSU 开发者审查，属于"用得好不好全看维护者，出了事自己兜着"的社区资源。结合官方安装指南（website/docs/guide/installation.md），使用这些社区内核时应遵守以下安全底线：

1. 刷入前备份原厂 boot.img：这是官方反复强调的第一步。一旦出现 bootloop，可通过 fastboot 刷回原厂 boot 恢复系统；刷机操作可能造成数据丢失，必要时先完整备份设备数据。
2. 核对内核版本而非 Android 版本：KernelSU 的兼容性取决于内核版本而非系统版本。设备升级 Android 后内核版本一般不会变，刷机前务必以内核版本为准（详见安装文档的 "Kernel version vs Android version" 一节）。
3. 优先选择匹配当前 ROM 的内核：多条记录注明仅适配 LineageOS / PixelExperience / MIUI / AOSP 等特定 ROM 环境（如 zlm324 的 msm8998 内核注明 "for LineageOS"），跨 ROM 使用可能无法正常开机。
4. 了解 KMI 与安全补丁级别约束：非 GKI 内核同样存在防回滚机制，旧安全补丁级别的内核映像可能触发 bootloop，应尽量选择安全补丁级别较新的内核。
5. 警惕引导循环的排查方法：若集成后卡 bootloop，官方集成指南给出一个判别手段——注释掉ksu_sucompat_init()与ksu_ksud_init()后若能正常开机，则问题很可能出在内核的 kprobe 上。

八、从"用别人编译的内核"到"自己集成"：非 GKI 的两种接入方式

如果清单里找不到你的设备，或你希望自己维护内核，官方保留了完整的非 GKI 集成指南（website/docs/guide/how-to-integrate-for-non-gki.md），这是理解"社区内核是怎么做出来的"的关键资料。前提是：你的内核源码开源，且你能从源码编译出可开机的内核。在此基础上有两种方式：

方式一：基于 kprobe 的自动集成（推荐）

KernelSU 的钩子机制依赖 kprobe。如果目标内核的 kprobe 稳定可用，这是最省事的方式。流程如下：

1. 将 KernelSU 拉入内核源码树（注意非 GKI 只支持到 v0.9.5）：

curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5

2. 确认内核配置已开启 kprobe，否则补充：

CONFIG_KPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_KPROBE_EVENTS=y

3. 重新编译内核。若 KPROBES 仍无法启用，可尝试开启CONFIG_MODULES，或用make menuconfig排查其他依赖。

需要说明的是，仓库内的 kernel/setup.sh 是面向 GKI 源码树的集成脚本：它会把KernelSU/kernel以符号链接方式挂到内核的drivers/kernelsu，并向drivers/Makefile追加obj-$(CONFIG_KSU) += kernelsu/、向drivers/Kconfig注入source "drivers/kernelsu/Kconfig"。非 GKI 场景下（v0.9.5 时代）原理相同，脚本内drivers/与common/drivers/的目录探测逻辑恰好兼容两类源码树布局。从源码结构看，这也解释了为什么社区内核仓库普遍保留了drivers/kernelsu软链接这一集成痕迹。

方式二：手动修改内核源码

当 kprobe 因上游缺陷失效、或内核版本低于 4.8 时，需要手动打补丁。核心步骤是：

1. 在 defconfig 中启用 KernelSU（注意 defconfig 可能位于arch/arm64/configs或其 vendor 子目录）：

# KernelSU CONFIG_KSU=y

2. 在四处系统调用路径插入 KernelSU 钩子调用（官方指南提供了可直接套用的 diff 补丁）：

   • do_faccessat，通常位于fs/open.c→ 对应ksu_handle_faccessat
   • do_execveat_common，通常位于fs/exec.c→ 对应ksu_handle_execveat/ksu_handle_execveat_sucompat
   • vfs_read，通常位于fs/read_write.c→ 对应ksu_handle_vfs_read
   • vfs_statx（或更老内核的vfs_fstatat），通常位于fs/stat.c→ 对应ksu_handle_stat

3. 建议同时接入内置安全模式（Safe Mode）：修改drivers/input/input.c的input_handle_event，加入ksu_handle_input_handle_event调用，以便在集成异常时通过按键进入安全模式自救。若手动集成且未禁用CONFIG_KPROBES，用户可能在开机时误触安全模式，因此手动集成时务必关闭CONFIG_KPROBES。

4. 若终端中pm命令执行失败，需修改fs/devpts/inode.c的devpts_get_priv加入ksu_handle_devpts调用；若内核早于 5.9 且需要"卸载模块"功能，还需把 5.9 的path_umount回移（backport）到fs/namespace.c。

仓库内 kernel/Kconfig 中CONFIG_KSU的定义印证了这套机制的依赖关系：它声明depends on KPROBES && EXT4_FS，帮助文本明确指出"在内核层面为 Android 系统提供 root 权限，需要 CONFIG_KPROBES 支持内核钩子，需要 CONFIG_EXT4_FS 支持ext4_unregister_sysfs"，且支持y（编入内核）与M（编译为名为kernelsu的模块）两种形态——后者正是 GKI 场景下 LKM 模式的来源。此外还提供KSU_DEBUG、KSU_DISABLE_MANAGER、KSU_DISABLE_POLICY、KSU_X86_PATCH_SYSCALL_DISPATCHER等可选项，说明非 GKI 内核同样可以按需裁剪 KernelSU 功能面。

九、如何确认你的设备是否被官方支持

在动手折腾社区内核之前，建议先用官方管理器确认设备状态（详见 website/docs/guide/installation.md）：

• 管理器显示Not installed：设备受 KernelSU 官方支持，直接使用官方 boot.img 或 LKM 即可。
• 管理器显示Unsupported：设备不在官方支持范围，此时有两个出路——要么查阅本文介绍的社区内核清单直接使用现成内核，要么按照官方非 GKI 集成指南自行编译内核。

总结

「非官方支持设备」清单是 KernelSU 在 v1.0 放弃非 GKI 官方支持之前，社区生态的忠实留档：它以 website/docs/repos.json 为数据源，用动态表格记录了 106 个由第三方维护的 KernelSU 内核，覆盖小米/POCO、三星、一加、Pixel、索尼、华为、诺基亚、LG、摩托罗拉、Realme、OPPO、华硕等多个品牌与高通的骁龙、联发科、三星 Exynos 等平台。使用这份清单时，请始终牢记三条警告——仅供存档、非官方维护、未经审查、风险自担；在刷入任何社区内核前备份原厂 boot 映像，并优先选择与自身 ROM 环境匹配、内核基线相近的版本。若清单中没有你的设备，非 GKI 集成指南 中基于 kprobe 与手动补丁的两条路径，可以让你亲手把 KernelSU 带进任何一款内核源码开放的设备。

【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU