Best Magisk Modules in 2026: Verified Sources, and What's Been Discontinued

Several modules that still appear on current lists no longer exist. Play Integrity Fix was deleted from GitHub by its author. Universal SafetyNet Fix last shipped in January 2023. And the "install from the Magisk app's online repository" step in most guides describes a feature removed from Magisk years ago. Every project below was checked against its own repository before it went on the list, and every one has a link.

Last technically verified: 29 August 2026
Magisk baseline: v30.7 (released 23 February 2026)
Also covers: KernelSU, KernelSU Next, SukiSU Ultra and APatch
Android coverage: 12 to 16, with newer versions noted only where a project explicitly supports them
Sourcing rule: official maintainer links only. We do not mirror module ZIPs

Start here: the short version

Most people want one of four things. You do not need the whole list.

Everything below is detail on those four, plus what to avoid.

What changed, and what to remove

If you are following an older guide, you may be about to install something that no longer exists.

That last row causes the most confusion. People open Magisk looking for the Modules download tab an old guide describes, cannot find it, and assume their install is broken. It is not. Discovery and installation are now separate steps: find the module on GitHub, download the ZIP, install it from storage.

Several popular "modules" are not modules

This matters because it changes where you get the thing and how you fix it when it misbehaves.

All of these are worth using. None of them is something you flash. A guide listing AdAway between two Zygisk modules is teaching a category error, and readers who then go hunting for an "AdAway ZIP" end up on exactly the kind of mirror site this article is steering them away from.

Which root manager are you on?

Magisk is no longer the only option, and which one you run decides what you can install. Modules are broadly portable, but not entirely.

Two things people get wrong here.

You cannot run two at once. Fully remove one, restore the matching stock image, then install the other. Both active at the same time conflicts.

KernelSU forks are not interchangeable. KernelSU, KernelSU Next and SukiSU Ultra share ideas but their managers and kernel changes differ. Use the build made for the fork you actually installed.

A note on Magisk Alpha: it is an unofficial build distributed mainly through Telegram. It has a following, but its public source and release trail are weaker than official Magisk, which matters for something running as root. Official stable is easier to verify.

What works on what

The row that decides the most is SUSFS. It hides inside the kernel rather than in userspace, which userspace modules structurally cannot match, and it does not work with Magisk because Magisk never touches the kernel. That is the main technical argument for moving off Magisk in 2026, and it needs a device with a compatible kernel, which not every device has. Our Magisk vs KernelSU vs APatch comparison covers the trade properly.

Everything in this article works on Magisk. Where something is restricted to one family, it says so.

Before you install anything

Screenshot your current modules. Open your root manager, go to the Modules tab, screenshot the list. That is your record of what changed if something breaks. Five seconds, no terminal needed.

Note your Magisk version and Android build while you are there. Magisk shows its version on the home screen. Android version and security patch are in Settings, under About phone.

One module at a time, then reboot, then check it worked. Install five and reboot once and you have no idea which one broke it.

Know how to recover before you need it. It is at the end of this article. Read it first.

Step 1: pick one Zygisk implementation

Zygisk is the injection layer that hiding modules and the Xposed framework depend on. Magisk has one built in. KernelSU and APatch do not, so those users need a standalone one. Magisk users can also choose a standalone implementation instead of the built-in.

Three rules that between them prevent most of the failures people post about:

Run exactly one. If you install a standalone implementation on Magisk, turn built-in Zygisk off first. Running both is a common and avoidable failure.

Shamiko does not work with ReZygisk. Shamiko targets built-in Zygisk and Zygisk Next. Choose ReZygisk and you need a different hiding module. Mixing them is the classic cause of "my hiding worked yesterday and stopped today." Same goes for Zygisk Assistant.

Uninstall the old one before switching. Migrating without removing the previous module first has caused bootloops, especially across module ID changes.

The Zygisk Next licence change is worth a deliberate decision rather than a default. It is a root-privileged module whose recent releases cannot be independently audited, and that is the stated reason ReZygisk exists. Whether it matters to you is a judgement call, not a technical fault.

Step 2: integrity and hiding, as a decision tree

The most important correction to the previous version of this guide:

Passing Play Integrity and hiding root from an app are two different problems.

Users routinely get every integrity verdict and still have Google Wallet or a specific bank refuse the device, because individual apps look at signals beyond the Play Integrity API. Installing the full stack because a guide called it essential is how people end up with six modules where two would have done.

Work it as a tree. Test after each step.

