Basics & Common Knowledge

About 1379 wordsAbout 5 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.

This covers original and all its forks.

When using , patches ramdisk to load kernel modules, location same as Magisk.

When using , requires kernel source code to rebuild Kernel to use . The modified partition is boot.

& FolkPatch

is based on secondary development. Its patching point is kernel, which is the boot partition.

重要

At all times, the partition patched by /FolkPatch is boot. Unless Google changes the kernel location in the future, it will always be boot. Patching init_boot is an invalid operation.

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.

This covers original and all its forks that have followed up with Meta Module.

Considering that has switched to Meta Module for mounting, only some Meta Module are briefly discussed here.

Meta-Overlayfs

The mounting implementation maintained by official, based on Linux Kernel's Overlayfs file system implementation, theoretically has better performance and stealthiness than Magic Mount.

Meta- (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.

& FolkPatch

has removed its built-in mount system in new versions. Meta Module installation is required for module mounting. The specific mount method is determined by the installed meta module (such as , bind mount, etc.).

does not have built-in .

FolkPatch

FolkPatch extends the mounting system on top of , providing more options:

1. Built-in

FolkPatch adds a Magisk-like (bind mount) mechanism as a built-in feature. When enabled, FolkPatch uses its own mount engine to handle the module's system directory mounting, without relying on external modules.

Controlled by the /data/adb/.magic_mount_enable marker file
Mount source directory is /data/adb/ap/magic_mount
Enable via Settings -> General -> Enable Mount System

2. Meta Module

FolkPatch also introduces Meta Module support. Meta modules are special modules that can take over FolkPatch's core behaviors, declared in module.prop with metamodule=1 or metamodule=true.

After installation, meta modules are linked to the /data/adb/metamodule/ directory, providing the following hooks:

Mount Takeover: Takes over the default mounting logic via metamount.sh (note: not mount.sh)
Install Takeover: Takes over the installation process of ordinary modules via metainstall.sh
Uninstall Takeover: Takes over the module uninstallation process via metauninstall.sh

This enables FolkPatch to extend its underlying capabilities through community-developed meta modules, like .

提示

Built-in and Meta Module should not be used simultaneously. Choose one or the other.

3. Default Mode (No Mount)

Starting from the new version, FolkPatch defaults to not mounting module files. When the mount system is disabled and no meta module is installed, FolkPatch retains only core functions such as Root permission management, without performing any file mounting. This was previously called "Lite Mode" but is now simply the default behavior.

Users who need module mounting must explicitly enable either Built-in or install a meta module.

Comparison with APatch

has removed its built-in mount system in new versions, but still supports meta modules. FolkPatch differs from by additionally retaining built-in as an optional feature that users can enable when needed.

Manager Authentication Mechanism

The manager needs to communicate with in the kernel to perform root operations. The authentication method determines how the manager proves its identity to the kernel.

Signature Verification

The new version of FolkPatch is synced with and uses a signature verification scheme. The kernel verifies the manager APK's signing certificate to confirm the manager's identity, without requiring the user to manually enter a password.

When signature verification passes, the manager can authenticate directly without relying on any key.

SuperKey

SuperKey is the traditional password-based authentication method. Users set a password when patching the boot image, and the manager must enter this password after startup to communicate with the kernel.

Differences Between FolkPatch and

Item	FolkPatch
Signature Verification	Supported	Supported
SuperKey Patching	Supported (optional)	Removed
Authentication Priority	Signature verification preferred	Signature verification only

: The new manager has completely removed the SuperKey patching feature and can only authenticate through signature verification.

FolkPatch: Retains both signature verification and SuperKey. Even when SuperKey mode is selected, signature verification is prioritized when it passes. SuperKey serves only as a fallback.

提示

Most users don't need to worry about the authentication method, as signature verification is completed automatically. Manual SuperKey input is only needed when signature verification fails (e.g., the manager has been re-signed or a non-official build is used).

About Legacy KPimg

FolkPatch supports patching legacy KPimg files, but note the following:

Version 0.13.1 and above: Supports signature verification, the manager can authenticate automatically
Version 0.13.0 and below: Does not include signature verification, SuperKey is required for authentication

Signature verification was introduced in 0.13.1. When using earlier KPimg versions, make sure SuperKey is set.

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.

Material Design 3 Expressive

The latest version of FolkPatch adopts Google's Material Design 3 Expressive (MD3E) design language, with the following major changes:

Large rounded corner cards: Settings items, module cards, etc. uniformly use 32dp corner radius (standard M3 is 12dp), making the interface softer and rounder
Wavy progress indicators: Loading animations and download progress use a wavy style, replacing traditional circular/bar progress indicators
Expanding floating action button: The action buttons on the module management page use MD3E's FloatingActionButtonMenu, which fans out into a menu when tapped
Shape morphing: The selected color in the theme color picker morphs from a circle to a 9-sided cookie shape (Cookie9Sided), using MD3E's shape morphing API

Copyright

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