Magisk vs KernelSU vs APatch
Root frameworks change quickly. Use this page to choose a method, then verify device-specific instructions and current requirements in the official docs before flashing anything.
Related guides:
Before you root
Unlocking the bootloader usually wipes data, weakens device security, and can break OTA, warranty, DRM, wallet, banking, and work-profile apps. Keep a stock firmware package and recovery plan ready.
Quick recommendation
| If you want... | Choose | Why |
|---|---|---|
| The safest default for most devices | Magisk | Broad compatibility, largest module ecosystem, easiest troubleshooting |
| Kernel-level root with strong per-app control | KernelSU | Root runs in kernel space; App Profiles can restrict UID, groups, capabilities, and SELinux rules |
| A KernelPatch-based alternative | APatch | Useful on compatible ARM64 devices, especially when you want APModule/KPModule support |
| Maximum reliability for banking, wallet, enterprise, or anti-cheat apps | No root | No framework can guarantee Play Integrity or app-specific checks |
Quick comparison
| Area | Magisk | KernelSU | APatch |
|---|---|---|---|
| Install model | Patches the correct boot-related image for your device | Uses a supported kernel path, usually GKI/LKM or a built kernel | Patches the stock boot.img using KernelPatch |
| Best for | Beginners, daily drivers, module-heavy setups | Power users, developers, supported GKI/custom kernels | Advanced users and edge cases |
| Main requirement | Unlocked bootloader + exact stock image | Supported kernel/KMI path; Manager must show support | ARM64 + KernelPatch-compatible kernel + required KALLSYMS config |
| Modules | Magisk modules, Zygisk modules | Metamodule-based system; many Magisk modules need a compatible metamodule | APModule plus KPModule for kernel-level code |
| Root control | App-based MagiskSU prompts | App Profiles with fine-grained privileges | SuperKey-based access control |
| Hiding / integrity | Community tooling only; no guarantees | Often less visible to apps, but no guarantee | Often less visible to apps, but no guarantee |
| OTA behavior | Usually needs restore/re-patch or inactive-slot flow | LKM setups can be more OTA-friendly, but not guaranteed | OTA support depends on device and install path |
| Troubleshooting | Easiest; largest community | Medium; kernel knowledge helps | Hardest; smaller ecosystem |
| Latest Version |  |  |  |
Framework notes
Magisk
Best default. Magisk is the most mature and widely documented root solution. It provides MagiskSU, Magisk modules, MagiskBoot, and optional Zygisk for running code in app processes.
Use Magisk when:
- You are rooting for the first time.
- You need the highest chance that guides, modules, and fixes already exist for your device.
- You want the simplest recovery path if a module bootloops the device.
Watch out for:
- You must patch the correct image for your device (
boot.img,init_boot.img, or recovery image depending on layout). - Do not flash patched images made by someone else.
- Root hiding is not a built-in guarantee; Play Integrity and app detections change constantly.
KernelSU
Best for supported kernels. KernelSU grants root from kernel space and lets only permitted apps access or see su. Its App Profiles allow tighter control than classic app-based superuser prompts.
Use KernelSU when:
- Your device/kernel is supported, or you can build/use a trusted KernelSU-enabled kernel.
- You want fine-grained root profiles and kernel-level control.
- You are comfortable with KMI, boot images, and kernel-specific recovery.
Watch out for:
- Module mounting is handled by metamodules, so fresh installs need a suitable metamodule for systemless modifications.
- Kernel/KMI mismatch can bootloop.
- Some OEM security stacks and kernels may block specific install modes.
APatch
Best as an advanced alternative. APatch is KernelPatch-based, runs root control in kernel space, and supports APModule plus KPModule for kernel code injection.
Use APatch when:
- Your ARM64 device meets APatch requirements.
- You specifically need APModule/KPModule or KernelPatch behavior.
- Magisk or KernelSU is not a good fit for your firmware.
Watch out for:
- APatch patches
boot.img; do not patchinit_boot.imgor random images. - SuperKey is higher-risk than a normal root password: use a strong, private key.
- Compatibility depends heavily on kernel config and device/OEM behavior.
Device guidance
Choose by bootloader unlockability, firmware availability, kernel support, and recovery options - not by brand alone.
| Device family | Practical guidance |
|---|---|
| Google Pixel | Magisk is usually easiest. KernelSU is good if a supported kernel path exists. |
| Samsung Galaxy | Research carefully. Installing root can permanently trip Knox-related protections, and some regional variants cannot unlock. KernelSU LKM may not work on Knox-protected devices. |
| Xiaomi / Redmi / POCO | Magisk is the usual starting point. KernelSU/APatch depend on ROM, kernel, and bootloader status. |
| OnePlus / Nothing | Generally root-friendly when unlockable; Magisk first, KernelSU if the kernel path is supported. |
| Motorola / ASUS | Unlock policy and firmware access vary by model/region. Keep exact stock images before flashing. |
| OPPO / Realme / vivo / Honor | Bootloader access is often the main blocker. Verify current regional policy before planning root. |
Samsung Knox
On Knox-protected Samsung devices, rooting/custom binaries can permanently break Knox-dependent features such as Samsung Wallet/Pay, Secure Folder, and Samsung Pass. Relocking or flashing stock firmware normally does not restore them.
Play Integrity and root detection
No root framework can promise that banking, wallet, streaming, work-profile, or anti-cheat apps will keep working.
- Basic checks may pass or fail depending on ROM, fingerprint, root traces, and current detections.
- Device/strong integrity are much harder because they depend on Google/OEM trust signals such as verified boot state, certified firmware, and hardware-backed proof.
- Community modules may help temporarily, but they are a cat-and-mouse game. Do not buy a device or choose a framework based only on bypass claims.
If those apps matter more than root, keep one unrooted phone.
Safe install checklist
Before installing or migrating:
- [ ] Back up internal storage and app data.
- [ ] Download the exact current firmware for your build.
- [ ] Save stock
boot.img,init_boot.img,vendor_boot.img,vbmeta.img, and recovery image if present. - [ ] Confirm bootloader unlock steps and whether unlock wipes data.
- [ ] Confirm fastboot/download-mode access and restore commands.
- [ ] Read your device forum/group for known bootloops, slot issues, and OTA quirks.
- [ ] Install only one root framework at a time.
Migration guide
Do not stack root frameworks
Switch cleanly. Mixing patched images, modules, and managers from multiple frameworks is a common cause of bootloops and broken OTAs.
Magisk → KernelSU
- Export module list and app root settings.
- Disable/uninstall risky modules.
- Restore stock boot-related image or fully uninstall Magisk.
- Install the KernelSU-compatible kernel/LKM path for your device.
- Install KernelSU Manager.
- Install a compatible metamodule if you need systemless modules.
- Reinstall modules one at a time and configure App Profiles.
Magisk → APatch
- Back up and keep your current stock
boot.img. - Fully uninstall Magisk or restore stock boot image.
- Patch the stock
boot.imgwith APatch Manager. - Set a strong SuperKey and keep it private.
- Flash the patched
boot.img. - Test root before adding modules.
KernelSU/APatch → Magisk
- Remove modules and document app permissions.
- Restore stock boot-related images or flash the ROM's clean kernel/boot image.
- Patch the correct image with Magisk on the target device.
- Flash, boot, then reinstall only needed modules.
Decision checklist
Pick Magisk if any of these are true:
- You are new to rooting.
- You rely on many Magisk/Zygisk modules.
- You want the largest support community.
- You are unsure what kernel your device uses.
Pick KernelSU if all of these are true:
- Your device has a known-good supported kernel path.
- You understand KMI/kernel compatibility.
- You want stronger per-app root isolation and profiles.
Pick APatch if all of these are true:
- Your device is ARM64 and APatch-compatible.
- You understand the SuperKey risk.
- You need APModule/KPModule or KernelPatch features.
Pick no root if:
- Banking/wallet/enterprise/anti-cheat reliability matters more than customization.
- You cannot restore stock firmware yourself.
- Losing data or warranty is unacceptable.
FAQ
Which is best overall?
Magisk for most users. KernelSU for supported-kernel power users. APatch for advanced KernelPatch use cases.
Which hides root best?
None reliably. Kernel-level approaches can reduce some userspace traces, but modern apps use many signals beyond su visibility.
Do Magisk modules work on KernelSU/APatch?
Some do, some do not. Mounting method, Zygisk needs, SELinux changes, and service scripts matter. Test one module at a time.
Will OTA updates work?
Sometimes. Always assume root may need to be restored after OTA and keep stock images for both slots when relevant.
Can I relock the bootloader after rooting?
Usually no. Relocking with modified partitions can brick or wipe the device. Return fully stock first and follow device-specific instructions.
Official resources
- Magisk: GitHub · Docs · Install guide
- KernelSU: GitHub · Docs · Installation · Metamodules
- APatch: GitHub · Docs · Installation
- Google: Play Integrity verdicts
Final rule
When in doubt, start with Magisk - unless your device community specifically recommends KernelSU or APatch for your exact model, ROM, and kernel.