If you want to root an Android phone in 2026, the real decision behind magisk vs kernelsu (and the third contender, APatch) is rarely "which one is best" in the abstract. It is "which one actually works on my exact device, and what am I trading away to get it." All three are mature, actively maintained root managers, but they patch your phone in very different places, support different hardware, and behave differently when you later want to hide root from a banking app. This guide explains how each one works, where each shines, and the honest risks before you unlock anything.
A blunt warning up front, because this content can brick a device: rooting requires unlocking the bootloader, and on almost every phone that wipes all your data and is partly or wholly irreversible. Back up everything first. It also voids warranty, can break OTA updates and some banking or payment apps, and meaningfully expands your device's attack surface. Read the risks section before you act.
What a root manager actually does
"Rooting" means giving apps (with your permission) superuser access to the Android system. A root manager is the tool that grants and controls that access, and that hosts modules — small packages that tweak the system without permanently editing it. The three managers differ mainly in where they hook into the system:
- Magisk patches the boot image in userspace. It is the classic, broadest-compatibility approach.
- KernelSU (and its forks) operates at the kernel level, giving the tightest control over which apps can even see that root exists.
- APatch sits in between: it patches the boot image like Magisk, but injects kernel patches at runtime, without rebuilding the kernel.
Every one of them needs an unlocked bootloader. None can work on a device that cannot be unlocked at all (more on Samsung below).
Magisk: the default for most people
Magisk, maintained by topjohnwu, is the long-standing standard. It works by patching your phone's boot image (or init_boot on newer devices) and running in userspace, which is why it supports the widest range of hardware regardless of kernel version. The latest stable is v30.7 (released around February 2026), which adds Android 16 QPR2 sepolicy support, Zygisk support for Android XR, and other fixes; the project has rewritten a large share of its native code in Rust over recent releases. (Note: vendor_boot partition support actually arrived back in v30.3, not v30.7 — worth knowing if you are chasing a specific feature.)
Magisk's strengths are its enormous module ecosystem (by far the largest of the three) and its built-in hiding tooling: Zygisk (its Zygote-injection framework), a DenyList, and the option to hide the Magisk app itself. For a first-time rooter on a mainstream phone — a Pixel especially — Magisk is the path of least resistance.
There is also Magisk Alpha, a bleeding-edge community build that ships hiding and Zygisk fixes ahead of stable. It is popular with people chasing maximum stealth, but it is unofficial; treat it as advanced-user territory.
KernelSU and its forks: kernel-level control
KernelSU takes a fundamentally different approach: root lives in the kernel itself, which gives it a cleaner permission model and strong app isolation. The trade-off is hardware support. The original KernelSU (tiann/KernelSU) dropped non-GKI support and now officially targets GKI kernels 5.10 and newer only — which in practice means phones that launched on Android 12 or later.
Most people today actually use a fork rather than the original:
- KernelSU-Next (KSUN) — the most active fork, latest v3.2.0 (April 2026). It supports GKI 5.10–6.6 and, in LTS mode, even non-GKI 4.4–5.4 kernels, and ships pre-built GKI images. It also offers an LKM mode on supported GKI devices that injects a loadable kernel module into the boot image without replacing the whole kernel — a simpler install and a much easier OTA path. (LKM mode requires a GKI kernel with LKM support; it is not available everywhere.)
- SukiSU-Ultra — another active fork that adds KPM (kernel patch module) support ported from APatch and focuses heavily on SUSFS-based stealth.
One important behaviour change: KernelSU v3.0+ and the major forks removed built-in module mounting for system-file modifications. If a module needs to modify /system via overlayfs, you must install a metamodule (such as meta-overlayfs) first. Modules that only use scripts, sepolicy rules, system.prop, or service.sh do not need it — so the often-repeated "you must install a metamodule before anything works" is an overstatement.
APatch: the flexible middle ground
APatch (bmax121/APatch) patches the boot image like Magisk but injects kernel patches at runtime, so no kernel rebuild is required. It is ARM64-only and supports a very wide kernel range, currently 3.18–6.12 per the official documentation. That makes it genuinely useful for older or non-GKI devices where KernelSU's original branch will not run but you still want kernel-level capabilities.
APatch supports two module types: APM (Magisk-compatible modules) and KPM (kernel-space modules). It is very much alive — the latest tagged build is from June 2026, so anyone who tells you APatch "died in 2024" is working from stale information. During install you set a SuperKey — a password you choose inside the APatch Manager (8–63 characters). There is no "SuperKey file" to download; if a guide tells you to fetch one, that guide is wrong.
Magisk vs KernelSU vs APatch: comparison table
| Aspect | Magisk | KernelSU / forks | APatch |
|---|---|---|---|
| Where it hooks | Boot image, userspace | Kernel | Boot image + runtime kernel patches |
| Kernel rebuild needed | No | Sometimes (GKI image / LKM mode avoids it) | No |
| Device support | Broadest | GKI 5.10+ (KSUN adds 4.4–5.4 LTS) | ARM64, kernel 3.18–6.12 |
| Module ecosystem | Largest | Smaller, mostly Magisk-compatible | Smallest (APM + KPM) |
| Built-in Zygisk | Yes | No — needs ZygiskNext | No — needs ZygiskNext |
| Deepest hiding | Zygisk + DenyList + Shamiko | + SUSFS (KSUN / SukiSU-Ultra) | ZygiskNext-based |
| Best for | Beginners, mainstream phones | Newer devices, max stealth | Older/non-GKI ARM64 devices |
One thing that catches people out: you cannot run Magisk and KernelSU/APatch on the same slot at once. KernelSU's module system conflicts with Magisk's magic mount, so one will simply stop working. Pick one per device.
Hiding root, banking apps and Play Integrity in 2026
This is where most readers' real question lives, so let's be precise and honest. Hiding root is an ongoing arms race; nothing here is guaranteed against any specific app, and detection logic changes server-side without warning.
The typical hiding stack is: Zygisk (built into Magisk, or ZygiskNext for KernelSU/APatch), plus a Play Integrity spoofing module, plus a hiding module such as Shamiko or the FOSS Zygisk-Assistant, plus adding sensitive apps to the DenyList or app profiles. KernelSU-Next and SukiSU-Ultra additionally support SUSFS, a kernel-level layer that hides root mount points and traces inside the kernel rather than userspace — currently the strongest stealth method available, and a genuine advantage of the kernel-based managers.
Google grades devices on three Play Integrity tiers. With the right stack, Basic and Device integrity are achievable on a rooted phone. Strong integrity is essentially closed to rooted devices: it requires hardware-backed key attestation, and Google completed its mandatory RKP (remote key provisioning) migration by April 2026. That made older leaked OEM keyboxes non-functional on hardware that supports RKP — which broadly means devices that shipped with Android 13 or later, not merely devices upgraded to it. A small but growing set of apps demand Strong integrity, and on those, rooted devices currently cannot pass.
On keyboxes: a keybox is a device-specific key provisioned in the TEE at manufacture. It cannot be extracted from a phone, so anyone selling an "extracted keybox" is running a scam. Valid keyboxes get revoked, and we won't promise any method defeats a particular bank.
The real risks before you root
- Data wipe. Unlocking the bootloader factory-resets the device on all major OEMs. Back up first.
- Bricking. A wrong or mismatched boot image causes a bootloop (usually recoverable by flashing the stock image — keep it). Xiaomi's Anti-Rollback Protection can cause a permanent lockout if you downgrade firmware; check ARB before flashing anything older.
- Samsung Knox e-fuse. Unlocking any unlockable Samsung permanently trips the Knox fuse, killing Samsung Pay, Secure Folder and some enterprise features forever — even if you re-lock.
- Newer Samsung cannot be rooted at all. Devices shipped with or updated to One UI 8 (Android 16) have had bootloader unlock removed from the bootloader binary. This is a firmware-level block, not a hidden toggle. It affects new purchases in that era and older devices that update to One UI 8.
- OTA and warranty. Updates need a tool-specific procedure or your phone may not boot; rooting voids warranty on virtually every OEM.
- Security. Root means any app you grant su to has full control, and a malicious kernel module has kernel-level access. Only install modules from sources you trust.
- Certification loss. Unlocked devices may show "Device not certified" and lose some DRM content (e.g. HD streaming).
Which root manager should you choose?
Remember you are modifying your own device, and the right answer depends entirely on your hardware and goals:
- Mainstream phone, first time, want the biggest module library? Choose Magisk. On a Pixel (Android 13+), patch init_boot.img, not boot.img.
- Newer GKI device (Android 12+) wanting the cleanest model and best stealth? Choose KernelSU-Next, and add SUSFS if hiding matters. LKM mode makes OTA updates far less painful.
- Older or non-GKI ARM64 device that KernelSU original won't touch? Choose APatch — no kernel rebuild and a wide kernel range.
If all of this sounds like a lot of careful, device-specific work — it is. Rooting properly means matching firmware exactly, keeping recovery images, and accepting the trade-offs. If you mainly want a private, de-Googled phone without the risk of bricking your daily driver, PrivacyPortal sells phones set up for privacy out of the box, and we are happy to advise on whether rooting your specific model is even worth it before you wipe anything.
Frequently asked questions
Is KernelSU better than Magisk for hiding root?
It can be, because KernelSU-Next and SukiSU-Ultra support SUSFS, a kernel-level hiding layer Magisk cannot match in userspace. But Magisk with Zygisk + Shamiko still hides from many apps. Neither is guaranteed against a given bank, and Strong integrity is out of reach for both on RKP devices.
Can I switch from Magisk to KernelSU later?
Yes, but not on the same slot at the same time. You fully uninstall one, then install the other's patched boot/kernel image. They conflict if both are active.
Is APatch dead?
No. Despite a quiet patch in 2024, APatch received updates well into 2026 (latest build June 2026) and remains a strong option for older ARM64 and non-GKI devices.
Can I root the latest Samsung Galaxy?
No. Devices on One UI 8 (Android 16) cannot have their bootloaders unlocked at all, so no root manager can run on them. Older, already-unlocked Samsungs are unaffected but have already tripped the Knox fuse.
Will rooting break my banking app?
It might. Hiding stacks help, but app developers update detection server-side, and some apps (certain MDM, government and crypto apps) use detection current modules cannot bypass. Expect occasional breakage that needs module updates.
Modules, apps & files to try
Here are the actual tools the rooting community uses for this, each linked to its official source. They're third-party community projects, so download only from the official page below, back up your boot.img first, and follow each project's own instructions. PrivacyPortal isn't affiliated with these projects and can't guarantee third-party files — flash at your own risk.
| File | What it is & how to use it safely |
|---|---|
| Magisk (GITHUB) | The original and most widely used Android root manager; systemless root via boot-image patching, with built-in Zygisk, a module system and a DenyList for hiding root. Download ONLY from the official repo github.com/topjohnwu/Magisk — its README states GitHub is the sole official source, and third-party "Magisk Manager" sites/APKs are frequently repackaged with malware. Rooting trips Play Integrity and can brick a device: back up your stock boot.img before patching/flashing, and never flash a Magisk ZIP/APK obtained from a Telegram link or random mirror. |
| KernelSU (GITHUB) | Kernel-based root manager that grants root from inside a kernel module rather than patching the boot image; no native Zygisk, so it pairs with a Zygisk add-on. Confirmed the official open-source repo (verified against kernelsu.org, which links to it). Kernel-based root — it requires a compatible/GKI kernel, so it is more device-specific than Magisk: back up your boot.img/stock firmware before flashing and only download the manager APK and kernel from this GitHub Releases page, never from APK mirrors or Telegram. It ships no native Zygisk, so pair it with a Zygisk add-on. Note a separate community fork, KernelSU-Next, also exists; this entry covers the original. |
| APatch (GITHUB) | Kernel-level root manager that patches the kernel binary directly and adds its own KPM (Kernel Patch Module) system; a third path distinct from Magisk's init-based and KernelSU's module-based root. Legitimate open-source kernel-based root manager (GPL-3.0, ~7.6k stars), distinct from Magisk/KernelSU. Only download from this official GitHub repo (or F-Droid / apatch.dev) — never third-party APK mirrors or Telegram reposts. Because it patches the kernel directly, ALWAYS back up your stock boot.img before flashing, set a strong superkey (early versions had weak superkey handling that allowed privilege escalation), and keep it updated. Rooting trips banking/Play Integrity checks and carries a real bootloop/brick risk. |
| SukiSU-Ultra (GITHUB) | A KernelSU fork that adds KPM (Kernel Patch Module) support and auto-updating GKI builds, blending KernelSU's model with APatch-style kernel patch modules. Real, actively maintained open-source KernelSU fork (KPM + built-in SUSFS). It is a kernel/boot-image root solution, so it requires flashing a patched kernel — always back up your stock boot.img first, match the exact build to your device/kernel, and download ONLY from the official GitHub releases page (github.com/SukiSU-Ultra/SukiSU-Ultra). Ignore any Telegram or third-party mirror links. |
| Zygisk Next (GITHUB) | A standalone reimplementation of Magisk's Zygisk (Zygote injection framework) packaged as a module, enabling Zygisk modules like LSPosed and Shamiko to run on KernelSU and APatch. Reputable, widely-used open-source root module (~9.8k GitHub stars, latest v1.4.0 from 2026, also listed in the official KernelSU module registry). Only download from the official GitHub Releases page and verify the published SHA256 checksum. As with any boot-time root module, back up your boot.img / take a Magisk backup before flashing so you can recover from a bootloop. Note: recent versions moved from GPL-3.0 to a more restrictive license, but it remains free to download and use. |
| KernelSU-Next (KSUN) (GITHUB) | Actively maintained KernelSU successor/fork by RifsxD with enhanced root hiding, magic mount, manual-hook support for non-GKI kernels, and integrated SUSFS GKI image support. Legitimate open-source (GPL) KernelSU fork — the candidate link rifsxd/KernelSU-Next 301-redirects to the canonical org repo. Actively maintained (v3.2.0, April 2026). Kernel-level root is high-risk: back up your boot.img before flashing, match the manager and kernel module versions, and download ONLY from this official GitHub repo/releases page (or the official kernelsu-next.github.io docs) — never from Telegram or mirror sites. Note the wider KernelSU ecosystem had a manager-impersonation root flaw in an old version, so always run a current release. |
