基础与常识
约 2103 字大约 7 分钟
2025-1-3
各 Root 方案的修补点位
Magisk
Magisk 修补的是 ramdisk，在拆分前位于 boot 分区，拆分后位于 init_boot 分区。
提示
有 init_boot 就修补 init_boot，没有就修补 boot
KernelSU
此处涵盖 KernelSU 原版及其所有分支
LKM
KernelSU 在使用 LKM 时修补 ramdisk 以加载内核模块，位置同 Magisk。
GKI
KernelSU 在使用 GKI 时，你需要内核源码以重新构建 Kernel 才可使用 GKI，修改的分区为 boot。
APatch & FolkPatch
APatch 基于 KernelPatch 二次开发，其修补的点位为 kernel，也就是 boot 分区。
重要
无论何时，APatch/FolkPatch 修补的分区均为 boot，除非 Google 未来变更 kernel 位置，否则均为 boot。修补 init_boot 为无效操作。
挂载
Magisk
Magisk 使用的挂载机制一般被称为 Magic Mount，其内置在 Magisk 核心中。允许你在不实际修改系统文件的前提下对不可写分区 (EROFS:system) 进行修改。
重要
你确实可以使用类似 Mountify 之类的模块来让 Magisk 支持 Overlayfs 挂载，但这一般毫无意义。
KernelSU
此处涵盖 KernelSU 原版及其所有已跟进 Meta Module 的分支。
考虑到 KernelSU 已切换至 Meta Module 用于挂载，此处仅简要谈及部分 Meta Module。
Meta-Overlayfs
KernelSU 官方维护的挂载实现，基于 Linux Kernel 的 Overlayfs 文件系统实现，理论拥有比 Magic Mount 更好的性能和隐蔽性。
Meta-Magic Mount (rs)
可类比 Magisk 的 Magic Mount 挂载实现，在此基础上实现了更多功能。
Meta-Hybrid Mount
同时提供了 Overlayfs & Magic Mount 两种挂载实现，考虑到其特殊的 HymoFS 已被暂时移除，相比较其它 Meta Module 并无优势。
APatch & FolkPatch
APatch
APatch 在新版中移除了内置挂载系统，必须安装元模块才能实现模块挂载。具体的挂载方式由所安装的元模块决定（如 OverlayFS、bind mount 等）。
APatch 没有 内置 Magic Mount。
FolkPatch
FolkPatch 在 APatch 基础上对挂载系统进行了扩展，提供了更多选择：
1. 内置 Magic Mount
FolkPatch 新增了类 Magisk 的 Magic Mount（bind mount）挂载机制作为内置功能。启用后，FolkPatch 使用自身的挂载引擎处理模块的 system 目录挂载，无需依赖外部模块。
- 由
/data/adb/.magic_mount_enable标记文件控制 - 挂载源目录为
/data/adb/ap/magic_mount - 通过设置 → 常规 → 启用挂载系统开启
2. Meta Module（元模块）
FolkPatch 同时引入了 Meta Module 支持。元模块是可以接管 FolkPatch 核心行为的特殊模块，在 module.prop 中声明 metamodule=1 或 metamodule=true。
元模块安装后会被链接至 /data/adb/metamodule/ 目录，提供以下钩子：
- 挂载接管：通过
metamount.sh接管默认的挂载逻辑（注意：不是mount.sh） - 安装接管：通过
metainstall.sh接管普通模块的安装过程 - 卸载接管：通过
metauninstall.sh接管模块的卸载过程
这使得 FolkPatch 能够像 KernelSU 一样，通过社区开发的元模块来扩展其底层能力。
提示
内置 Magic Mount 和 Meta Module 不应同时使用。选择其一即可。
3. 默认模式（不挂载）
新版本 FolkPatch 默认不挂载模块文件，仅保留 Root 权限管理等核心功能。如需挂载，需主动开启内置 Magic Mount 或安装元模块。
与 APatch 的区别
APatch 在新版中移除了内置挂载系统，必须使用元模块才能挂载。FolkPatch 保留了内置 Magic Mount 和元模块两种方案。
管理器认证机制
管理器需要与内核中的 KernelPatch 通信才能执行 Root 操作。FolkPatch 4.3 起采用纯签名验证方案，完全移除了 SuperKey 密码认证。
签名验证
内核通过验证管理器 APK 的签名证书来确认管理器身份，无需用户手动输入任何密码。认证过程在开机时自动完成，管理器启动后即可直接与内核通信。
提示
签名验证完全自动化，用户无需任何额外操作。只要使用官方签名管理器，认证即可正常完成。
认证原理
- 开机时，内核主动扫描已安装应用的 APK 签名摘要，与内置的受信任管理器签名表进行匹配
- 签名摘要匹配成功后，内核记录该管理器的 UID，后续所有内核通信均基于此 UID 进行身份验证
- 管理器无需向内核传递任何密码或密钥，仅需通过签名验证获得的 UID 即可完成授权
- 如果管理器被卸载重装，内核记录的旧 UID 会失效，需要重启设备让内核重新扫描并匹配
重装管理器
卸载并重新安装管理器后，由于内核记录的仍是旧管理器的 UID，可能会显示"未安装"或"认证失败"。这是正常现象，重启设备即可恢复。
认证方案历史
| 版本范围 | 认证方式 | 说明 |
|---|---|---|
| FolkPatch 4.3 起 | 纯签名验证 | 完全移除 SuperKey，仅通过 APK 签名摘要验证管理器身份 |
| FolkPatch 4.3 之前 | 签名验证 + SuperKey（可选） | 签名验证优先，SuperKey 作为备用认证方式 |
| KernelPatch ≤ 0.13.0 | 仅 SuperKey | 签名验证尚未引入，必须设置 SuperKey 才能认证 |
如果你从 4.3 之前的版本升级，之前设置的 SuperKey 将不再需要，管理器会自动通过签名验证完成认证。
关于旧版 KPimg
FolkPatch 支持修补旧版 KernelPatch 的 KPimg 文件，但需要注意：
- 0.13.1（含）以上版本：支持签名验证，管理器可自动完成认证
- 0.13.0 及以下版本：不包含签名验证功能，无法完成认证
签名验证是在 KernelPatch 0.13.1 才引入的，使用更早版本的 KPimg 时将无法完成认证，请升级到 0.13.1 或更高版本。
模块冲突
你是否经常有这种疑惑，即某个模块是否与某个模块冲突？
首先我们需要明确，为什么模块会冲突？
- 对相同系统文件进行了挂载或修改
- 对相同系统属性进行了修改
- 模块作用域重叠
它们的修改会根据加载顺序进行覆盖，导致某一方的修改不生效，甚至导致系统无法启动。
如何判断是否冲突
- 相同类型模块，例如
Zygisk 实现、元模块、调度、墓碑，这些模块通常来讲不会，也不能兼容，所以只能使用一个。 - 各种功能重复的模块，例如
后台优化模块会与Noactive的后台优化功能重复，因为它们都修改了系统的oom_adj。 - 需要使用挂载的模块，例如
字体、温控，同样只能使用一个。
重要
如果原作者对模块的兼容性做了特别说明，那么一切以原作者为准。
Material Design 3 Expressive
FolkPatch 新版采用了 Google Material Design 3 Expressive（MD3E）设计语言，主要变化包括：
- 大圆角卡片：设置项、模块卡片等统一使用 32dp 圆角（标准 M3 为 12dp），界面更加柔和圆润
- 波浪进度指示器：加载动画和下载进度使用波浪形（Wavy）样式，替代传统圆形/条形进度条
- 展开式浮动按钮：模块管理页面的操作按钮采用 MD3E 的
FloatingActionButtonMenu，点击展开扇形菜单 - 形状变换：主题色选择器中被选中的颜色会从圆形变换为 9 边饼干形（Cookie9Sided），使用 MD3E 的形状变形 API
版权所有
版权归属：FolkPatch Team