FolkPatch: a KernelPatch-based root manager for ARM64 Android

The root implementation is a kernel patch, not a recompiled kernel

FolkPatch is a root management application built on KernelPatch, another project by the same author, and that dependency defines what the tool is. The README states that root access to the kernel is achieved by patching the boot partition for reflashing, and the project description adds that the solution is based on a non-parallel extended branch of APatch with a primary focus on UI and UX design. The feature list puts it plainly: KernelPatch-based root without recompiling the kernel. That is the key difference from an approach that requires building a custom kernel, and it is why the README lists a supported kernel range of 3.18 through 6.15 alongside the requirement of an ARM64 Android device and a supported KernelPatch installation.

Three extension systems, each with a different privilege level

The manager is really three plugin systems that are commonly conflated. APM is described as providing a Magisk-like system module system, with installation, removal, enable and disable controls, batch operations and full backups, and the credits name Magisk for magiskpolicy and KernelSU for the application interface and module system reference. KPM is kernel module support, covering inline-hook and syscall-table-hook use cases, with automatic module loading. APD is the lightweight plugin layer, running Lua scripts in the apd lifecycle without modifying system files or injecting a kernel module, with configuration, quick actions, background daemons and persistent logs. The APM and KPM paths change the system and the kernel respectively, while an APD plugin stays in userspace, and the documentation keeps that distinction explicit with separate plugin pages in English and Chinese.

Runtime controls are the part with real consequences

Beyond modules, the application exposes runtime controls that act on the running system: network isolation, path hiding, kernel spoofing, mount hiding and unmount policies. These are the features a user reaches for when an app detects root or refuses to run, and they are also the features that make the tool controversial, since kernel spoofing exists to defeat detection. The README does not soften this, and the installation instructions explicitly tell the user to read the documentation before enabling runtime controls, which is a sensible ordering given the combination of privileges involved. Shizuku service management and startup integration are also included, meaning the manager can drive a Shizuku service rather than only root-level operations.

The interface is the project's stated focus

The project description says the primary focus is on UI and UX design, and the README backs that with a full list of home layouts: ListUI, GridUI, FocusUI, CircleUI, DashboardUI and StatsUI, with FocusUI as the default for new installations. Alongside that there are system theme colours, custom colours, wallpapers and custom fonts, configurable navigation styles and dashboard cards, and optional automatic update checks. Themes, wallpapers, fonts and multiple home layouts are all described as importable. The credits name SukiSU-Ultra as the interface design reference and MMRL as the module repository format reference, and the root directory confirms a Gradle project with fastlane/ for distribution and an examples/plugins/ directory holding plugin examples.

The SuperKey is a credential, not a feature

The security section is short and blunt. The SuperKey has higher privileges than a normal root session, a weak or exposed key can allow unauthorized control of the device, and the instruction is to use a strong key and keep it private. That is worth taking at face value, because the failure mode here is not a bug in a plugin but full control of the device by anyone who obtains the key. The root directory shows that this is handled as a build-time concern as well as a runtime one, with auth.properties.template, keystore.properties.template and local.properties.template alongside the build scripts Build-Release.sh, Build-Debug.sh and their Windows equivalents. The templates being checked in as templates rather than real files is the right arrangement for secrets.

Installing means a package, the setup flow, and reading the docs first

The installation path is short, which suits an app that patches the boot partition. You download the latest package from the releases page, install the package on the Android device, and then follow the in-app setup flow, with the instruction to read the documentation before installing modules or enabling runtime controls. The reason that last step is in the list rather than optional is that the boot partition patch and the SuperKey are not recoverable through the app if you get them wrong, so the setup flow and the documentation are the only guide to doing it safely. The project description adds the other half of the method, that root is achieved by patching the Boot partition for reflashing, and the README's requirement of an existing supported KernelPatch installation means the patch is not something the app installs for you from scratch.

Licensing is GPLv3 with an explicit source obligation

The licence section is more specific than most. FolkPatch is licensed under the GNU General Public License v3, and the README spells out the consequence: if you modify FolkPatch or integrate it into another project and distribute the result, the complete project must be released under GPLv3, and binary distributions must provide or promise complete, readable source code. The software is provided without warranty, and any violation terminates the GPLv3 grant. For a manager that people are likely to fork, that last clause is the significant one, since a fork that drops the source obligation is not a permitted distribution. The repository also carries a version.properties file, four README translations, and scripts/ and core/ directories in the tree.

Releases are tagged by build number, and the naming is irregular

The release list gives three recent tags and they do not follow one scheme. Two are numeric, 115357 and 115051, and one is a name, v6 with the suffix Sol, dated 2026-10-04. The numeric ones correspond to the release names FolkPatch and FolkPatch Cipher, and the first release badge in the README points at the latest release page rather than a specific tag. The project publishes a documentation site at fp.mysqil.com and the homepage field points at the same address, and there is a Telegram channel linked from both the badge row and the community section. The last push to the repository was on 2026-10-12, and the project is not archived, so it is being worked on even though the tag naming gives you no way to reason about which build is which.

Editorial conclusion

FolkPatch suits an Android user who already has a KernelPatch installation and wants a single manager for system modules, kernel modules, plugins and the runtime controls, since consolidating those in one UI is the project's stated contribution. It is a poor fit for a device whose kernel falls outside the supported range of 3.18 through 6.15, since the README states that requirement along with an ARM64 device and a supported KernelPatch install, and a poor fit for anyone who cannot read the documentation before enabling runtime controls. Verify first that your exact kernel version and device are covered in the compatibility matrix in the documentation, and treat the SuperKey as a credential, because the README states it carries higher privileges than a normal root session.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LyraVoid/FolkPatch on GitHub
4. README
5. Releases