管理器
约 1694 字大约 6 分钟
YukiSU Manager 使用 Kotlin 和 Jetpack Compose 开发。授权应用、装模块、开 YukiZygisk、安装 LKM、备份分区和看诊断，都在这里完成。
但先别把 APK 当成 Root 本体。管理器只是前台：内核里得有兼容的 YukiSU LKM，认证要成功，ksud 也要正常，它才能真正做事。
你在界面上操作
↓
YukiSU Manager
↓ 认证、发送请求
ksud / su
↓
kernelsu.ko所以 APK 能打开、首页却写着“未安装”，完全不矛盾。界面已经在了，内核侧还没接上而已。
首页先看什么
首页不是一张装饰用的设备信息卡。出问题时，先看这几项：
| 状态 | 正常时说明什么 | 不正常先查哪里 |
|---|---|---|
| 设备与内核 | 进入 ARM64 GKI 2.0 / 5.10+ 范围 | 架构、GKI、内核版本 |
| YukiSU / LKM | 内核确实加载了哪一版 YukiSU | 启动镜像、KMI、LKM 日志 |
| Hook | TSR 已经工作 | 内核配置、tracepoint、第一条内核错误 |
| 管理器认证 | 当前 APK 被内核认作管理器 | 包名、签名、SuperKey、设备时间 |
ksud | 内置版和已安装版分别是什么 | 是否需要同步、有没有混用构建 |
| MetaModule | 当前挂载后端是谁 | 禁用、待更新、待卸载、启动日志 |
| YukiZygisk | 是否支持、是否开启、有没有进安全模式 | 总开关、Zygote 状态、诊断导出 |
首页截图适合让别人快速了解环境，但别只发截图。完整版本字符串和日志才方便搜索。
超级用户
这里决定哪些应用能拿 Root。应用弹出请求，不等于你有义务点允许；先看看包名、来源和它到底为什么需要 Root。
尤其留意这些应用：
- 会常驻后台；
- 会监听网络端口；
- 能下载并执行额外脚本；
- 更新后换了来源或签名。
不再使用的测试应用，Root 权限也顺手收回来。授权不是收藏品，不必越攒越多。
App Profile
需要细分权限时，可以设置 UID/GID、附加组、capabilities、SELinux domain、namespace 和 no_new_privs。这套东西很强，也很容易把应用配坏；没明确需求就用默认值。详见 App Profile。
模块卸载
你还可以控制某个应用 namespace 中是否卸载模块挂载。它减少的是应用看到的挂载，不会撤销应用 Root，也不是“打开就检测不到 Root”的保证。
模块页
模块页能做这些事：
- 从 ZIP 安装模块；
- 查看版本、作者和说明；
- 启用、禁用、更新、卸载；
- 运行
action.sh； - 打开 WebUI；
- 查看当前 MetaModule 和待处理状态。
卡片刚出现，只代表文件写进了模块目录。脚本有没有跑、文件有没有挂、功能有没有生效，往往要等重启后才知道。
换 MetaModule 时，先卸载旧后端并重启，再装新的。旧后端还处于待卸载状态时继续叠一个上去，只会让两个后端争同一批模块文件。
YukiZygisk 页
这里可以开关 YukiZygisk、查看 64/32 位 Zygote、模块数量、Native 注入目标、安全模式，以及导出跨重启诊断。
“已开启”“已注入”“模块已加载”“模块功能正常”是四件事。页面能证明前三步中的一部分，最后一步还得去目标应用里看。详见 YukiZygisk 介绍。
LKM 修补与安装
| 入口 | 用途 | 最容易错在哪 |
|---|---|---|
| 直接安装 | 已有 Root 时更新当前槽位 | 分区判断错、当前镜像不匹配 |
| 安装到未使用槽位 | OTA 后给新槽位装 YukiSU | OTA 状态变化、槽位选反 |
| 选择镜像修补 | 生成一份带 YukiSU 的输出镜像 | 输入不是当前固件、镜像类型选错 |
选择本地 .ko | 使用设备专用或自编译 LKM | KMI、符号、配置不匹配 |
| 内置 KMI 资源 | 使用 APK 自带 LKM | 只看名字相似就误选 |
管理器会尽量检测，但最终点“写入”的还是你。开始前按快速开始准备好原厂镜像和恢复方法。
越狱模式
当前还没加载 YukiSU、SELinux 为 Permissive，并且管理器里正好有匹配 KMI 的 LKM 时，首页会出现越狱入口。
已有 Root shell 就直接执行 ksud late-load；没有的话用 Magica 完成第一次引导。它只对当前这次开机有效，模块也要用 late-load.sh 代替早期的 post-fs-data.sh。详见越狱模式。
分区管理器
它可以查看分区、批量或单独备份、刷写镜像，也能运行受支持的 AnyKernel3 包。
备份
备份结束后看一眼文件大小、保存位置和能否读取。一个 0 字节文件就算名字叫“原厂完整备份”，真出事时也救不了你。
刷写
刷写会直接改分区。文件、分区名、容量和槽位都要核对，不要把别的机型教程里的目标原样抄过来。
AnyKernel3
管理器只是执行包里的脚本，不会替包作者担保。运行前看来源、支持设备、目标分区和卸载方式；能选择这个 ZIP，不代表它适合当前设备。
Ramdisk Editor
Ramdisk Editor 通过 ksud 打开、修改和重新打包受支持的启动镜像。它适合知道自己要改哪个文件的人，不是拿来在启动镜像里随便逛的 Root 文件管理器。
输出保存后，还要确认来源镜像、重新打包结果和目标分区。开发协议见 Ramdisk Editor 协议。
更新时看清版本
一套环境里可能同时有：
- 管理器 APK；
- APK 内置
ksud； - 设备已安装
ksud； - LKM 与 KMI；
- MetaModule 和普通模块；
- YukiZygisk 用户空间组件。
所以“我管理器已经最新版”不能说明整套环境都最新版。更新后先看首页，再决定要不要同步 ksud 或更新 LKM。正式版只从 YukiSU Releases 获取。
哪些按钮会真改设备
下面这些操作不是看看而已：
- 直接安装、安装到未使用槽位；
- 刷写镜像或分区；
- 运行 AnyKernel3；
- 永久卸载 YukiSU；
- 同步设备侧
ksud； - 安装、更新、禁用或卸载模块；
- 修改 SuperKey、签名认证、ADB root 或 SELinux 相关设置。
动手前留日志和原厂镜像，做完后检查对应功能。弹出“成功”只说明这一步没报告错误，不等于下一次启动一定成功。
管理器最大的用处不是把按钮塞在一起，而是让 LKM、认证、ksud、模块和 YukiZygisk 的状态分别可见。先看是哪层坏了，再修哪层，省得模块没挂载却跑去重刷 LKM。