基础与常识

约 1955 字大约 7 分钟

2025-1-3

各 Root 方案的修补点位

Magisk

Magisk 修补的是 ramdisk，在拆分前位于 boot 分区，拆分后位于 init_boot 分区。

提示

有 init_boot 就修补 init_boot，没有就修补 boot

此处涵盖原版及其所有分支

在使用时修补 ramdisk 以加载内核模块，位置同 Magisk。

在使用时，你需要内核源码以重新构建 Kernel 才可使用，修改的分区为 boot。

& FolkPatch

基于二次开发，其修补的点位为 kernel，也就是 boot 分区。

重要

无论何时，/FolkPatch 修补的分区均为 boot，除非 Google 未来变更 kernel 位置，否则均为 boot。修补 init_boot 为无效操作。

挂载

Magisk

Magisk 使用的挂载机制一般被称为 Magic Mount，其内置在 Magisk 核心中。允许你在不实际修改系统文件的前提下对不可写分区 (EROFS:system) 进行修改。

重要

你确实可以使用类似 Mountify 之类的模块来让 Magisk 支持 Overlayfs 挂载，但这一般毫无意义。

此处涵盖原版及其所有已跟进 Meta Module 的分支。

考虑到已切换至 Meta Module 用于挂载，此处仅简要谈及部分 Meta Module。

Meta-Overlayfs

官方维护的挂载实现，基于 Linux Kernel 的 Overlayfs 文件系统实现，理论拥有比 Magic Mount 更好的性能和隐蔽性。

Meta- (rs)

可类比 Magisk 的 Magic Mount 挂载实现，在此基础上实现了更多功能。

Meta-Hybrid Mount

同时提供了 Overlayfs & Magic Mount 两种挂载实现，考虑到其特殊的 HymoFS 已被暂时移除，相比较其它 Meta Module 并无优势。

& FolkPatch

在新版中移除了内置挂载系统，必须安装元模块才能实现模块挂载。具体的挂载方式由所安装的元模块决定（如、bind mount 等）。

没有内置。

FolkPatch

FolkPatch 在基础上对挂载系统进行了扩展，提供了更多选择：

1. 内置

FolkPatch 新增了类 Magisk 的（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 能够像一样，通过社区开发的元模块来扩展其底层能力。

提示

内置和 Meta Module 不应同时使用。选择其一即可。

3. 默认模式（不挂载）

新版本 FolkPatch 默认不挂载模块文件，仅保留 Root 权限管理等核心功能。如需挂载，需主动开启内置或安装元模块。

与 APatch 的区别

在新版中移除了内置挂载系统，必须使用元模块才能挂载。FolkPatch 保留了内置和元模块两种方案。

管理器认证机制

管理器需要与内核中的通信才能执行 Root 操作。认证方式决定了管理器如何向内核证明自己的身份。

签名验证

新版 FolkPatch 与同步，采用了签名验证方案。内核通过验证管理器 APK 的签名证书来确认管理器身份，无需用户手动输入密码。

当签名验证通过时，管理器可以直接完成认证，不依赖任何密钥。

SuperKey

SuperKey 是传统的密码认证方式，用户在修补 boot 镜像时设置一个密码，管理器启动后需要输入该密码才能与内核通信。

FolkPatch 与的区别

项目	FolkPatch
签名验证	支持	支持
SuperKey 修补	支持（可选）	已移除
认证优先级	签名验证优先	仅签名验证

：新版管理器彻底移除了 SuperKey 修补功能，只能通过签名验证完成认证。

FolkPatch：保留了签名验证和 SuperKey 两种方案。即使选择了 SuperKey 模式，在签名验证通过时也会优先使用签名来认证，SuperKey 仅作为备用。

提示

大部分用户无需关心认证方式，签名验证会自动完成。只有在签名验证失败时（如管理器被重新签名或使用了非官方构建），才需要手动输入 SuperKey。

关于旧版 KPimg

FolkPatch 支持修补旧版的 KPimg 文件，但需要注意：

0.13.1（含）以上版本：支持签名验证，管理器可自动完成认证
0.13.0 及以下版本：不包含签名验证功能，必须使用 SuperKey 才能完成认证

签名验证是在 0.13.1 才引入的，使用更早版本的 KPimg 时请确保已设置 SuperKey。

模块冲突

你是否经常有这种疑惑，即某个模块是否与某个模块冲突？

首先我们需要明确，为什么模块会冲突？

对相同系统文件进行了挂载或修改
对相同系统属性进行了修改
模块作用域重叠

它们的修改会根据加载顺序进行覆盖，导致某一方的修改不生效，甚至导致系统无法启动。

如何判断是否冲突

相同类型模块，例如 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

许可证：署名 4.0 国际 (CC-BY-4.0)