Basics & Common Knowledge
About 606 wordsAbout 2 min
2025-1-3
Patching Points of Root Solutions
Magisk
Magisk patches ramdisk, which is located in the boot partition before splitting, and in the init_boot partition after splitting.
提示
If there is init_boot, patch init_boot; if not, patch boot.
KernelSU
This covers original KernelSU and all its forks.
LKM
When using LKM, KernelSU patches ramdisk to load kernel modules, location same as Magisk.
GKI
When using GKI, KernelSU requires kernel source code to rebuild Kernel to use GKI. The modified partition is boot.
Apatch & FolkPatch
Apatch is based on KernelPatch secondary development, its patching point is kernel, which is the boot partition.
重要
At all times, the partition patched by Apatch is boot. Unless Google changes the kernel location in the future, it will always be boot. Patching init_boot is an invalid patch.
Mounting
Magisk
The mounting mechanism used by Magisk is generally called Magic Mount, which is built into the Magisk core. It allows you to modify non-writable partitions (EROFS:system) without actually modifying system files.
重要
You can indeed use modules like Mountify to make Magisk support Overlayfs mounting, but this is generally pointless.
KernelSU
This covers original KernelSU and all its forks that have followed up with Meta Module.
Considering that KernelSU has switched to Meta Module for mounting, only some Meta Module are briefly discussed here.
Meta-Overlayfs
The mounting implementation maintained by KernelSU official, based on Linux Kernel's Overlayfs file system implementation, theoretically has better performance and stealthiness than Magic Mount.
Meta-Magic Mount (rs)
Can be compared to Magisk's Magic Mount mounting implementation, implementing more functions on this basis.
Meta-Hybrid Mount
Provides both Overlayfs & Magic Mount mounting implementations. Considering its special HymoFS has been temporarily removed, it has no advantage compared to other Meta Module.
Apatch & FolkPatch
提示
FolkPatch has now officially introduced Meta Module support.
Meta Module
FolkPatch supports installing special Meta Modules (declared metamodule=1 in module.prop). Meta modules have extremely high permissions and can take over and redefine FolkPatch's core behaviors:
- Mount Takeover: Take over the default mounting logic via
mount.sh, for example, implementing anOverlayFS-based mounting mechanism to provide better performance or compatibility than the defaultMagic Mount. - Install Takeover: Take over the installation process of ordinary modules via
metainstall.sh, allowing custom module installation methods. - Uninstall Takeover: Take over the module uninstallation process via
metauninstall.sh.
This enables FolkPatch to extend its underlying capabilities through community-developed meta modules, like KernelSU, such as supporting OverlayFS mounting or other advanced features, without modifying FolkPatch core code.
Module Conflicts
Do you often wonder whether a certain module conflicts with another?
First, we need to understand why modules conflict:
- Mounting or modifying the same system files
- Modifying the same system properties
- Overlapping module scopes
Their modifications will be overwritten based on loading order, causing one side's modifications to not take effect, or even preventing the system from booting.
How to Determine Conflicts
- Same type of modules, such as
Zygisk implementations,Meta Modules,Schedulers,Tombstones—these modules usually don't and can't be compatible, so only one can be used. - Various modules with duplicate functions, for example:
Background Optimizationmodules may conflict withNoactive's background optimization feature because they both modify the system'soom_adj. - Modules that require mounting, such as
Fonts,Thermal Control, can only use one at a time.
重要
If the original author has made special notes about module compatibility, then defer to the original author.
Copyright
Copyright Ownership:FolkPatch Team
License under:Attribution 4.0 International (CC-BY-4.0)
