企业官网建设流程全解析

旧内核也能刷 KernelSU：4.14–5.3 设备从判断到开机的 5 步手动适配

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

用了五六年、还跑着 Linux 4.19 的老旗舰，装上 KernelSU 管理器第一屏就提示"不支持"。其实只要这块旧内核的版本在 4.14 及以上、内核源码是开放的，这台设备完全可以手动适配。下面是具体走法。

🔎 先判断：你的设备要不要自己编译内核

结论先行：内核版本决定路线，GKI 设备根本不用碰源码。

先跑一条命令拿内核版本号：

adb shell uname -r # 输出示例：4.19.191-android11-8-gb2f41e6

再对照管理器的支持提示，你属于三种情况之一：

• GKI 内核（5.4 / 5.10 / 6.x）：管理器直接可用，刷官方预编译 boot 就行，后面这些内容你可以关掉了。
• 4.14–5.3 且内核源码开放：手动适配的目标人群。路线只有两条——kprobe 自动集成，或者手改内核源码；kprobe 能用就走第一条，不能用才动刀。
• 源码不开放 / 编译不出能开机的 boot / 版本低于 4.14：不建议折腾。以下全部内容属于非官方支持，风险自担。

还有一个硬事实要记住：KernelSU 自 v1.0 起放弃非 GKI 支持，最后一个支持旧内核的 tag 是v0.9.5，后面所有操作都用这个版本。

🧠 原理 30 秒：KernelSU 为什么非要改内核

KernelSU 运行在内核层，权限判定和隐藏逻辑必须在系统调用返回用户空间之前生效，所以它必须存在于内核里。GKI 内核上它以可加载模块身份挂入，靠 kprobe 动态 hook 目标函数；而很多 4.x 老内核的 kprobe 机制本身是坏的，模块一挂就死机。这就是适配时的分叉点：要么验证 kprobe 能不能用，要么手动在 4 个系统调用入口处各插一句 hook 调用——exec、access 检查、read、stat 四条路，正好覆盖 su 和隐藏逻辑的全部路径。

🛠️ 适配时间线：从源码到刷 boot 的 5 步

1. 准备源码：先确认能编出能开机的 boot

用你设备对应的内核源码（厂商源码优先）。在集成任何东西之前，先按原厂流程编出一张能正常开机的 boot 镜像；如果连这一步都做不到，说明内核闭源或工具链不全，直接停手，别往下走。

2. 集成 KernelSU 源码

先克隆仓库并切到 v0.9.5 这个 tag：

git clone https://gitcode.com/GitHub_Trending/ke/KernelSU cd KernelSU && git checkout v0.9.5

然后把 KernelSU 目录放在内核源码树的同级位置，在内核根目录执行下面三行。它们等价于kernel/setup.sh做的事：把内核代码挂进drivers/，再登记到构建系统里。

ln -s ../KernelSU/kernel drivers/kernelsu echo 'obj-$(CONFIG_KSU) += kernelsu/' >> drivers/Makefile sed -i '/endmenu/i source "drivers/kernelsu/Kconfig"' drivers/Kconfig

构建系统只多了两行登记，万一出问题，把这三处直接还原即可，改动面很小。

3. 打开 Kconfig 配置

在你的设备 defconfig 里追加以下内容，位置通常在arch/arm64/configs/设备代号_defconfig，也可能是arch/arm64/configs/vendor/设备代号_defconfig：

CONFIG_KSU=y CONFIG_KPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_KPROBE_EVENTS=y

如果你判断 kprobe 大概率是坏的、准备一上来就走手改源码路线，就把CONFIG_KPROBES直接设为n，原因见后面的踩坑清单第 2 条。

4. 选钩子路线：kprobe 优先，手改兜底

路线 A（推荐）：kprobe 在你内核里能正常工作，就到此为止，直接编译，KernelSU 运行时自己完成 hook，不改任何其他源码。

路线 B：刷入后开不了机，优先怀疑 kprobe 失效。改用手改：在 4 个函数入口各加一次 hook 调用。最核心的fs/exec.c中do_execveat_common长这样：

static int do_execveat_common(int fd, struct filename *filename, struct user_arg_ptr argv, struct user_arg_ptr envp, int flags) { #ifdef CONFIG_KSU if (unlikely(ksu_execveat_hook)) ksu_handle_execveat(&fd, &filename, &argv, &envp, &flags); else ksu_handle_execveat_sucompat(&fd, &filename, &argv, &envp, &flags); #endif return __do_execve_file(fd, filename, argv, envp, flags, NULL); }

其余三处是同样的模式：在函数入口前加对应的extern声明，再插一行调用。分别是fs/open.c的do_faccessat（4.17 以下的老内核没有这个函数，直接改SYSCALL_DEFINE3(faccessat, ...)定义处）、fs/read_write.c的vfs_read、fs/stat.c的vfs_statx（没有 statx 就用vfs_fstatat顶替）。想保留安全模式，还要在drivers/input/input.c的input_handle_event里加一个输入 hook，这一步强烈建议做，救砖时靠它进安全模式。

5. 编译并用 fastboot 验证开机

先确认配置真的生效，再编译（命令以你设备厂商的构建方式为准，这里给 arm64 通用示例）：

grep -E '^CONFIG_KSU=' .config # 应输出 CONFIG_KSU=y make -j$(nproc)

在永久写入之前，务必用 fastboot 临时启动来验证——这一步不写设备，重启就回到原内核，把风险全部消化在这里：

fastboot boot boot-ksu.img adb shell su -c id # 输出 uid=0(root) 即成功

连续正常开机 5 次以上，再做永久刷写。

⚠️ 适配踩坑：四种几乎必碰的情况

1. 卡在 logo 开不了机原因：这个内核里 kprobe 工作不正常，模块挂入即死机。 处理：fastboot flash boot刷回备份恢复，把CONFIG_KPROBES改为n，改走路线 B 手改源码。

2. 莫名其妙进了安全模式，su 和模块全没了原因：手改源码集成，但CONFIG_KPROBES没关，kprobe 的输入 hook 残留，开机时按音量下就触发了安全模式。 处理：关闭CONFIG_KPROBES重新编译。

3. 开机正常但pm命令执行失败原因：devpts 路径没有被 hook。 处理：在fs/devpts/inode.c的devpts_get_priv函数开头加一行ksu_handle_devpts(dentry->d_inode);，并在函数前声明extern int ksu_handle_devpts(struct inode *);。

4. 编译报vfs_statx或do_faccessat未定义原因：内核太老，这两个函数还没从老函数里拆出来。 处理：stat 用vfs_fstatat顶替，access 直接挂在faccessat系统调用定义上，改法见时间线第 4 步。

📦 收尾：必须记住的四件事

• 在动任何东西之前，先备份原始 boot，管理器内置备份或fastboot flash boot 备份镜像.img随时能刷回。
• 永久刷写之前，务必先用fastboot boot临时启动验证，正常开机 5 次再写入。
• 整个流程是非官方支持，风险自担；卡住先对照非 GKI 内核集成文档（文档已标注存档、不再更新），完全开不了机时看bootloop 救援指南。
• 旧内核只认 v0.9.5，别拿 1.x 的 tag 往下走，编译都过不了。

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