Start with the DenyList. Built into Magisk, no download. Add the apps you want root hidden from. Plenty of apps stop complaining here and you are finished.

Still detected? Add a hiding module. Shamiko, from the LSPosed release distribution, v1.2.5 as of June 2025 with Android 16 and 16K-page fixes. Note the counterintuitive requirement: Shamiko needs DenyList enforcement turned off while the list itself stays populated. Leaving enforcement on disables Shamiko. This is the single most common misconfiguration in this whole article. On KernelSU with a SUSFS kernel you often do not need Shamiko at all, because the kernel is already doing that job.

Failing an integrity verdict specifically? Add a Play Integrity module. osm0sis/PlayIntegrityFork, v17 as of June 2026, is the direct continuation of the discontinued original and the successor its own author pointed to. KOWX712/PlayIntegrityFix is another maintained fork of the same lineage. Do not install two PIF forks at once.

Only with a concrete key attestation requirement, consider Tricky Store. 5ec1cff/TrickyStore, Android 10+. Forks by beakthoven and qwq233 are also in circulation and are what several tooling projects now target.

To manage which apps it applies to: KOWX712/Tricky-Addon-Update-Target-List gives Tricky Store a proper interface for its target list, keybox and security patch handling. It is a separate project and its author asks that issues not be filed upstream.

Three things other guides do not tell you

Tricky Store has been closed-source since v1.1.0. The maintainer closed it over abuse concerns. Together with the Zygisk Next licence change, the two most powerful tools in this category are now both unauditable binaries running as root. Worth knowing before you install them, not after.

Tricky Store does not ship a working keybox. It ships an AOSP keybox that is not valid for attestation. Guides saying "install Tricky Store, get strong integrity" skip that entirely. Keyboxes also get revoked, at which point your setup quietly stops working. We do not distribute keyboxes and we would be cautious about anyone who does.

Software-backed device integrity got much harder in 2026. A large wave of device fingerprints was blocked early in the year, and the main community repository maintaining that collection was archived by its owner, who said no working fingerprints remained for the most common architecture combinations. Fingerprint approaches have not stopped working, but the supply is not what it was.

The honest read: basic verdicts are broadly achievable, device integrity takes more work than it used to, and strong integrity on an unlocked bootloader is genuinely difficult. Some apps refuse regardless. We do not publish a pass rate, because it would be wrong within weeks.

Want this set up once, correctly, instead of testing combinations for a week? Send us your device, Android version, root method and the apps you need working. We configure it remotely and tell you up front which of your apps are realistically achievable. Free diagnosis on the rooting service.

If you need to ask for help

Integrity behaviour changes constantly, so "does this stack work with my bank" is unanswerable without detail. If you are asking anyone, including us, send this:

Device and exact model:
Android version and build:
Security patch level:
Root manager and version:
Zygisk implementation:
Modules installed, with versions:
Play Integrity verdict:
App and version that is failing:
What exactly it says:

That turns a question nobody can answer into one someone can. We removed the anonymous app-compatibility anecdotes from the previous version of this guide for the same reason: they had none of this detail, so they were not reproducible.

Step 3: the Xposed layer

The original LSPosed project was archived, and its releases targeted Android 8.1 to 14. Wrong starting point on a modern device.

JingMatrix/LSPosed is the maintained fork most people run. Its maintainer has been refactoring it into JingMatrix/Vector, which keeps API consistency with the original Xposed while rewriting the internals, with support out to Android 16 and 17 and 16K-page devices. Check which the project's own releases page currently recommends, because this is in transition.

JingMatrix/LSPatch is the rootless route. It embeds the framework into one app by patching that app's APK. No root, no Zygisk. Worth knowing if you want one Xposed module's behaviour and nothing else.

ReLSPosed, another fork that circulated, was archived by its owner in February 2026. Check dates before trusting a fork.

Hide My Applist (Dr-TSNG/Hide-My-Applist) intercepts app-list scanning, which some apps use to spot root managers. Its author has suspended development, though it remains available and in use. Treat it as a legacy tool that still works rather than something maintained.

Xposed modules themselves have the same problem. One untouched for two years is unlikely to work on Android 15 or 16 whatever its thread claims.

Step 4: the verified list

Grouped by what you would actually want. Every link goes to the maintainer's own repository. All work on Magisk unless noted.

Ad and tracker blocking

Run exactly one hosts blocker. Two, or one plus AdAway's root mode, means two things fighting over the same file. Aggressive lists also break legitimate app features, so start with a standard profile and add more only when you hit something specific.

