KernelSU 定制内核构建指南GKI 内核源码同步、镜像编译与 KernelSU 模块集成【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU本篇基于仓库中的官方构建文档 how-to-build.md完整讲解如何为 GKI 设备从源码同步、编译 Android 内核镜像再通过setup.sh一键集成 KernelSU 并重新构建出带 root 能力的内核。文中每一步均结合仓库内 kernel/setup.sh、kernel/Kconfig、kernel/Kbuild 的实际实现展开帮助你既能跑通构建流程也能理解构建过程中 KernelSU 究竟往内核里注入了什么。文档定位GKI 内核构建方式的存档参考原文档开头有一段明确的警告这里必须完整保留其含义该文档仅作为存档参考已不再维护。自 KernelSU v3.0 起官方已不再支持 GKI image 模式即把 KernelSU 直接编进内核镜像的模式目的是加快迭代速度并缩短构建时间。官方推荐使用Ylarod/ddk以 LKM可加载内核模块模式构建 KernelSU。理解这一点非常重要本文描述的是“把 KernelSU 作为内核源码树的一部分直接编译”的经典构建方式适用于你本来就需要自行编译 GKI 内核的场景例如定制内核、移植功能。如果你只是想在现成内核上加 KernelSU仓库脚本 scripts/prepare-ddk-x64.sh 所体现的 DDK LKM 路线才是当前官方维护的主路径这一点会在后文“LKM 模式背景”中说明。此外原文档同样提示该页面向 GKI 设备如果你的设备使用较旧的非 GKI 内核应参阅 非 GKI 设备集成指南。在开始之前原文档建议先阅读 Android 官方的两篇内核构建文档source.android.com 上的 “Building kernels”构建内核与 “GKI release builds”GKI 发行版构建页面。这两篇文档说明了 repo 工具链、构建环境和 GKI manifest 的通用用法本文不再展开只聚焦 KernelSU 相关部分。第一步同步 GKI 内核源码在任意工作目录中执行repo init -u https://android.googlesource.com/kernel/manifest mv kernel_manifest.xml .repo/manifests repo init -m manifest.xml repo sync参数说明repo init -u .../kernel/manifest以 Android 官方内核 manifest 仓库初始化 repo 环境kernel_manifest.xmlGKI 发行版提供的 manifest 文件名需从 Android 官方 “GKI release builds” 页面下载。该文件唯一标识一次构建所使用的内核源码快照是 GKI 内核可复现构建reproducible build的关键——用同一份 manifest 同步出的源码树任何开发者构建出的内核都应完全一致repo init -m manifest.xml切换到该指定 manifest 后再repo sync确保同步到与目标设备匹配的精确源码集合。第二步编译 GKI 内核镜像原文档以aarch64架构为例给出构建命令LTOthin BUILD_CONFIGcommon/build.config.gki.aarch64 build/build.sh两个关键变量BUILD_CONFIGcommon/build.config.gki.aarch64指定 GKI aarch64 构建配置LTOthin不要遗漏该标志。原文档明确指出若计算机内存小于 24 GB未开启 LTO 的构建可能失败——ThinLTO 能显著降低链接阶段的内存占用。自 Android 13 起内核改为由bazel构建对应命令tools/bazel build --configfast //common:kernel_aarch64_dist::: 原文档附带的一条实战提示针对部分 Android 14 内核在部分 Android 14 内核上为了让 Wi-Fi/Bluetooth 正常工作可能需要移除所有 GKI protected exportsrm common/abi_gki_protected_exports_*即删除内核源码中common/abi_gki_protected_exports_*文件。这是因为这些受保护导出列表会限制外部包括厂商驱动可链接的内核符号移除后才能让依赖这些符号的 Wi-Fi/蓝牙驱动通过modpost校验。第三步将 KernelSU 集成进内核源码树在成功构建过内核镜像之后集成 KernelSU 本身很简单进入内核源码根目录按需要的版本选择以下任一命令执行原文档提供的三种方式完整保留# 方式一最新 tag稳定版 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# 方式三指定 tag例如 v0.5.2 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s v0.5.2然后重新执行第二步的构建命令即可得到一个包含 KernelSU 的内核镜像。setup.sh 到底做了什么源码级解析setup.sh的完整实现位于仓库的 kernel/setup.sh只有约 75 行可以逐段读懂。它的用法为Usage: setup.sh [--cleanup | commit-or-tag]参数作用无参数将 KernelSU 安装/更新到最新 tag稳定版--cleanup清理此前脚本所做的全部修改commit-or-tag安装/更新到指定的 tag 或 commit如main、v0.9.5-h,--help显示用法1. 自动探测驱动目录L14-L26脚本首先探测内核源码中驱动目录的位置优先common/driversGKI 的 common 目录结构否则回退到根目录下的drivers/较旧的内核布局两者都不存在则以错误码 127 退出。这解释了为什么脚本同时适用于 GKI 的common/布局和普通内核树。2. 核心安装逻辑setup_kernelsuL40-L61这是脚本的主流程依次做四件事克隆 KernelSU 仓库到内核源码根目录若KernelSU/目录已存在则跳过克隆否则执行git clone切换版本先git stash保存本地改动并切回main执行git pull更新然后——若未传参数检出git describe --abbrev0 --tags得到的最新 tag若传了参数则检出指定 tag/commit检出失败时回退到默认分支创建符号链接在驱动目录下执行ln -sf KernelSU/kernel 的相对绝对路径 kernelsu 即建立drivers/kernelsu - ../KernelSU/kernel软链这样内核的 Kbuild 系统会把kernel/目录下的全部 C 源码当作drivers/kernelsu/来编译修改 Makefile 与 Kconfig幂等已存在则跳过向drivers/Makefile追加一行obj-$(CONFIG_KSU) kernelsu/在drivers/Kconfig的endmenu之前插入source drivers/kernelsu/Kconfig。这两行正是 Kconfig 中config KSU选项能被make menuconfig发现、以及CONFIG_KSU开启后kernelsu.o被纳入编译的原因对应 kernel/Kbuild L88 的obj-$(CONFIG_KSU) kernelsu.o。3. 清理逻辑perform_cleanupL29-L37--cleanup会逆序撤销上述所有改动删除drivers/kernelsu软链、从drivers/Makefile和drivers/Kconfig中删除含kernelsu的行、删除根目录下的KernelSU/克隆目录。也就是说集成过程对内核源码树的侵入被完全封装在这几处可逆修改里便于在多个设备/多个内核之间复用同一份 KernelSU 源码。编译期视角Kbuild 如何构建 kernelsu.o集成完成后重新编译内核时kernel/Kbuild 定义了kernelsu目标的完整对象列表从源码结构看可分为几个子系统核心初始化core/init.o功能特性feature/kernel_umount.o模块卸载、feature/sulog.oSU 日志、feature/sucompat.osu 兼容、feature/adb_root.oadb root、feature/selinux_hide.oHook 层hook/lsm_hook.oLSM 钩子、hook/setuid_hook.o、hook/syscall_event_bridge.o、hook/syscall_hook_manager.o、hook/tp_marker.o以及按架构条件编译的hook/arm64/patch_memory.o与hook/arm64/syscall_hook.ox86_64 则编译hook/x86_64/下对应文件基础设施infra/file_wrapper.o、infra/event_queue.o、infra/seccomp_cache.o、infra/su_mount_ns.o、infra/symbol_resolver.o管理器识别manager/apk_sign.o、manager/pkg_observer.o、manager/throne_tracker.o可用CONFIG_KSU_DISABLE_MANAGER剔除策略policy/allowlist.o、policy/app_profile.o、policy/feature.o运行时/日志/超级调用runtime/boot_event.o、runtime/ksud_integration.o、sulog/event.o、sulog/fd.o、supercall/dispatch.o、supercall/perm.o、supercall/supercall.o等。Kbuild 中还有两处与构建体验直接相关的细节版本号注入kernel/Kbuild L114-L124构建时若能在 KernelSU 目录中检测到独立的 git 仓库就用git rev-list --count HEAD自浅克隆还会自动fetch --unshallow算出KSU_GIT_VERSION再以30000 git version的公式注释说明 200/30000 是历史原因计算KSU_VERSION并-D进内核没有 git 元数据时回退为KSU_VERSION16并打印警告——这解释了为什么setup.sh用git clone而非下载 tarballtarball 不含.git会触发版本回退。管理器签名校验参数L138-L157通过 make 变量KSU_MANAGER_PACKAGE、KSU_EXPECTED_SIZE、KSU_EXPECTED_HASH以及可选的KSU_EXPECTED_SIZE2/KSU_EXPECTED_HASH2向内核注入管理器 APK 的包名与 v2 签名指纹默认值分别为0x033b与一个 sha256 哈希内核侧的 kernel/manager/apk_sign.c 据此识别可信的 Manager。自建内核时可以覆盖这些变量指向自己的 Manager 构建。KernelSU 的 Kconfig 构建选项drivers/kernelsu/Kconfig经setup.sh注入到内核drivers/Kconfig后提供以下选项可在make menuconfig的 “KernelSU” 菜单下配置选项类型/默认说明CONFIG_KSUtristate默认y总开关。depends on KPROBES EXT4_FS——内核钩子依赖KPROBES模块卸载功能依赖ext4_unregister_sysfs因而依赖EXT4_FS。选M时编译为名为kernelsu的模块CONFIG_KSU_DEBUGbool默认n开启调试模式Kbuild 中映射为-DCONFIG_KSU_DEBUG1宏CONFIG_KSU_DISABLE_MANAGERbool默认n禁用 Manager APK 识别与专属处理逻辑编译时剔除manager/子系统对象“Root 会替代仅 Manager 可用的功能”CONFIG_KSU_DISABLE_POLICYbool默认n禁用按 App 的 root/non-root 策略档案提权一律使用默认完整 root 档案CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHERbool仅X86_64默认n动态修补 x86_64 加固版 syscall dispatcher 以支持 syscall hook作为内核源码 patch 的替代方案主要面向 x86_64 LKM 模式其中CONFIG_KSU_DEBUG等选项除了影响 Kbuild 的对象选择外还会在外部模块LKM构建时通过ifdef KBUILD_EXTMOD分支转换为-D宏kernel/Kbuild L54-L67因此同一套 Kconfig 在 in-tree 与 LKM 两种构建方式下都能生效。LKM 模式背景当前官方主路径再次强调开头的存档警告v3.0 起官方迭代已转向 LKM 模式推荐工具为Ylarod/ddk。仓库中的两个文件可以作为这条路线的实证scripts/prepare-ddk-x64.sh 维护了一份 KMI 与工具链矩阵从源码结构看官方 CI 覆盖了android12-5.10、android13-5.10、android13-5.15、android14-5.15、android14-6.1、android15-6.6、android16-6.12、android17-6.18共 8 组内核版本每组对应固定的 clang 版本如clang-r416183b至clang-r584948c6.12 与 6.18 还叠加 Rust 工具链。脚本对每个 KMI 依次执行make gki_defconfig关闭 ThinLTO/FullLTO与本文LTOthin的 GKI 全内核构建形成对比、modules_prepare并针对ddk-min源码包预先修补scripts/mod/modpost.c以适配完整 kdir 的 modpost 修复。justfile 定义了用户空间组件的构建别名just bk即build_ksud通过cross build --target aarch64-linux-android --release交叉编译ksudLKM 模式下的用户态守护程序源码位于 userspace/ksudjust bm则在其基础上把它拷贝进manager/app/src/main/jniLibs/arm64-v8a/libksud.so并执行./gradlew aDebug构建 Manager APK。也就是说GKI image 模式构建的是“内核镜像 编译在内核中的 KernelSU”而 LKM 模式构建的产物是kernelsu.ko模块加ksud与 Manager 的组合。两种模式共享同一份kernel/源码树setup.sh的集成逻辑也兼容 LKM 场景CONFIG_KSUM。重新构建与验证清单完成setup.sh后按第二步的命令重新构建内核build/build.sh或bazel产出包含 KernelSU 的Image/Image.gz。构建与验证时建议核对以下几点Kconfig 状态确认CONFIG_KSUy或m、CONFIG_KPROBESy均在最终.config中生效Kbuild 在缺少 git 信息时会打印KSU_GIT_VERSION not defined! It is better to make KernelSU a git repository!的警告出现该警告说明版本回退到了默认值Manager 识别参数若使用官方 Manager默认注入的签名指纹即可用若签名不匹配导致内核拒绝识别 Manager检查构建时是否意外覆盖了KSU_EXPECTED_SIZE/KSU_EXPECTED_HASH回退手段集成出问题或需要干净源码树时运行setup.sh --cleanup一键还原 Makefile、Kconfig 与软链x86_64 注意在 x86_64 设备上构建时hook/x86_64/与CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER相关路径才参与编译且仓库 README 提示近期内核在 x86_64 上存在已知兼容性问题构建前建议先查阅 x86_64 支持说明。小结GKI 内核构建的三步主干repo同步 GKI manifest 源码 →LTOthin或 bazel构建内核镜像 → 用 kernel/setup.sh 注入 KernelSU 后重新构建setup.sh的全部侵入性修改只有四处软链 Makefile/Kconfig 各一行且可用--cleanup完整回滚编译期的行为由 kernel/Kbuild 与 kernel/Kconfig 决定子系统对象组织、git 版本号注入、Manager 签名校验、以及KSU_DEBUG/KSU_DISABLE_MANAGER/KSU_DISABLE_POLICY等构建选项该文档是 GKI image 模式的存档参考v3.0 之后官方主线已转向Ylarod/ddk的 LKM 构建仓库内 scripts/prepare-ddk-x64.sh 与 justfile 即该路线的工程化体现。【免费下载链接】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/KernelSU本篇基于仓库中的官方构建文档 how-to-build.md完整讲解如何为 GKI 设备从源码同步、编译 Android 内核镜像再通过setup.sh一键集成 KernelSU 并重新构建出带 root 能力的内核。文中每一步均结合仓库内 kernel/setup.sh、kernel/Kconfig、kernel/Kbuild 的实际实现展开帮助你既能跑通构建流程也能理解构建过程中 KernelSU 究竟往内核里注入了什么。文档定位GKI 内核构建方式的存档参考原文档开头有一段明确的警告这里必须完整保留其含义该文档仅作为存档参考已不再维护。自 KernelSU v3.0 起官方已不再支持 GKI image 模式即把 KernelSU 直接编进内核镜像的模式目的是加快迭代速度并缩短构建时间。官方推荐使用Ylarod/ddk以 LKM可加载内核模块模式构建 KernelSU。理解这一点非常重要本文描述的是“把 KernelSU 作为内核源码树的一部分直接编译”的经典构建方式适用于你本来就需要自行编译 GKI 内核的场景例如定制内核、移植功能。如果你只是想在现成内核上加 KernelSU仓库脚本 scripts/prepare-ddk-x64.sh 所体现的 DDK LKM 路线才是当前官方维护的主路径这一点会在后文“LKM 模式背景”中说明。此外原文档同样提示该页面向 GKI 设备如果你的设备使用较旧的非 GKI 内核应参阅 非 GKI 设备集成指南。在开始之前原文档建议先阅读 Android 官方的两篇内核构建文档source.android.com 上的 “Building kernels”构建内核与 “GKI release builds”GKI 发行版构建页面。这两篇文档说明了 repo 工具链、构建环境和 GKI manifest 的通用用法本文不再展开只聚焦 KernelSU 相关部分。第一步同步 GKI 内核源码在任意工作目录中执行repo init -u https://android.googlesource.com/kernel/manifest mv kernel_manifest.xml .repo/manifests repo init -m manifest.xml repo sync参数说明repo init -u .../kernel/manifest以 Android 官方内核 manifest 仓库初始化 repo 环境kernel_manifest.xmlGKI 发行版提供的 manifest 文件名需从 Android 官方 “GKI release builds” 页面下载。该文件唯一标识一次构建所使用的内核源码快照是 GKI 内核可复现构建reproducible build的关键——用同一份 manifest 同步出的源码树任何开发者构建出的内核都应完全一致repo init -m manifest.xml切换到该指定 manifest 后再repo sync确保同步到与目标设备匹配的精确源码集合。第二步编译 GKI 内核镜像原文档以aarch64架构为例给出构建命令LTOthin BUILD_CONFIGcommon/build.config.gki.aarch64 build/build.sh两个关键变量BUILD_CONFIGcommon/build.config.gki.aarch64指定 GKI aarch64 构建配置LTOthin不要遗漏该标志。原文档明确指出若计算机内存小于 24 GB未开启 LTO 的构建可能失败——ThinLTO 能显著降低链接阶段的内存占用。自 Android 13 起内核改为由bazel构建对应命令tools/bazel build --configfast //common:kernel_aarch64_dist::: 原文档附带的一条实战提示针对部分 Android 14 内核在部分 Android 14 内核上为了让 Wi-Fi/Bluetooth 正常工作可能需要移除所有 GKI protected exportsrm common/abi_gki_protected_exports_*即删除内核源码中common/abi_gki_protected_exports_*文件。这是因为这些受保护导出列表会限制外部包括厂商驱动可链接的内核符号移除后才能让依赖这些符号的 Wi-Fi/蓝牙驱动通过modpost校验。第三步将 KernelSU 集成进内核源码树在成功构建过内核镜像之后集成 KernelSU 本身很简单进入内核源码根目录按需要的版本选择以下任一命令执行原文档提供的三种方式完整保留# 方式一最新 tag稳定版 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# 方式三指定 tag例如 v0.5.2 curl -LSs https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh | bash -s v0.5.2然后重新执行第二步的构建命令即可得到一个包含 KernelSU 的内核镜像。setup.sh 到底做了什么源码级解析setup.sh的完整实现位于仓库的 kernel/setup.sh只有约 75 行可以逐段读懂。它的用法为Usage: setup.sh [--cleanup | commit-or-tag]参数作用无参数将 KernelSU 安装/更新到最新 tag稳定版--cleanup清理此前脚本所做的全部修改commit-or-tag安装/更新到指定的 tag 或 commit如main、v0.9.5-h,--help显示用法1. 自动探测驱动目录L14-L26脚本首先探测内核源码中驱动目录的位置优先common/driversGKI 的 common 目录结构否则回退到根目录下的drivers/较旧的内核布局两者都不存在则以错误码 127 退出。这解释了为什么脚本同时适用于 GKI 的common/布局和普通内核树。2. 核心安装逻辑setup_kernelsuL40-L61这是脚本的主流程依次做四件事克隆 KernelSU 仓库到内核源码根目录若KernelSU/目录已存在则跳过克隆否则执行git clone切换版本先git stash保存本地改动并切回main执行git pull更新然后——若未传参数检出git describe --abbrev0 --tags得到的最新 tag若传了参数则检出指定 tag/commit检出失败时回退到默认分支创建符号链接在驱动目录下执行ln -sf KernelSU/kernel 的相对绝对路径 kernelsu 即建立drivers/kernelsu - ../KernelSU/kernel软链这样内核的 Kbuild 系统会把kernel/目录下的全部 C 源码当作drivers/kernelsu/来编译修改 Makefile 与 Kconfig幂等已存在则跳过向drivers/Makefile追加一行obj-$(CONFIG_KSU) kernelsu/在drivers/Kconfig的endmenu之前插入source drivers/kernelsu/Kconfig。这两行正是 Kconfig 中config KSU选项能被make menuconfig发现、以及CONFIG_KSU开启后kernelsu.o被纳入编译的原因对应 kernel/Kbuild L88 的obj-$(CONFIG_KSU) kernelsu.o。3. 清理逻辑perform_cleanupL29-L37--cleanup会逆序撤销上述所有改动删除drivers/kernelsu软链、从drivers/Makefile和drivers/Kconfig中删除含kernelsu的行、删除根目录下的KernelSU/克隆目录。也就是说集成过程对内核源码树的侵入被完全封装在这几处可逆修改里便于在多个设备/多个内核之间复用同一份 KernelSU 源码。编译期视角Kbuild 如何构建 kernelsu.o集成完成后重新编译内核时kernel/Kbuild 定义了kernelsu目标的完整对象列表从源码结构看可分为几个子系统核心初始化core/init.o功能特性feature/kernel_umount.o模块卸载、feature/sulog.oSU 日志、feature/sucompat.osu 兼容、feature/adb_root.oadb root、feature/selinux_hide.oHook 层hook/lsm_hook.oLSM 钩子、hook/setuid_hook.o、hook/syscall_event_bridge.o、hook/syscall_hook_manager.o、hook/tp_marker.o以及按架构条件编译的hook/arm64/patch_memory.o与hook/arm64/syscall_hook.ox86_64 则编译hook/x86_64/下对应文件基础设施infra/file_wrapper.o、infra/event_queue.o、infra/seccomp_cache.o、infra/su_mount_ns.o、infra/symbol_resolver.o管理器识别manager/apk_sign.o、manager/pkg_observer.o、manager/throne_tracker.o可用CONFIG_KSU_DISABLE_MANAGER剔除策略policy/allowlist.o、policy/app_profile.o、policy/feature.o运行时/日志/超级调用runtime/boot_event.o、runtime/ksud_integration.o、sulog/event.o、sulog/fd.o、supercall/dispatch.o、supercall/perm.o、supercall/supercall.o等。Kbuild 中还有两处与构建体验直接相关的细节版本号注入kernel/Kbuild L114-L124构建时若能在 KernelSU 目录中检测到独立的 git 仓库就用git rev-list --count HEAD自浅克隆还会自动fetch --unshallow算出KSU_GIT_VERSION再以30000 git version的公式注释说明 200/30000 是历史原因计算KSU_VERSION并-D进内核没有 git 元数据时回退为KSU_VERSION16并打印警告——这解释了为什么setup.sh用git clone而非下载 tarballtarball 不含.git会触发版本回退。管理器签名校验参数L138-L157通过 make 变量KSU_MANAGER_PACKAGE、KSU_EXPECTED_SIZE、KSU_EXPECTED_HASH以及可选的KSU_EXPECTED_SIZE2/KSU_EXPECTED_HASH2向内核注入管理器 APK 的包名与 v2 签名指纹默认值分别为0x033b与一个 sha256 哈希内核侧的 kernel/manager/apk_sign.c 据此识别可信的 Manager。自建内核时可以覆盖这些变量指向自己的 Manager 构建。KernelSU 的 Kconfig 构建选项drivers/kernelsu/Kconfig经setup.sh注入到内核drivers/Kconfig后提供以下选项可在make menuconfig的 “KernelSU” 菜单下配置选项类型/默认说明CONFIG_KSUtristate默认y总开关。depends on KPROBES EXT4_FS——内核钩子依赖KPROBES模块卸载功能依赖ext4_unregister_sysfs因而依赖EXT4_FS。选M时编译为名为kernelsu的模块CONFIG_KSU_DEBUGbool默认n开启调试模式Kbuild 中映射为-DCONFIG_KSU_DEBUG1宏CONFIG_KSU_DISABLE_MANAGERbool默认n禁用 Manager APK 识别与专属处理逻辑编译时剔除manager/子系统对象“Root 会替代仅 Manager 可用的功能”CONFIG_KSU_DISABLE_POLICYbool默认n禁用按 App 的 root/non-root 策略档案提权一律使用默认完整 root 档案CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHERbool仅X86_64默认n动态修补 x86_64 加固版 syscall dispatcher 以支持 syscall hook作为内核源码 patch 的替代方案主要面向 x86_64 LKM 模式其中CONFIG_KSU_DEBUG等选项除了影响 Kbuild 的对象选择外还会在外部模块LKM构建时通过ifdef KBUILD_EXTMOD分支转换为-D宏kernel/Kbuild L54-L67因此同一套 Kconfig 在 in-tree 与 LKM 两种构建方式下都能生效。LKM 模式背景当前官方主路径再次强调开头的存档警告v3.0 起官方迭代已转向 LKM 模式推荐工具为Ylarod/ddk。仓库中的两个文件可以作为这条路线的实证scripts/prepare-ddk-x64.sh 维护了一份 KMI 与工具链矩阵从源码结构看官方 CI 覆盖了android12-5.10、android13-5.10、android13-5.15、android14-5.15、android14-6.1、android15-6.6、android16-6.12、android17-6.18共 8 组内核版本每组对应固定的 clang 版本如clang-r416183b至clang-r584948c6.12 与 6.18 还叠加 Rust 工具链。脚本对每个 KMI 依次执行make gki_defconfig关闭 ThinLTO/FullLTO与本文LTOthin的 GKI 全内核构建形成对比、modules_prepare并针对ddk-min源码包预先修补scripts/mod/modpost.c以适配完整 kdir 的 modpost 修复。justfile 定义了用户空间组件的构建别名just bk即build_ksud通过cross build --target aarch64-linux-android --release交叉编译ksudLKM 模式下的用户态守护程序源码位于 userspace/ksudjust bm则在其基础上把它拷贝进manager/app/src/main/jniLibs/arm64-v8a/libksud.so并执行./gradlew aDebug构建 Manager APK。也就是说GKI image 模式构建的是“内核镜像 编译在内核中的 KernelSU”而 LKM 模式构建的产物是kernelsu.ko模块加ksud与 Manager 的组合。两种模式共享同一份kernel/源码树setup.sh的集成逻辑也兼容 LKM 场景CONFIG_KSUM。重新构建与验证清单完成setup.sh后按第二步的命令重新构建内核build/build.sh或bazel产出包含 KernelSU 的Image/Image.gz。构建与验证时建议核对以下几点Kconfig 状态确认CONFIG_KSUy或m、CONFIG_KPROBESy均在最终.config中生效Kbuild 在缺少 git 信息时会打印KSU_GIT_VERSION not defined! It is better to make KernelSU a git repository!的警告出现该警告说明版本回退到了默认值Manager 识别参数若使用官方 Manager默认注入的签名指纹即可用若签名不匹配导致内核拒绝识别 Manager检查构建时是否意外覆盖了KSU_EXPECTED_SIZE/KSU_EXPECTED_HASH回退手段集成出问题或需要干净源码树时运行setup.sh --cleanup一键还原 Makefile、Kconfig 与软链x86_64 注意在 x86_64 设备上构建时hook/x86_64/与CONFIG_KSU_X86_PATCH_SYSCALL_DISPATCHER相关路径才参与编译且仓库 README 提示近期内核在 x86_64 上存在已知兼容性问题构建前建议先查阅 x86_64 支持说明。小结GKI 内核构建的三步主干repo同步 GKI manifest 源码 →LTOthin或 bazel构建内核镜像 → 用 kernel/setup.sh 注入 KernelSU 后重新构建setup.sh的全部侵入性修改只有四处软链 Makefile/Kconfig 各一行且可用--cleanup完整回滚编译期的行为由 kernel/Kbuild 与 kernel/Kconfig 决定子系统对象组织、git 版本号注入、Manager 签名校验、以及KSU_DEBUG/KSU_DISABLE_MANAGER/KSU_DISABLE_POLICY等构建选项该文档是 GKI image 模式的存档参考v3.0 之后官方主线已转向Ylarod/ddk的 LKM 构建仓库内 scripts/prepare-ddk-x64.sh 与 justfile 即该路线的工程化体现。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考