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.

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 an OverlayFS-based mounting mechanism to provide better performance or compatibility than the default Magic 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 Optimization modules may conflict with Noactive's background optimization feature because they both modify the system's oom_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

License under:Attribution 4.0 International (CC-BY-4.0)