Setting expectations: hosts blocking stops domain lookups. It does nothing about ads served from the same domain as the content. Android's Private DNS setting gets you much of the same with no root at all.

Battery and power

ACC is the honest replacement for the vague "battery management" entries that appear on most lists with no repository attached. Use its own detection tooling rather than copying another phone's charging switch.

Gaming and scheduling

Configure per game rather than globally. Gains are device, kernel and game dependent, and the demo videos overstate them. Do not stack it with another scheduler module.

Interface and theming

Apply one group of changes at a time. SystemUI crashes and bootloops after unsupported ROM and update combinations are a known pattern with theming modules. Revert overlays before a major system update.

Utility

Developer and security testing

These widen your device's trust boundary. They exist for traffic debugging and security research and are a poor idea on a daily driver. Remove test CAs when you are done. Neither defeats certificate pinning.

Alternative integrity toolkits

Integrity-Box (MeowDump/Integrity-Box) bundles integrity and environment management behind its own interface. PlayIntegrityFix-NEXT (EricInacio01/PlayIntegrityFix-NEXT) is an experimental fork covering Android 10 to 16.

Both overlap with PlayIntegrityFork. Treat them as alternative stacks, not additions. Overlapping integrity tools create conflicts that are miserable to diagnose.

Kernel-level hiding, KernelSU family only

SUSFS lives at gitlab.com/simonpunk/susfs4ksu with a companion module at sidex15/susfs4ksu-module. It needs a kernel with SUSFS patched in, so it is a KernelSU, KernelSU Next or SukiSU Ultra option. Not available on Magisk or APatch.

Risk tiers

Not every module carries the same exposure.

Where to get modules now

Since the built-in repository is gone:

1. The project's own GitHub releases page. The correct source for everything above, and where every link here points. Download the .zip asset, not the source archive.
2. Magisk-Modules-Alt-Repo, the community repository that accepts new submissions.
3. MMRL, a module manager app that handles Magisk, KernelSU and APatch modules if you would rather browse than download by hand.

To install: open your root manager, go to Modules, tap Install from storage, pick the ZIP, reboot.

We do not host module binaries and we would be wary of anyone who does. Download from the project, not from a mirror, a shortened link, or a Telegram file.

How to vet a module

Root modules run with full privileges. Apply the scrutiny that deserves:

• Is the source visible? No repository, no install. That alone rules out a lot.
• When was the last release? Untouched for two years on a fast-moving target is a liability.
• Does the maintainer answer issues? Months of silence is a signal.
• Does its documentation state compatibility? Android version, root manager, known conflicts.
• Is anyone running it on your Android version and your root manager? Not on the device it was written for in 2023.
• Does it ask you to weaken something? Anything requiring SELinux to be disabled deserves a hard look.

Recovering from a bootloop

Have this ready before you need it. In order of preference:

1. Safe mode. Magisk disables all modules when it detects a safe mode boot. Boot to safe mode, then reboot normally, and you get a running system with everything off so you can remove the offender from the app. KernelSU does the same. The key combination varies by device, so practise it once while everything works.

2. The removal command. If a computer can see the device while it tries to boot, Magisk documents this:

adb wait-for-device shell magisk --remove-modules

It removes all modules and reboots.

3. Disable one module from a shell. Creating a disable file inside a module's folder under /data/adb/modules/ turns just that one off.

4. Restore the stock boot image. The fallback, and the reason to keep one. Read the caution below first.

The boot image caveat

Magisk's own documentation warns that partition restoration is device-specific, and cautions Samsung users in particular against casually restoring boot, init_boot, recovery or vbmeta. Generic fastboot advice does not transfer across manufacturers. APatch users should also note that it patches boot, not init_boot.

Follow the procedure for your exact device. If a flash has already gone wrong, diagnose before flashing again, and if the device will not boot at all, work out which state it is in first.

Whatever you do, do not start wiping. The order of operations matters, and a factory reset destroys your encryption keys along with your data.

Related reading: Magisk vs KernelSU vs APatch · SafetyNet and Play Integrity with root · Magisk in 2026: what changed · Magisk flash failed · OTA update failed on a rooted Android · Android debloating guide

Sources: Each project's own GitHub or GitLab repository, linked inline. Magisk official documentation, FAQ and release notes. APatch and KernelSU official documentation. Module status verified against repository activity and maintainer statements on the date shown above.

Last verified: 29 August 2026. This ecosystem moves quickly. Projects listed here were active at the time of verification and any may be discontinued, forked, or superseded without notice. Check the linked repository before installing, and treat compatibility as device-specific.