MMRL: an Android app for browsing and installing Magisk modules
A app for managing, sharing, and exploring Magisk modules across repositories
At a glance
- What is it?
- MMRL is a Kotlin app that turns Magisk module management into something you browse rather than something you sideload file by file, working across Magisk, KernelSU and APatch. It also runs a public module repository with a command line builder behind it.
- Who is it for?
- MMRL earns its place for anyone with more than a handful of modules, because it replaces a folder of downloaded zips and a manual flash order with a browsable list that resolves dependencies for you. It is the wrong choice for a rooted phone with two modules and no interest in a repository, and it is not a root manager itself: it drives whichever one you already have.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A module manager that treats modules as a catalogue
Most Magisk workflows start with a zip file you found somewhere and a recovery-flash mindset. MMRL reorganises that around a repository: a community platform where anyone can contribute modules and users can browse, search and install them, with categories, screenshots, icons and cover images on each page.
What makes that more than a file list is the install path. Bulk installation is supported, both from online repositories and from local files, and module dependencies are handled automatically rather than left to you to work out the order. The README describes this as simplifying installation for end users, and it is the feature that separates a browser from a downloader.
There is a transparency thread running through the feature list that is worth taking seriously. MMRL keeps a blacklist of restricted modules and actions, and it says the point is that users can see what is blocked and decide for themselves. It also shows a detailed breakdown of every file inside a module, including APKs and service scripts, before you install. For a mechanism that runs shell scripts as root on your phone, being able to read what you are about to grant is not a minor feature.
Three root managers, one interface
MMRL sits on top of other software rather than replacing it. The README states full compatibility with Magisk, KernelSU and APatch, and the supported version ranges are given explicitly: Android 8.0 through 14, Magisk 24.0 and later, KernelSU 0.5.1 and later, APatch 10253 and later.
Those floors are the practical adoption question. If your root setup predates the stated minimum, the app will still install but the compatibility claim does not cover you, and the repository has no way to warn you at install time. Checking your own version against that list is a five second job that saves a confusing afternoon.
The Kotlin source layout follows modern Android structure: app/ for the main module, ui/ for Compose screens, datastore/ for preferences, platform/ for the platform specific layer that is what makes three root managers supportable, plus ext/, compat/ and hidden-api/ directories, and build-logic/ holding the Gradle conventions. Kotlin with Compose is the declared stack, and the topics on the repository agree.
One entry in a recent release is easy to skim past. v34265 includes Randomize KernelSU native library name and later Remove dynamic KernelSU library naming, which is an anti-detection measure: the library name changes so that an app scanning for known root binaries does not find a fixed string. Knowing that is in the changelog tells you what threat model the developers are working under.
Build numbers instead of version numbers
The release tags look nothing like semantic versions. The three most recent are v34296 on 2026-03-08, v34292 on 2026-02-21 and v34265 on 2025-12-21. These are monotonic build identifiers, which is a common pattern for apps distributed through Google Play, where the version code has to increase on every upload even when nothing user visible changed.
That has a practical consequence for anyone tracking releases. There is no minor version to jump to for a fix, and the release notes are a flat list of merged changes. Compare the two recent ones and the pattern is obvious: v34292 is almost entirely Weblate translation activity across Thai, Vietnamese, Persian, Simplified Chinese, Spanish, Indonesian and Turkish, with one Compose refactor of MainScreen to use CompositionLocalProvider for padding, and a README typo fix. v34296 is three lines, two of them the same Dutch translation entry repeated.
The one that shows real feature work is v34265 in December 2025, which added a Meta Modules section to the repository screen, stars and buildMetadata fields on online modules, an option to show stars in module details, a default for showing update time, and a fix so the module date shows the latest version timestamp. That last one is the kind of bug that only shows up once a repository has history worth displaying.
So if you are deciding whether to update, the honest summary is that this project ships often and ships small. The repository metadata shows the last push on 2026-09-22, several months after the v34296 release, so there is work on master that has not been tagged.
The repository has a command line builder behind it
One line in the README is more architecturally interesting than the feature list: MMRL-Util, described as a command line interface for building modules repository, lives in a separate repository under the same organisation.
That split tells you how the data gets into the app. The Android app is a consumer, not the source of truth. Index generation, module metadata and whatever validation a repository needs happen outside the app, in a tool you can run on a build machine or in CI. For a public community repository that is the only arrangement that scales, since nobody should have to open an Android project to add a module.
The credits section names where the ideas came from: tabler-icons for the icon set, topjohnwu/libsu for root shell access, and MRepoApp/MRepo, the earlier repository app whose lineage is visible in the fastlane directory used for Play Store metadata. The Play listing uses the package identifier com.dergoogler.mmrl, which is a leftover from that ancestry and a useful clue if you are looking for the right app in the store.
Translations run through Weblate, hosted at weblate.org with an mmrlapp project, and the release notes confirm contributors arriving that way. Crowdsourced translation for an app in this category is normal, and it does mean some strings will read awkwardly.
Distribution through Play and direct APK downloads
The README carries three badges and each one answers a different question. The GitHub release badge points at the newest tag. The Google Play badge is a custom endpoint querying the Play listing, and it is labelled Google Play in red, which signals that this is the primary channel. The third badge counts total GitHub downloads across all assets and all releases, which is the number that matters if you are distributing outside the Play ecosystem.
Two channels with different rules means two different update behaviours, and nobody in the repository spells out how they interact. Play delivers updates on your schedule and MMRL has to ship through review to move; GitHub releases deliver immediately but you have to install from an unknown source. The fastlane/ directory in the tree, with per-locale phone screenshot folders under android/en-US, confirms the Play path is actively maintained with real assets rather than a listing left to rot.
The homepage for the project is mmrl.dev, and the repository has a docs/ directory that the README does not describe in any detail. For an app with this many settings across three root managers, the documentation you want is a per-setting explanation, and it is not in the README page.
Where this does not help you
MMRL does not root anything. It is a catalogue and installer for modules that run inside a root manager you already have, which means the value of the app scales with how many modules you actually want. On a device running a single module, a browser with a dependency resolver is more machinery than the job needs, and the stock Magisk app covers installation fine.
It also does not replace the judgement a module deserves. The README's file listing feature gets you as far as reading which APKs and scripts ship inside a module, which is real information, but it is not a security review of what those scripts do. A module that runs as root with a service script can do anything on the device, and the repository platform is described as community driven, which means contributors include people you have not heard of. The blacklist covers known problems and nothing more.
The analytics dashboard on the homepage is worth a sceptic's glance too. Displaying module usage trends is useful for the people maintaining modules and mildly useful for choosing between two similarly named entries, but popularity is not a quality signal in a community catalogue, and download counts reward whatever was listed first.
If you need reproducible builds, pinned versions or a signed module set for a fleet of devices, none of that is in this repository. MMRL is a phone app for a person with a phone.
Editorial conclusion
MMRL earns its place for anyone with more than a handful of modules, because it replaces a folder of downloaded zips and a manual flash order with a browsable list that resolves dependencies for you. It is the wrong choice for a rooted phone with two modules and no interest in a repository, and it is not a root manager itself: it drives whichever one you already have. Two things to check before you switch your daily driver. Confirm your root solution is inside the supported range listed in the README, since Magisk 24.0, KernelSU 0.5.1 and APatch 10253 are the stated floors. And look at the file listing for a module before installing, which MMRL makes possible and which is the closest thing to an audit this ecosystem has. Start by adding one repository and reading the dependency resolution on a module you already know.
Frequently asked questions
What root managers does MMRL work with?
Magisk, KernelSU and APatch, with the README giving supported ranges of Magisk 24.0 and later, KernelSU 0.5.1 and later, and APatch 10253 and later, on Android 8.0 through 14. MMRL drives whichever root manager is installed rather than replacing it.
Does MMRL install module dependencies automatically?
Yes. Dependency management is listed as a feature, with modules installed automatically handling their dependencies rather than leaving the order to the user. Bulk installation is also supported, from online repositories and from local files.
Can I see what files are inside a Magisk module in MMRL?
The README lists a detailed breakdown of all files within modules, including APKs and service files, and describes it as transparency for full user awareness. MMRL also keeps a blacklist of restricted modules and actions, and says the visibility is there so users can make informed decisions.
How do I publish or build a module repository for MMRL?
Repository building lives in a separate tool: MMRL-Util, hosted at MMRLApp/MMRL-Util and described as a command line interface for building a modules repository. MMRL itself is the Android consumer of that data, and the public repository is community driven, so contributions go through the project's issue tracker or repository tooling.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mmrlapp-mmrl)