KernelSU 构建指南从 GKI 内核源码同步、编译到集成 KernelSU 的完整流程【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是一个运行在 Linux 内核态、直接在内核空间向用户态应用授予 root 权限的 Android 根解决方案。本篇技术指南以仓库中归档的《KernelSU のビルド方法は》website/docs/ja_JP/guide/how-to-build.md为骨架系统讲解 GKI 内核源码的同步、构建以及如何通过setup.sh将 KernelSU 集成进内核镜像同时结合当前仓库的 kernel/setup.sh、kernel/Kbuild、kernel/Kconfig 等源码深入说明脚本的底层行为与内核侧构建系统的组织方式。读完本文你将掌握一条完整的源码级集成 KernelSU实战路径并能理解 v3.0 之后 GKI 镜像模式与 LKM 模式之间的演进关系。文档定位与版本背景GKI 镜像模式已归档在开始动手之前必须明确一点本文所依据的这份文档在仓库中已被标记为仅供归档参考不再维护。原文档开头的 warning 明确指出KernelSU v3.0 之后为了更快的迭代与构建速度官方终止了对GKI 镜像模式GKI image mode的支持并推荐使用Ylarod/ddk构建LKMLoadable Kernel Module。因此本文第一部分GKI 镜像模式的完整构建流程代表的是 KernelSU 在 v3.0 之前的官方构建方式如今的价值在于理解 KernelSU 与 GKI 内核的集成原理、为历史版本如 v0.5.x提供构建参考以及为阅读后续 LKM 构建方式提供背景知识。当前官方推荐的构建路径已在仓库中有迹可循例如 scripts/prepare-ddk-x64.sh 正是为 x86_64 平台准备 ddk 内核构建环境的脚本这会在后文展开。此外原文档还提醒本文面向 GKI 设备。如果你使用的是旧内核非 GKI应参考仓库中的非 GKI 集成文档 website/docs/ja_JP/guide/how-to-integrate-for-non-gki.md该文档同样已归档说明 KernelSU v1.0 起终止了非 GKI 设备的官方支持。构建前的准备先读 Android 官方内核构建文档原文档在正文之前强调构建前应先阅读 Android 官方的两份关键文档Build kernels内核构建总览覆盖内核源码同步、交叉编译工具链、构建脚本等基础概念GKI release buildsGKI 发布构建介绍 GKI 内核的发布形式并提供了用于可复现构建的 manifest 清单文件。这两份文档是理解下文所有命令的前提尤其是 manifest 的获取方式——它直接决定了你构建出的内核版本与配置。第一步同步内核源码构建内核的第一步是从 AOSP 内核仓库同步源码使用repo工具完成。原文档给出的完整流程如下repo init -u https://android.googlesource.com/kernel/manifest mv kernel_manifest.xml .repo/manifests repo init -m manifest.xml repo sync其中kernel_manifest.xml是唯一确定一次构建的 manifest 文件它精确锁定了各内核仓库如common、common-modules等的提交版本从而保证构建可复现。该文件需要从 Google 的GKI release builds页面下载——每个 GKI 发布版本都对应一份专属 manifest。需要特别说明的是manifest 一经选定之后每次构建都会基于同一组源码提交这是后续排错与复现构建的基础。如果你希望跟随最新主线也可以不指定 manifest 直接repo sync但那样就失去了可复现性。第二步构建内核源码同步完成后先按官方文档确认构建环境交叉编译工具链、依赖等然后开始构建。以构建aarch64内核镜像为例原文档给出的命令是LTOthin BUILD_CONFIGcommon/build.config.gki.aarch64 build/build.sh关键点是不要遗漏LTOthin标志如果省略当你的电脑内存不足 24 GB 时构建很可能会失败。LTOLink Time Optimization默认采用全量链接优化会显著拉高编译期的内存峰值thin模式将 LTO 拆分为并行的轻量子任务内存占用大幅下降代价是优化程度略低但对 Android GKI 内核的日常构建完全足够。从Android 13开始内核构建方式迁移到了bazel命令变为tools/bazel build --configfast //common:kernel_aarch64_dist该命令产出kernel_aarch64_dist目标即 aarch64 内核的 dist 发布包--configfast对应快速构建配置。这是 Android 内核构建体系从build.sh向 Bazel 迁移的过渡产物在 Android 13 的 GKI 内核树中两者并存。补充说明来自英文版同源文档对于部分 Android 14 内核为了让 Wi-Fi / Bluetooth 正常工作可能需要移除全部 GKI 保护导出符号rm common/android/abi_gki_protected_exports_*这一步视具体内核版本与驱动需求而定仅在遇到无线功能异常时考虑。构建成功后你会得到一份干净的、可启动的 GKI 内核镜像这是下一步集成 KernelSU 的前提。第三步将 KernelSU 集成进内核并重建如果内核已经可以成功构建那么加入 KernelSU 就非常简单了。在内核源码树的根目录下任选下列三种方式之一执行原文档以 code-group 形式给出# 方式一最新发布标签稳定版 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash - # 方式二main 分支开发版 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s main # 方式三指定标签例如 v0.5.2 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s v0.5.2三种方式的差异在于传给setup.sh的参数参数含义适用场景无参数检出最新发布标签git describe --abbrev0 --tags追求稳定日常使用main检出 main 分支体验最新开发特性可能不稳定v0.5.2等具体标签/提交检出指定标签或提交复现特定版本行为执行完成后重新构建内核即重复第二步的命令即可得到内嵌 KernelSU 的内核镜像。整条链路可以概括为同步源码 → 构建内核 → 注入 KernelSU 代码 → 再次构建。需要注意的是该curl | bash方式拉取的是 GitHub 上的kernel/setup.sh在本地仓库中这份脚本同样存在即 kernel/setup.sh可以直接阅读或离线使用两者行为一致。深入源码setup.sh 到底做了什么理解了用法之后我们结合仓库中的 kernel/setup.sh 看看这条命令的内部逻辑。脚本的核心流程分为三个部分1. 定位驱动目录initialize_variables脚本基于当前目录即内核源码根目录自动探测drivers目录的位置——优先使用common/driversGKI 内核树常见布局否则回退到根目录下的drivers两者都不存在则报错退出if test -d $GKI_ROOT/common/drivers; then DRIVER_DIR$GKI_ROOT/common/drivers elif test -d $GKI_ROOT/drivers; then DRIVER_DIR$GKI_ROOT/drivers else echo [ERROR] drivers/ directory not found. exit 127 fi2. 注入 KernelSUsetup_kernelsu若内核源码树中没有KernelSU目录则git cloneKernelSU 仓库进入KernelSU目录后先git stash本地改动、切回main并git pull确保拿到最新代码按参数检出最新标签或指定标签/分支无参数时检出git describe --abbrev0 --tags得到的最新标签在内核drivers目录下创建指向KernelSU/kernel的符号链接kernelsuln -sf $(realpath --relative-to$DRIVER_DIR $GKI_ROOT/KernelSU/kernel) kernelsu向drivers/Makefile追加一行obj-$(CONFIG_KSU) kernelsu/把 KernelSU 纳入内核驱动编译体系向drivers/Kconfig的endmenu之前插入source drivers/kernelsu/Kconfig将 KernelSU 的配置项暴露给内核配置系统。3. 清理回滚perform_cleanup脚本还内置了--cleanup参数用于还原上述全部修改删除符号链接、从Makefile/Kconfig中移除 KernelSU 相关行、删除克隆的KernelSU目录。这在调试或切换内核版本时非常实用curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s -- --cleanup从源码可以看到setup.sh的本质是把 KernelSU 当作一个内核驱动注入到构建树中这也是为什么它在 GKI 镜像模式和后来的 LKM 模式中都适用——区别只在于最终编译成内置镜像还是独立.ko模块。内核侧构建系统Kbuild 与 Kconfig注入完成后KernelSU 的内核代码通过 kernel/Kbuild 组织编译。该文件清晰地展示了 KernelSU 的模块化构成core/init.o作为入口随后依次编译feature/如kernel_umount、sucompat、sulog、adb_root、selinux_hide、hook/LSM hook、setuid hook、系统调用 hook且按CONFIG_ARM64/CONFIG_X86_64分别选择架构相关实现、infra/事件队列、seccomp 缓存、su 挂载命名空间、符号解析、policy/allowlist、app_profile、feature、selinux/、sulog/、supercall/等子系统最终由obj-$(CONFIG_KSU) kernelsu.o汇总。值得关注的两个细节KSU_VERSION 的自动计算若 KernelSU 目录是独立 git 仓库Kbuild会通过git rev-list --count HEAD统计提交数并计算KSU_VERSION 30000 git 提交数源码注释说明历史上加 200通过-DKSU_VERSION传给编译器否则回退到默认值16。这也解释了文档中建议让 KernelSU 保持为 git 仓库的原因——版本号信息依赖 git 历史。Manager 签名校验Kbuild中定义了KSU_EXPECTED_SIZE与KSU_EXPECTED_HASH可被KSU_EXPECTED_SIZE2/KSU_EXPECTED_HASH2扩展用于在构建期固定 KernelSU Manager 应用签名防止管理器被替换。KernelSU 的可用配置项定义在 kernel/Kconfig核心选项如下配置项类型/默认值说明CONFIG_KSUtristate默认y总开关依赖KPROBES与EXT4_FS选M时以kernelsu模块形式编译CONFIG_KSU_DEBUGbool默认n开启 KernelSU 调试模式CONFIG_KSU_DISABLE_MANAGERbool默认n禁用 Manager 应用检测与专属处理仅保留纯 root 能力CONFIG_KSU_DISABLE_POLICYbool默认n禁用按应用定制的 root/非 root 配置文件提权一律使用默认完整 root 配置CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHERbool默认n在 x86_64 上动态修补加固的系统调用分发器以支持 syscall hook是 x86_64 LKM 模式下替代内核源码补丁的方案在 GKI 镜像模式即本文主流程下这些选项通过 defconfig 或make menuconfig配置后随内核一并编译进镜像而在 LKM 模式下它们通过KBUILD_EXTMOD分支中的ccflags-y以宏形式生效见 kernel/Kbuild 第 54-67 行。从镜像模式到 LKMv3.0 之后的推荐构建路径正如文档归档警告所述KernelSU v3.0 起放弃了 GKI 镜像模式转而推荐用Ylarod/ddk构建 LKM。这一演进在当前仓库中同样有迹可循kernel/Makefile 提供了独立的 LKM 构建入口make -C $(KDIR) M$(ODIR) modules编译出kernelsu.ko随后用./check_symbol源码在 kernel/tools/check_symbol.c校验模块所需符号在vmlinux中是否存在。注意它对不同 KMI 版本如android17-6.18与更早版本采用了不同的M/MO参数形式。scripts/prepare-ddk-x64.sh 为 x86_64 平台的 ddk 构建环境做了完整准备覆盖从android12-5.10到android17-6.18共 8 个 KMI 版本为每个版本选定匹配的 clang如clang-r584948c与 Rust 工具链rust-1.82.0/rust-1.91.1.p36.12 及之后内核需要 Rust 支持并生成对应的gki_defconfig、禁用 LTO、执行modules_prepare与 SELinux 头文件生成等步骤。用户态配套的ksud守护进程Rust 实现见 userspace/ksud/Cargo.toml负责模块加载后的用户态管理与内核侧 kernel/runtime/ksud_integration.c 协同工作。LKM 模式的优势正如文档所述迭代更快无需整体重编内核镜像、构建更快只编译一个模块并且通过CONFIG_KSU选M即可直接复用本仓库的kernel/代码。对于仍在维护 GKI 镜像模式旧版本的读者本文前半部分的流程依然完全适用。验证构建结果无论采用哪种模式构建完成后都应做基本验证镜像模式下检查生成的内核镜像中是否包含CONFIG_KSUy的配置痕迹可通过/proc/config.gz或zcat /proc/config.gz | grep KSU在设备端确认并观察启动日志中 KernelSU 的初始化输出LKM 模式下确认生成了kernelsu.ko且check_symbol校验通过该工具会比对模块与内核vmlinux的符号表任何缺失符号都会导致模块无法加载版本号核对Kbuild在编译时会打印-- KernelSU version: xxx可用其与预期版本比对功能冒烟安装 KernelSU Manager 应用后验证授权管理、su 兼容层sucompat与 SELinux 规则是否按预期生效。如果集成后遇到问题可参考仓库中的排障文档 website/docs/ja_JP/guide/rescue-from-bootloop.md以及安装文档 website/docs/ja_JP/guide/installation.md。小结本文完整复现了 KernelSU 官方构建指南的核心流程通过repo同步 GKI 内核源码 → 以LTOthin或 Bazel 构建基础内核 → 用setup.sh注入 KernelSU 并重建。同时结合仓库源码揭示了setup.sh的注入机制符号链接 Makefile/Kconfig 改写、Kbuild/Kconfig的模块化组织与配置项语义并解释了 v3.0 之后 GKI 镜像模式归档、LKM/ddk 成为主流的原因。需要再次强调的是GKI 镜像模式路径已归档新项目应优先评估Ylarod/ddk的 LKM 构建路线仓库内 scripts/prepare-ddk-x64.sh 与 kernel/Makefile 可作为参考实现本文的镜像模式流程则用于理解原理与维护旧版本。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KernelSU 构建指南：从 GKI 内核源码同步、编译到集成 KernelSU 的完整流程
KernelSU 构建指南从 GKI 内核源码同步、编译到集成 KernelSU 的完整流程【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是一个运行在 Linux 内核态、直接在内核空间向用户态应用授予 root 权限的 Android 根解决方案。本篇技术指南以仓库中归档的《KernelSU のビルド方法は》website/docs/ja_JP/guide/how-to-build.md为骨架系统讲解 GKI 内核源码的同步、构建以及如何通过setup.sh将 KernelSU 集成进内核镜像同时结合当前仓库的 kernel/setup.sh、kernel/Kbuild、kernel/Kconfig 等源码深入说明脚本的底层行为与内核侧构建系统的组织方式。读完本文你将掌握一条完整的源码级集成 KernelSU实战路径并能理解 v3.0 之后 GKI 镜像模式与 LKM 模式之间的演进关系。文档定位与版本背景GKI 镜像模式已归档在开始动手之前必须明确一点本文所依据的这份文档在仓库中已被标记为仅供归档参考不再维护。原文档开头的 warning 明确指出KernelSU v3.0 之后为了更快的迭代与构建速度官方终止了对GKI 镜像模式GKI image mode的支持并推荐使用Ylarod/ddk构建LKMLoadable Kernel Module。因此本文第一部分GKI 镜像模式的完整构建流程代表的是 KernelSU 在 v3.0 之前的官方构建方式如今的价值在于理解 KernelSU 与 GKI 内核的集成原理、为历史版本如 v0.5.x提供构建参考以及为阅读后续 LKM 构建方式提供背景知识。当前官方推荐的构建路径已在仓库中有迹可循例如 scripts/prepare-ddk-x64.sh 正是为 x86_64 平台准备 ddk 内核构建环境的脚本这会在后文展开。此外原文档还提醒本文面向 GKI 设备。如果你使用的是旧内核非 GKI应参考仓库中的非 GKI 集成文档 website/docs/ja_JP/guide/how-to-integrate-for-non-gki.md该文档同样已归档说明 KernelSU v1.0 起终止了非 GKI 设备的官方支持。构建前的准备先读 Android 官方内核构建文档原文档在正文之前强调构建前应先阅读 Android 官方的两份关键文档Build kernels内核构建总览覆盖内核源码同步、交叉编译工具链、构建脚本等基础概念GKI release buildsGKI 发布构建介绍 GKI 内核的发布形式并提供了用于可复现构建的 manifest 清单文件。这两份文档是理解下文所有命令的前提尤其是 manifest 的获取方式——它直接决定了你构建出的内核版本与配置。第一步同步内核源码构建内核的第一步是从 AOSP 内核仓库同步源码使用repo工具完成。原文档给出的完整流程如下repo init -u https://android.googlesource.com/kernel/manifest mv kernel_manifest.xml .repo/manifests repo init -m manifest.xml repo sync其中kernel_manifest.xml是唯一确定一次构建的 manifest 文件它精确锁定了各内核仓库如common、common-modules等的提交版本从而保证构建可复现。该文件需要从 Google 的GKI release builds页面下载——每个 GKI 发布版本都对应一份专属 manifest。需要特别说明的是manifest 一经选定之后每次构建都会基于同一组源码提交这是后续排错与复现构建的基础。如果你希望跟随最新主线也可以不指定 manifest 直接repo sync但那样就失去了可复现性。第二步构建内核源码同步完成后先按官方文档确认构建环境交叉编译工具链、依赖等然后开始构建。以构建aarch64内核镜像为例原文档给出的命令是LTOthin BUILD_CONFIGcommon/build.config.gki.aarch64 build/build.sh关键点是不要遗漏LTOthin标志如果省略当你的电脑内存不足 24 GB 时构建很可能会失败。LTOLink Time Optimization默认采用全量链接优化会显著拉高编译期的内存峰值thin模式将 LTO 拆分为并行的轻量子任务内存占用大幅下降代价是优化程度略低但对 Android GKI 内核的日常构建完全足够。从Android 13开始内核构建方式迁移到了bazel命令变为tools/bazel build --configfast //common:kernel_aarch64_dist该命令产出kernel_aarch64_dist目标即 aarch64 内核的 dist 发布包--configfast对应快速构建配置。这是 Android 内核构建体系从build.sh向 Bazel 迁移的过渡产物在 Android 13 的 GKI 内核树中两者并存。补充说明来自英文版同源文档对于部分 Android 14 内核为了让 Wi-Fi / Bluetooth 正常工作可能需要移除全部 GKI 保护导出符号rm common/android/abi_gki_protected_exports_*这一步视具体内核版本与驱动需求而定仅在遇到无线功能异常时考虑。构建成功后你会得到一份干净的、可启动的 GKI 内核镜像这是下一步集成 KernelSU 的前提。第三步将 KernelSU 集成进内核并重建如果内核已经可以成功构建那么加入 KernelSU 就非常简单了。在内核源码树的根目录下任选下列三种方式之一执行原文档以 code-group 形式给出# 方式一最新发布标签稳定版 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash - # 方式二main 分支开发版 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s main # 方式三指定标签例如 v0.5.2 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s v0.5.2三种方式的差异在于传给setup.sh的参数参数含义适用场景无参数检出最新发布标签git describe --abbrev0 --tags追求稳定日常使用main检出 main 分支体验最新开发特性可能不稳定v0.5.2等具体标签/提交检出指定标签或提交复现特定版本行为执行完成后重新构建内核即重复第二步的命令即可得到内嵌 KernelSU 的内核镜像。整条链路可以概括为同步源码 → 构建内核 → 注入 KernelSU 代码 → 再次构建。需要注意的是该curl | bash方式拉取的是 GitHub 上的kernel/setup.sh在本地仓库中这份脚本同样存在即 kernel/setup.sh可以直接阅读或离线使用两者行为一致。深入源码setup.sh 到底做了什么理解了用法之后我们结合仓库中的 kernel/setup.sh 看看这条命令的内部逻辑。脚本的核心流程分为三个部分1. 定位驱动目录initialize_variables脚本基于当前目录即内核源码根目录自动探测drivers目录的位置——优先使用common/driversGKI 内核树常见布局否则回退到根目录下的drivers两者都不存在则报错退出if test -d $GKI_ROOT/common/drivers; then DRIVER_DIR$GKI_ROOT/common/drivers elif test -d $GKI_ROOT/drivers; then DRIVER_DIR$GKI_ROOT/drivers else echo [ERROR] drivers/ directory not found. exit 127 fi2. 注入 KernelSUsetup_kernelsu若内核源码树中没有KernelSU目录则git cloneKernelSU 仓库进入KernelSU目录后先git stash本地改动、切回main并git pull确保拿到最新代码按参数检出最新标签或指定标签/分支无参数时检出git describe --abbrev0 --tags得到的最新标签在内核drivers目录下创建指向KernelSU/kernel的符号链接kernelsuln -sf $(realpath --relative-to$DRIVER_DIR $GKI_ROOT/KernelSU/kernel) kernelsu向drivers/Makefile追加一行obj-$(CONFIG_KSU) kernelsu/把 KernelSU 纳入内核驱动编译体系向drivers/Kconfig的endmenu之前插入source drivers/kernelsu/Kconfig将 KernelSU 的配置项暴露给内核配置系统。3. 清理回滚perform_cleanup脚本还内置了--cleanup参数用于还原上述全部修改删除符号链接、从Makefile/Kconfig中移除 KernelSU 相关行、删除克隆的KernelSU目录。这在调试或切换内核版本时非常实用curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s -- --cleanup从源码可以看到setup.sh的本质是把 KernelSU 当作一个内核驱动注入到构建树中这也是为什么它在 GKI 镜像模式和后来的 LKM 模式中都适用——区别只在于最终编译成内置镜像还是独立.ko模块。内核侧构建系统Kbuild 与 Kconfig注入完成后KernelSU 的内核代码通过 kernel/Kbuild 组织编译。该文件清晰地展示了 KernelSU 的模块化构成core/init.o作为入口随后依次编译feature/如kernel_umount、sucompat、sulog、adb_root、selinux_hide、hook/LSM hook、setuid hook、系统调用 hook且按CONFIG_ARM64/CONFIG_X86_64分别选择架构相关实现、infra/事件队列、seccomp 缓存、su 挂载命名空间、符号解析、policy/allowlist、app_profile、feature、selinux/、sulog/、supercall/等子系统最终由obj-$(CONFIG_KSU) kernelsu.o汇总。值得关注的两个细节KSU_VERSION 的自动计算若 KernelSU 目录是独立 git 仓库Kbuild会通过git rev-list --count HEAD统计提交数并计算KSU_VERSION 30000 git 提交数源码注释说明历史上加 200通过-DKSU_VERSION传给编译器否则回退到默认值16。这也解释了文档中建议让 KernelSU 保持为 git 仓库的原因——版本号信息依赖 git 历史。Manager 签名校验Kbuild中定义了KSU_EXPECTED_SIZE与KSU_EXPECTED_HASH可被KSU_EXPECTED_SIZE2/KSU_EXPECTED_HASH2扩展用于在构建期固定 KernelSU Manager 应用签名防止管理器被替换。KernelSU 的可用配置项定义在 kernel/Kconfig核心选项如下配置项类型/默认值说明CONFIG_KSUtristate默认y总开关依赖KPROBES与EXT4_FS选M时以kernelsu模块形式编译CONFIG_KSU_DEBUGbool默认n开启 KernelSU 调试模式CONFIG_KSU_DISABLE_MANAGERbool默认n禁用 Manager 应用检测与专属处理仅保留纯 root 能力CONFIG_KSU_DISABLE_POLICYbool默认n禁用按应用定制的 root/非 root 配置文件提权一律使用默认完整 root 配置CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHERbool默认n在 x86_64 上动态修补加固的系统调用分发器以支持 syscall hook是 x86_64 LKM 模式下替代内核源码补丁的方案在 GKI 镜像模式即本文主流程下这些选项通过 defconfig 或make menuconfig配置后随内核一并编译进镜像而在 LKM 模式下它们通过KBUILD_EXTMOD分支中的ccflags-y以宏形式生效见 kernel/Kbuild 第 54-67 行。从镜像模式到 LKMv3.0 之后的推荐构建路径正如文档归档警告所述KernelSU v3.0 起放弃了 GKI 镜像模式转而推荐用Ylarod/ddk构建 LKM。这一演进在当前仓库中同样有迹可循kernel/Makefile 提供了独立的 LKM 构建入口make -C $(KDIR) M$(ODIR) modules编译出kernelsu.ko随后用./check_symbol源码在 kernel/tools/check_symbol.c校验模块所需符号在vmlinux中是否存在。注意它对不同 KMI 版本如android17-6.18与更早版本采用了不同的M/MO参数形式。scripts/prepare-ddk-x64.sh 为 x86_64 平台的 ddk 构建环境做了完整准备覆盖从android12-5.10到android17-6.18共 8 个 KMI 版本为每个版本选定匹配的 clang如clang-r584948c与 Rust 工具链rust-1.82.0/rust-1.91.1.p36.12 及之后内核需要 Rust 支持并生成对应的gki_defconfig、禁用 LTO、执行modules_prepare与 SELinux 头文件生成等步骤。用户态配套的ksud守护进程Rust 实现见 userspace/ksud/Cargo.toml负责模块加载后的用户态管理与内核侧 kernel/runtime/ksud_integration.c 协同工作。LKM 模式的优势正如文档所述迭代更快无需整体重编内核镜像、构建更快只编译一个模块并且通过CONFIG_KSU选M即可直接复用本仓库的kernel/代码。对于仍在维护 GKI 镜像模式旧版本的读者本文前半部分的流程依然完全适用。验证构建结果无论采用哪种模式构建完成后都应做基本验证镜像模式下检查生成的内核镜像中是否包含CONFIG_KSUy的配置痕迹可通过/proc/config.gz或zcat /proc/config.gz | grep KSU在设备端确认并观察启动日志中 KernelSU 的初始化输出LKM 模式下确认生成了kernelsu.ko且check_symbol校验通过该工具会比对模块与内核vmlinux的符号表任何缺失符号都会导致模块无法加载版本号核对Kbuild在编译时会打印-- KernelSU version: xxx可用其与预期版本比对功能冒烟安装 KernelSU Manager 应用后验证授权管理、su 兼容层sucompat与 SELinux 规则是否按预期生效。如果集成后遇到问题可参考仓库中的排障文档 website/docs/ja_JP/guide/rescue-from-bootloop.md以及安装文档 website/docs/ja_JP/guide/installation.md。小结本文完整复现了 KernelSU 官方构建指南的核心流程通过repo同步 GKI 内核源码 → 以LTOthin或 Bazel 构建基础内核 → 用setup.sh注入 KernelSU 并重建。同时结合仓库源码揭示了setup.sh的注入机制符号链接 Makefile/Kconfig 改写、Kbuild/Kconfig的模块化组织与配置项语义并解释了 v3.0 之后 GKI 镜像模式归档、LKM/ddk 成为主流的原因。需要再次强调的是GKI 镜像模式路径已归档新项目应优先评估Ylarod/ddk的 LKM 构建路线仓库内 scripts/prepare-ddk-x64.sh 与 kernel/Makefile 可作为参考实现本文的镜像模式流程则用于理解原理与维护旧版本。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考