KernelSU 是什么基于内核的 Android GKI Root 解决方案与模块架构详解【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是面向 Android GKIGeneric Kernel Image设备的内核级 root 解决方案其核心特征是以内核模式运行——直接在内核空间中为应用授予 root 权限从而提供用户空间 root 方案无法触及的内核接口。本文以官方中文文档为主线结合本仓库中 kernel 内核模块、ksud 用户空间工具与 Manager 管理器的实际实现系统讲解 KernelSU 的定位、核心特性、模块机制、安装路径与构建方式帮助你建立对这套「基于内核的 root 可插拔模块」架构的完整认知。一、KernelSU 是什么KernelSU 是 Android GKI 设备的 root 解决方案它工作在内核模式并直接在内核空间中为用户空间应用程序授予 root 权限官方文档。这一「内核空间直接授权」的架构与用户空间 root 方案有本质区别。从仓库源码看授权入口位于 kernel/supercall/dispatch.c 的do_grant_root()内核在确认调用者已通过白名单allowlist检查后通过escape_with_root_profile()为当前进程授予 root profile同时通过ksu_sulog_emit_grant_root()记录审计日志。也就是说root 授权这一动作发生在内核内部而不是像传统方案那样通过一个运行在用户空间的守护进程代为执行。在理解 KernelSU 之前需要先明确两个概念GKIGeneric Kernel ImageGoogle 推出的通用内核镜像计划将内核与厂商驱动解耦。GKI 设备的内核版本遵循固定格式详见安装章节中的 KMI 说明。KMIKernel Module Interface内核模块接口相同 KMI 的内核版本互相兼容这也是 GKI 中「通用」二字的含义。二、核心特性基于内核的能力KernelSU 的主要特点是它是基于内核的。KernelSU 运行在内核空间所以它可以提供我们以前从未有过的内核接口。官方文档列举了三种典型能力硬件断点在内核模式下为任何进程添加硬件断点物理内存访问在任何进程的物理内存中访问而无人知晓系统调用拦截在内核空间拦截任何系统调用。仓库中确实存在与这些能力对应的实现骨架。内核侧的 hook 体系分布在 kernel/hook/ 下lsm_hook.c 与 setuid_hook.c通过 LSM 与 setuid 路径实现对关键安全回调的接管syscall_hook.c 与 syscall_hook_manager.c在 arm64 / x86_64 上实现系统调用级 hooktp_marker.c基于内核 tracepoint 的标记机制为后续钩子提供触发点patch_memory.c用于内核态内存补丁。从这些模块可以推断KernelSU 的「内核接口」是一套围绕 syscall / LSM / tracepoint 的完整 hook 框架而 root 授权只是其最基础的用途之一——模块系统、initrc 注入、SELinux 策略加载等都建立在这套内核接口之上详见 kernel/feature/ 下的adb_root.c、kernel_umount.c、selinux_hide.c、sulog.c等特性实现。三、核心特性可插拔的 metamodule 模块架构除了内核接口KernelSU 还提供了metamodule元模块系统这是一套可插拔的模块管理架构。与将挂载逻辑内置到核心的传统 root 方案不同KernelSU 将此功能委托给 metamodule。这允许你安装meta-overlayfs等 metamodule以提供对/system分区和其他分区的无系统systemless修改官方文档。这一设计思路在官方《元模块》文档website/docs/zh_CN/guide/metamodule.md中有完整阐述可概括为以下几点什么是元模块元模块是一种特殊类型的 KernelSU 模块为模块系统提供核心基础设施功能。与常规模块不同元模块控制常规模块的安装和挂载方式。它具备四个主要特征基础设施角色元模块提供常规模块依赖的服务单实例只允许一个元模块处于运行状态优先执行元模块脚本在常规模块脚本之前运行特殊钩子提供三个用于安装、挂载和清理的钩子脚本。为什么需要元模块传统 root 解决方案将挂载逻辑内置在核心中这使得它们更容易被检测且难以演进。KernelSU 的元模块架构通过关注点分离解决这些问题减少检测面KernelSU 本身不执行挂载减少了检测向量稳定性核心保持稳定而挂载实现可以不断演进创新性社区可以开发替代挂载策略选择性用户可以选择最适合其需求的实现。在挂载灵活性上元模块架构允许完全自定义挂载策略可以是无挂载仅使用无挂载模块时完全避免挂载开销、OverlayFS 挂载通过meta-overlayfs支持读写层、Magic MountMagisk 兼容挂载或自定义实现基于 FUSE 的 overlayfs、自定义 VFS 挂载等。::: warning 重要 如果没有安装元模块依赖挂载的模块其挂载功能将不会生效。新安装的 KernelSU 需要安装元模块如meta-overlayfs才能使模块正常工作。 :::与 Magisk 的架构差异在官方《KernelSU 模块与 Magisk 的差异》文档website/docs/zh_CN/guide/difference-with-magisk.md中也有明确对照KernelSU 使用 metamodule 系统将挂载委托给可插拔模块而 Magisk 将挂载内置在其核心中。另外该文档还列出了一些模块兼容性差异KernelSU 的模块不支持在 Recovery 中安装KernelSU 没有内置 Zygisk 支持可通过 ZygiskNext 使用KernelSU 不支持.replace方式删除文件需通过mknod filename c 0 0创建同名节点来 whiteout 删除也支持REPLACE与REMOVE变量KernelSU 内置 BusyBox 位于/data/adb/ksu/bin/busyboxKernelSU 新增boot-completed.sh与post-mount.sh两种脚本脚本可用环境变量KSU值为true区分当前运行环境。四、如何使用安装路径概览官方《安装》文档website/docs/zh_CN/guide/installation.md是使用 KernelSU 的入口。其要点如下1. 检查设备是否受支持从官方 Release 下载 KernelSU 管理器应用并安装到设备打开如果应用显示「不支持」说明设备没有官方开箱即用的 boot 镜像需要自行编译设备内核集成 KernelSU官方不会提供可刷写的 boot 镜像如果显示「未安装」说明设备受支持可进入下一步。先决条件设备必须能够解锁 bootloader。2. 备份原厂 boot.img刷机前必须备份原厂 boot.img出现问题时可通过fastboot刷回恢复。任何刷机操作都有风险必要时还应备份全部数据。3. 必备知识KMI 与安全补丁级别KMI 格式GKI 设备内核版本格式为Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix如w.x.y-zzz-k-something其中w.x-zzz-k为 KMI 版本。例如5.10.101-android12-9-g30979850fc20的 KMI 是5.10-android12-9刷入相同 KMI 的内核可正常开机。::: tip 注意 SubLevel 不属于 KMI5.10.101-android12-9-...与5.10.137-android12-9-...的 KMI 相同。 :::安全补丁级别SPL新设备可能有防回滚机制不允许刷入安全补丁更旧的内核。在 KMI 一致的前提下应优先采用安全补丁级别更新的内核。内核版本 ≠ Android 版本内核版本一般与设备出厂时自带的 Android 系统版本一致系统升级后内核版本通常不变化。刷机请以内核版本为准。4. 两种运行模式自0.9.0版本以后GKI 设备上 KernelSU 支持两种运行模式模式原理优点适用建议LKM使用可加载内核模块加载不替换设备原有内核保留原厂内核、升级与 OTA 方便、可用临时 root 加载、不触发 avb、可临时卸载手机设备优先GKI用 KernelSU 提供的通用内核镜像替换原厂内核通用性强、不依赖官方固件更新模拟器、WSA、Waydroid 等5. 安装方法LKM 模式获取官方固件 → 用管理器「选择并修补一个文件 / 直接安装 / 安装到另一个分区」或命令行ksud boot-patch修补 → 刷入。LKM 会修改 ramdisk出厂 Android 13 设备修补init_boot分区GKI 模式永远操作boot分区。GKI 模式可使用 KernelSU 提供的 boot.img 直接fastboot flash boot boot.img、用内核刷写 AppAnyKernel3 包、手动用magiskboot修补 boot.imgPixel 等特殊压缩格式设备推荐、或用 TWRP 等自定义 Recovery 刷入 AnyKernel3 zip。命令行修补ksud boot-patchKernelSU 的ksud工具支持 macOS、Linux 和 Windows核心用法如下ksud boot-patch -b boot.img --kmi android13-5.10其中-b/--boot指定 boot 镜像路径--kmi用于设备内核名未遵循 KMI 规范时手动指定 KMI。该命令在仓库用户空间侧的实现位于 userspace/ksud/src/boot_patch.rs并在 userspace/ksud/src/cli.rs 中注册为 CLI 子命令还支持-k/--kernel、-m/--module、-f/--flash、-o/--out、--magiskboot、-u/--ota等选项完整选项见ksud boot-patch -h。安装后的模块支持想使用修改/system文件的模块需要先安装 metamodule如meta-overlayfs仅使用脚本、sepolicy 或 system.prop 的模块无需 metamodule。五、模块机制补充常规模块要点由于「使用」章节指向安装文档而模块与 metamodule 是 KernelSU 使用体验的核心这里补充常规模块的几个关键机制详见 website/docs/zh_CN/guide/module.md模块目录位于/data/adb/modules/MODID核心文件包括module.prop必须格式为id...、name...、versionCodeint等id必须匹配^[a-zA-Z][a-zA-Z0-9._-]$、system/将被 overlayfs 挂载叠加到/system、标记文件skip_mount/disable/remove以及可选脚本post-fs-data.sh、post-mount.sh、service.sh、boot-completed.sh、uninstall.sh、system.prop、sepolicy.rule、initrc/等。systemless 机制通过内核 overlayfs 叠加同名文件覆盖、同名目录合并删除文件用mknod name c 0 0触发 whiteout替换目录用setfattr -n trusted.overlay.opaque -v y dir也可在customize.sh中声明REMOVE/REPLACE变量自动处理。initrc 注入将模块initrc/目录下.rc文件全局目录/data/adb/initrc.d/需可执行权限由内核 hook 透明追加到init.rcksud 合并为modules.rc存放于/metadata可用ksud initrc refresh手动刷新。启动脚本post-fs-data 模式阻塞脚本在任何模块挂载之前运行setprop会导致死锁应使用resetprop -n与 late_start 服务模式非阻塞与启动并行大多数脚本推荐此模式通用脚本置于/data/adb/post-fs-data.d、/data/adb/service.d等目录且需可执行权限。late-load 模式LKM 场景下通过ksud late-load在系统完全启动后加载内核模块此时 initrc 注入不可用、安全模式检测禁用模块可用KSU_LATE_LOAD1环境变量检测该模式。隐藏功能默认/system/bin/sh会加载/system/etc/mkshrc创建/data/adb/ksu/.ksurc可让 su 改加载该文件website/docs/zh_CN/guide/hidden-features.md。六、如何构建构建 KernelSU 涉及两个层面内核侧集成与用户空间侧编译。内核侧仓库内核源码位于 kernel/采用 Kbuild 体系kernel/Makefile、kernel/Kbuild可在内核源码树中集成后编译。对于非 GKI 设备需要下载内核源代码并将 KernelSU 集成到源码树中自行编译参考 website/docs/zh_CN/guide/how-to-integrate-for-non-gki.md目前内核最低支持到 4.14更低版本需要手动移植。用户空间侧ksuduserspace/ksud/与ksuinituserspace/ksuinit/均为 Rust 项目仓库根目录的 Cargo.toml 与 justfile 定义了工作区与常用构建命令。七、常见问题速览官方《常见问题》文档website/docs/zh_CN/guide/faq.md回答了使用者的核心疑问是否需要解锁 Bootloader当然需要是否支持模块支持但修改/system的模块需要安装 metamodule是否支持 Xposed / ZygiskKernelSU 本体不支持 Zygisk但可通过 ZygiskNext 正常运行 LSPosed 等 Zygisk 模块与 Magisk 兼容性模块系统与 Magisk 的 magic mount 冲突启用任何模块时整个 Magisk 无法工作但仅使用su时二者可共存KernelSU 改 kernel、Magisk 改 ramdisk是否会替代 Magisk官方明确表示这不是目标——Magisk 对用户空间 root 方案已经足够好KernelSU 的目标是提供内核接口支持范围支持非 GKI 设备需自行编译内核、支持旧内核最低 4.14出厂 Android 12 的设备必定是 GKI 设备。八、小结KernelSU 的定位可以概括为一句话以内核接口为根基、以 metamodule 为模块层核心的可插拔 root 架构。内核侧通过 kernel/supercall/ 的 supercall 通道与 kernel/policy/allowlist.c 中的白名单机制完成授权与审计用户空间侧由 userspace/ksud/ 负责 boot 修补、模块管理与脚本调度Manager 应用manager/app/提供图形化安装与管理入口。理解「基于内核」与「模块挂载可插拔」这两个核心点就抓住了 KernelSU 与以往 root 方案最本质的区别。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KernelSU 是什么：基于内核的 Android GKI Root 解决方案与模块架构详解
KernelSU 是什么基于内核的 Android GKI Root 解决方案与模块架构详解【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是面向 Android GKIGeneric Kernel Image设备的内核级 root 解决方案其核心特征是以内核模式运行——直接在内核空间中为应用授予 root 权限从而提供用户空间 root 方案无法触及的内核接口。本文以官方中文文档为主线结合本仓库中 kernel 内核模块、ksud 用户空间工具与 Manager 管理器的实际实现系统讲解 KernelSU 的定位、核心特性、模块机制、安装路径与构建方式帮助你建立对这套「基于内核的 root 可插拔模块」架构的完整认知。一、KernelSU 是什么KernelSU 是 Android GKI 设备的 root 解决方案它工作在内核模式并直接在内核空间中为用户空间应用程序授予 root 权限官方文档。这一「内核空间直接授权」的架构与用户空间 root 方案有本质区别。从仓库源码看授权入口位于 kernel/supercall/dispatch.c 的do_grant_root()内核在确认调用者已通过白名单allowlist检查后通过escape_with_root_profile()为当前进程授予 root profile同时通过ksu_sulog_emit_grant_root()记录审计日志。也就是说root 授权这一动作发生在内核内部而不是像传统方案那样通过一个运行在用户空间的守护进程代为执行。在理解 KernelSU 之前需要先明确两个概念GKIGeneric Kernel ImageGoogle 推出的通用内核镜像计划将内核与厂商驱动解耦。GKI 设备的内核版本遵循固定格式详见安装章节中的 KMI 说明。KMIKernel Module Interface内核模块接口相同 KMI 的内核版本互相兼容这也是 GKI 中「通用」二字的含义。二、核心特性基于内核的能力KernelSU 的主要特点是它是基于内核的。KernelSU 运行在内核空间所以它可以提供我们以前从未有过的内核接口。官方文档列举了三种典型能力硬件断点在内核模式下为任何进程添加硬件断点物理内存访问在任何进程的物理内存中访问而无人知晓系统调用拦截在内核空间拦截任何系统调用。仓库中确实存在与这些能力对应的实现骨架。内核侧的 hook 体系分布在 kernel/hook/ 下lsm_hook.c 与 setuid_hook.c通过 LSM 与 setuid 路径实现对关键安全回调的接管syscall_hook.c 与 syscall_hook_manager.c在 arm64 / x86_64 上实现系统调用级 hooktp_marker.c基于内核 tracepoint 的标记机制为后续钩子提供触发点patch_memory.c用于内核态内存补丁。从这些模块可以推断KernelSU 的「内核接口」是一套围绕 syscall / LSM / tracepoint 的完整 hook 框架而 root 授权只是其最基础的用途之一——模块系统、initrc 注入、SELinux 策略加载等都建立在这套内核接口之上详见 kernel/feature/ 下的adb_root.c、kernel_umount.c、selinux_hide.c、sulog.c等特性实现。三、核心特性可插拔的 metamodule 模块架构除了内核接口KernelSU 还提供了metamodule元模块系统这是一套可插拔的模块管理架构。与将挂载逻辑内置到核心的传统 root 方案不同KernelSU 将此功能委托给 metamodule。这允许你安装meta-overlayfs等 metamodule以提供对/system分区和其他分区的无系统systemless修改官方文档。这一设计思路在官方《元模块》文档website/docs/zh_CN/guide/metamodule.md中有完整阐述可概括为以下几点什么是元模块元模块是一种特殊类型的 KernelSU 模块为模块系统提供核心基础设施功能。与常规模块不同元模块控制常规模块的安装和挂载方式。它具备四个主要特征基础设施角色元模块提供常规模块依赖的服务单实例只允许一个元模块处于运行状态优先执行元模块脚本在常规模块脚本之前运行特殊钩子提供三个用于安装、挂载和清理的钩子脚本。为什么需要元模块传统 root 解决方案将挂载逻辑内置在核心中这使得它们更容易被检测且难以演进。KernelSU 的元模块架构通过关注点分离解决这些问题减少检测面KernelSU 本身不执行挂载减少了检测向量稳定性核心保持稳定而挂载实现可以不断演进创新性社区可以开发替代挂载策略选择性用户可以选择最适合其需求的实现。在挂载灵活性上元模块架构允许完全自定义挂载策略可以是无挂载仅使用无挂载模块时完全避免挂载开销、OverlayFS 挂载通过meta-overlayfs支持读写层、Magic MountMagisk 兼容挂载或自定义实现基于 FUSE 的 overlayfs、自定义 VFS 挂载等。::: warning 重要 如果没有安装元模块依赖挂载的模块其挂载功能将不会生效。新安装的 KernelSU 需要安装元模块如meta-overlayfs才能使模块正常工作。 :::与 Magisk 的架构差异在官方《KernelSU 模块与 Magisk 的差异》文档website/docs/zh_CN/guide/difference-with-magisk.md中也有明确对照KernelSU 使用 metamodule 系统将挂载委托给可插拔模块而 Magisk 将挂载内置在其核心中。另外该文档还列出了一些模块兼容性差异KernelSU 的模块不支持在 Recovery 中安装KernelSU 没有内置 Zygisk 支持可通过 ZygiskNext 使用KernelSU 不支持.replace方式删除文件需通过mknod filename c 0 0创建同名节点来 whiteout 删除也支持REPLACE与REMOVE变量KernelSU 内置 BusyBox 位于/data/adb/ksu/bin/busyboxKernelSU 新增boot-completed.sh与post-mount.sh两种脚本脚本可用环境变量KSU值为true区分当前运行环境。四、如何使用安装路径概览官方《安装》文档website/docs/zh_CN/guide/installation.md是使用 KernelSU 的入口。其要点如下1. 检查设备是否受支持从官方 Release 下载 KernelSU 管理器应用并安装到设备打开如果应用显示「不支持」说明设备没有官方开箱即用的 boot 镜像需要自行编译设备内核集成 KernelSU官方不会提供可刷写的 boot 镜像如果显示「未安装」说明设备受支持可进入下一步。先决条件设备必须能够解锁 bootloader。2. 备份原厂 boot.img刷机前必须备份原厂 boot.img出现问题时可通过fastboot刷回恢复。任何刷机操作都有风险必要时还应备份全部数据。3. 必备知识KMI 与安全补丁级别KMI 格式GKI 设备内核版本格式为Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix如w.x.y-zzz-k-something其中w.x-zzz-k为 KMI 版本。例如5.10.101-android12-9-g30979850fc20的 KMI 是5.10-android12-9刷入相同 KMI 的内核可正常开机。::: tip 注意 SubLevel 不属于 KMI5.10.101-android12-9-...与5.10.137-android12-9-...的 KMI 相同。 :::安全补丁级别SPL新设备可能有防回滚机制不允许刷入安全补丁更旧的内核。在 KMI 一致的前提下应优先采用安全补丁级别更新的内核。内核版本 ≠ Android 版本内核版本一般与设备出厂时自带的 Android 系统版本一致系统升级后内核版本通常不变化。刷机请以内核版本为准。4. 两种运行模式自0.9.0版本以后GKI 设备上 KernelSU 支持两种运行模式模式原理优点适用建议LKM使用可加载内核模块加载不替换设备原有内核保留原厂内核、升级与 OTA 方便、可用临时 root 加载、不触发 avb、可临时卸载手机设备优先GKI用 KernelSU 提供的通用内核镜像替换原厂内核通用性强、不依赖官方固件更新模拟器、WSA、Waydroid 等5. 安装方法LKM 模式获取官方固件 → 用管理器「选择并修补一个文件 / 直接安装 / 安装到另一个分区」或命令行ksud boot-patch修补 → 刷入。LKM 会修改 ramdisk出厂 Android 13 设备修补init_boot分区GKI 模式永远操作boot分区。GKI 模式可使用 KernelSU 提供的 boot.img 直接fastboot flash boot boot.img、用内核刷写 AppAnyKernel3 包、手动用magiskboot修补 boot.imgPixel 等特殊压缩格式设备推荐、或用 TWRP 等自定义 Recovery 刷入 AnyKernel3 zip。命令行修补ksud boot-patchKernelSU 的ksud工具支持 macOS、Linux 和 Windows核心用法如下ksud boot-patch -b boot.img --kmi android13-5.10其中-b/--boot指定 boot 镜像路径--kmi用于设备内核名未遵循 KMI 规范时手动指定 KMI。该命令在仓库用户空间侧的实现位于 userspace/ksud/src/boot_patch.rs并在 userspace/ksud/src/cli.rs 中注册为 CLI 子命令还支持-k/--kernel、-m/--module、-f/--flash、-o/--out、--magiskboot、-u/--ota等选项完整选项见ksud boot-patch -h。安装后的模块支持想使用修改/system文件的模块需要先安装 metamodule如meta-overlayfs仅使用脚本、sepolicy 或 system.prop 的模块无需 metamodule。五、模块机制补充常规模块要点由于「使用」章节指向安装文档而模块与 metamodule 是 KernelSU 使用体验的核心这里补充常规模块的几个关键机制详见 website/docs/zh_CN/guide/module.md模块目录位于/data/adb/modules/MODID核心文件包括module.prop必须格式为id...、name...、versionCodeint等id必须匹配^[a-zA-Z][a-zA-Z0-9._-]$、system/将被 overlayfs 挂载叠加到/system、标记文件skip_mount/disable/remove以及可选脚本post-fs-data.sh、post-mount.sh、service.sh、boot-completed.sh、uninstall.sh、system.prop、sepolicy.rule、initrc/等。systemless 机制通过内核 overlayfs 叠加同名文件覆盖、同名目录合并删除文件用mknod name c 0 0触发 whiteout替换目录用setfattr -n trusted.overlay.opaque -v y dir也可在customize.sh中声明REMOVE/REPLACE变量自动处理。initrc 注入将模块initrc/目录下.rc文件全局目录/data/adb/initrc.d/需可执行权限由内核 hook 透明追加到init.rcksud 合并为modules.rc存放于/metadata可用ksud initrc refresh手动刷新。启动脚本post-fs-data 模式阻塞脚本在任何模块挂载之前运行setprop会导致死锁应使用resetprop -n与 late_start 服务模式非阻塞与启动并行大多数脚本推荐此模式通用脚本置于/data/adb/post-fs-data.d、/data/adb/service.d等目录且需可执行权限。late-load 模式LKM 场景下通过ksud late-load在系统完全启动后加载内核模块此时 initrc 注入不可用、安全模式检测禁用模块可用KSU_LATE_LOAD1环境变量检测该模式。隐藏功能默认/system/bin/sh会加载/system/etc/mkshrc创建/data/adb/ksu/.ksurc可让 su 改加载该文件website/docs/zh_CN/guide/hidden-features.md。六、如何构建构建 KernelSU 涉及两个层面内核侧集成与用户空间侧编译。内核侧仓库内核源码位于 kernel/采用 Kbuild 体系kernel/Makefile、kernel/Kbuild可在内核源码树中集成后编译。对于非 GKI 设备需要下载内核源代码并将 KernelSU 集成到源码树中自行编译参考 website/docs/zh_CN/guide/how-to-integrate-for-non-gki.md目前内核最低支持到 4.14更低版本需要手动移植。用户空间侧ksuduserspace/ksud/与ksuinituserspace/ksuinit/均为 Rust 项目仓库根目录的 Cargo.toml 与 justfile 定义了工作区与常用构建命令。七、常见问题速览官方《常见问题》文档website/docs/zh_CN/guide/faq.md回答了使用者的核心疑问是否需要解锁 Bootloader当然需要是否支持模块支持但修改/system的模块需要安装 metamodule是否支持 Xposed / ZygiskKernelSU 本体不支持 Zygisk但可通过 ZygiskNext 正常运行 LSPosed 等 Zygisk 模块与 Magisk 兼容性模块系统与 Magisk 的 magic mount 冲突启用任何模块时整个 Magisk 无法工作但仅使用su时二者可共存KernelSU 改 kernel、Magisk 改 ramdisk是否会替代 Magisk官方明确表示这不是目标——Magisk 对用户空间 root 方案已经足够好KernelSU 的目标是提供内核接口支持范围支持非 GKI 设备需自行编译内核、支持旧内核最低 4.14出厂 Android 12 的设备必定是 GKI 设备。八、小结KernelSU 的定位可以概括为一句话以内核接口为根基、以 metamodule 为模块层核心的可插拔 root 架构。内核侧通过 kernel/supercall/ 的 supercall 通道与 kernel/policy/allowlist.c 中的白名单机制完成授权与审计用户空间侧由 userspace/ksud/ 负责 boot 修补、模块管理与脚本调度Manager 应用manager/app/提供图形化安装与管理入口。理解「基于内核」与「模块挂载可插拔」这两个核心点就抓住了 KernelSU 与以往 root 方案最本质的区别。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考