j-hc/revanced-magisk-module: a daily ReVanced builder for Magisk and KernelSU
Extensive ReVanced builder. Builds both modules and APKs. Updated daily.
At a glance
- What is it?
- This repository builds ReVanced modules and non-root APKs from a config file, either in GitHub Actions or locally. It is a build pipeline, not a patched APK you install directly, and that distinction decides whether it fits your setup.
- Who is it for?
- Adopt it if you already run Magisk or KernelSU, want ReVanced patches applied to current app versions, and are willing to fork the template and edit config.toml. Skip it if you want a ready-made APK to sideload, since every artifact here is produced by a build you or a workflow runs.
- 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 Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What j-hc/revanced-magisk-module actually produces
The repository is a builder, not a patched app. Its README calls it an "Extensive ReVanced builder", and the outputs are Magisk modules and non-root APKs generated from the ReVanced patches applied to app versions. The README states it supports all present and future ReVanced apps, including projects implementing the same interface, and names Morphe as an example.
The audience is narrow but well defined. You are running Magisk or KernelSU, you want patched YouTube or YouTube Music installed as a module rather than a sideloaded APK, and you accept that the patch set changes as ReVanced patches change. The README also points to zygisk-detach for detaching YouTube and YT Music from the Play Store when using magisk modules, which tells you the expected install pattern: patched app as a module, stock app detached so the store does not overwrite it.
If you just want a patched APK to install by hand, this project is more machinery than you need. The non-root APK path exists, but the module path is where the repository's stated advantages live.
How the build pipeline is wired
Two entry points exist. The README's customization flow uses the repository as a template, edits config.toml, and runs the build workflow in GitHub Actions; artifacts land in the releases of your fork. The local flow runs build.sh on Linux or build-termux.sh under Termux, using the same config.
The config is the control surface. The README points to rvmm-config-gen for producing config.toml and to CONFIG.md for the keys. That means patch inclusion and exclusion, and the set of apps to patch, are declared rather than hardcoded, which is why the same tree can serve YouTube, YT Music and other ReVanced-compatible apps.
The repository layout backs this up: build-module.sh, a revanced-magisk/ directory, and a base-v17.24.34.apk.REMOVED.git-id marker. The base APK itself is not in the tree, only a git-id placeholder, so a build has to fetch or be supplied the base app. The README does not document that fetch step in the excerpt available, so treat base APK sourcing as something to confirm in CONFIG.md before you rely on a local build.
On the module side, the README lists recompiling invalidated odex for faster usage, updates from the Magisk app, handling installation of the correct stock app version, and support for Magisk and KernelSU. It also claims modules do not break safetynet or trigger root detections, a claim worth testing on your own device rather than taking on faith.
Building locally on Linux or Termux
The README gives a Termux one-liner that clones nothing by hand: it pipes build-termux.sh from the main branch into bash.
bash <(curl -sSf https://raw.githubusercontent.com/j-hc/revanced-magisk-module/main/build-termux.sh)On Linux the documented steps are a shallow clone and build.sh:
git clone https://github.com/j-hc/revanced-magisk-module --depth 1
cd revanced-magisk-module
./build.shThe --depth 1 flag keeps the clone small; the build then runs from the checked-out tree. What you should see at the end is the module and APK outputs in the working directory, per the README's description of the builder. The README does not print an expected file listing, so check the tree after the run rather than assuming a fixed output name.
If you would rather not build at all, the README says to get the latest CI release from the releases page. Those are prebuilt artifacts from the scheduled workflow, which the README describes as updated daily with the latest versions of apps and patches.
Where the module approach breaks down
The README itself documents a failure mode for the classic mount method: a "Reflash needed" error after reboots, and "Suspicious mount detected" warnings from root detector apps. Its answer is rvmm-zygisk-mount, a separate repository. That is an admission that the default mount path is not invisible on every device, whatever the feature list claims about root detections.
The second limitation is structural. Because the project tracks current app and patch versions, a module built today can be invalidated by an app update or a patch change. The daily release cadence exists precisely because the inputs move. If you pin an old module and stop rebuilding, you are on your own for compatibility.
Third, the local build path depends on a base APK that is not in the repository. The base-v17.24.34.apk.REMOVED.git-id entry confirms the file was removed from version control. Anyone building locally needs to understand how the base app is obtained; the README excerpt does not cover it, and CONFIG.md is the place to look.
Finally, this is the wrong tool if your device is not rooted. Modules require Magisk or KernelSU. The non-root APK output exists, but then you are not using the module features at all, and a simpler patching route may suit you better.
How it differs from patching an APK yourself
The obvious alternative is running the ReVanced patcher directly against an APK you supply and installing the result as a normal app. The difference is where the work happens and what you get afterward.
With a direct patch, you own the whole cycle: fetch the APK, pick patches, patch, sign, install, repeat when a patch changes. Nothing sits between you and the output, and no module infrastructure is involved. With this repository, the patch selection lives in config.toml, the build runs in a workflow or in build.sh, and the output is a module the Magisk app can update in place. The README lists receiving in-app updates and updates from the Magisk app as features, and that update path is the real distinction: a sideloaded patched APK does not update itself through Magisk.
The trade is control for convenience. You give up direct control of the patching invocation and take on a config file, a build environment, and the project's assumptions about base app versions. If you need a specific patch combination that config.toml cannot express, the direct route is less friction.
Licence and upgrade cost
The repository is GPL-3.0. If you fork it as a template and distribute built modules, the licence terms attach to that distribution. That is a general property of GPL-3.0, not legal advice, and it is worth reading the LICENSE file in the tree before you publish artifacts.
Upgrade cost is mostly time, not money. The README describes daily updates, and the release list shows builds on consecutive days, so the project expects you to rebuild or re-download regularly to stay current with app and patch versions. If you fork, you carry the cost of keeping your config.toml aligned with whatever keys CONFIG.md documents, because a config that drifts from the current schema will fail the build rather than silently degrade.
The repository is not archived, and the last push was on 2026-09-21, so it is being pushed to. That does not tell you how long any individual release will keep working against a given app version.
Editorial conclusion
Adopt it if you already run Magisk or KernelSU, want ReVanced patches applied to current app versions, and are willing to fork the template and edit config.toml. Skip it if you want a ready-made APK to sideload, since every artifact here is produced by a build you or a workflow runs. Before committing, check that config.toml covers the apps and patches you need, and read the rvmm-zygisk-mount README if root detector apps have flagged your mounts.
Frequently asked questions
how to install revanced magisk module
Build or download a module from the releases page, then install it through the Magisk app, which the README says can also deliver updates to the module. For local builds, run build.sh on Linux or the build-termux.sh one-liner under Termux and take the module output from the build tree.
Can I use Magisk modules without root access?
No. The README lists support for Magisk and KernelSU, both of which are root solutions, so the module path requires root. The repository can also build non-root APKs, but those are installed as ordinary apps and do not use the module features.
What is j-hc/revanced-magisk-module?
It is a ReVanced builder that produces Magisk modules and non-root APKs from a config file, either through a GitHub Actions workflow on your own fork or through build.sh locally. The README describes it as an extensive ReVanced builder that supports ReVanced apps and projects implementing the same interface, such as Morphe.
Why do I need Magisk for j-hc/revanced-magisk-module?
Because the primary output is a Magisk module, and the README lists Magisk and KernelSU as the supported module environments. Without root there is no module to install, although the builder can still produce a non-root APK.
How do I choose which patches j-hc/revanced-magisk-module applies?
Patch selection and the apps to patch are set in config.toml. The README points to rvmm-config-gen for customizing that file and to CONFIG.md for the available keys.
What should I do if the module shows a reflash needed error or a suspicious mount warning?
The README documents both symptoms for the classic mount method and points to rvmm-zygisk-mount as the alternative to consider in that case.
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/j-hc-revanced-magisk-module)