ReVanced as a Magisk module: rebuilding YouTube and YouTube Music from patches

This is a build pipeline, not the patch project itself

It helps to be clear about what this repository is, because the name invites confusion. The ReVanced Team maintains the patches, in the revanced-patches repository. This repository is a shell script that takes those patches, applies them, recompiles the result, and packages it as a root module.

The project description says it covers ReVanced YT and YT-M for both root and non root users, and the primary language is Shell. The tree confirms it: build.sh, build-termux.sh and utils.sh at the top level, a bin directory, a module directory, a config.toml, a sig.txt file and two keystores, ks.keystore and ks-p12.keystore.

The credits matter for reading the code. j-hc is credited for zygisk-detach and for the script on which this one is based, that is the revanced-magisk-module project. The ReVanced Team is credited for their patches, and the Morphe Team for MicroG. So the architecture is borrowed, with the patches coming from upstream and the module mechanics from j-hc.

The audience is therefore fairly specific: people who already understand root module systems and want patched YouTube builds that install and update like any other module.

What the module actually does at runtime

The feature list is short and each item is a concrete mechanism rather than a promise.

The module recompiles the invalidated odex for YouTube and YouTube Music, which the project describes as making them faster to use. In practice the odex is the precompiled form of the app's dex code, and an invalidated one is one the system has to rebuild on first launch, so shipping a valid one removes that cost.

The module receives updates from the Magisk app, which is the practical difference between this and a sideloaded APK. You install once and the module updates itself.

It is also designed not to break safetynet or trigger root detections used by certain apps, and to handle installation of the correct version of the stock app. The last point is the one that explains the rest of the design. Because the patched build carries a different signing key than the Play Store build, it cannot be installed as an update over the stock app, so the module has to keep the stock and patched versions apart and swap them.

That is also why zygisk-detach is needed. The notes tell you to use zygisk-detach to block the Play Store from updating YouTube and YouTube Music. Without that, the Play Store replaces the patched build with the stock one and the whole exercise ends without an error message.

Both Magisk and KernelSU are supported, so the module is not tied to one root implementation.

The two builds, root and non root, and the MicroG dependency

The non root path is the more interesting one, and it carries a dependency you cannot remove.

The notes state that non root versions of YouTube and YouTube Music require MicroG to work, linking the MorpheApp MicroG-RE project. The reason is straightforward once you understand what the module does. It installs a patched build of the app, and a patched build is signed with a different key than the stock one. On a rooted device the module system controls the package, so the patched APK can occupy the package name. Without root there is no module system, so the patched app has to coexist with the stock app, and Google Play Services has to believe the patched app is the real one. That is what MicroG provides.

So the root and non root variants are not two flavours of the same install. They are different arrangements, and the non root one is a collaboration with another project rather than a self contained solution.

The trade is worth stating plainly. The non root route gives you a patched app without rooting, which removes the root detection and safetynet concerns entirely for your own device. The root route is the one the project is built around, with the module, the zygisk-detach integration and the Magisk update channel, and it is the one that gives you control over the installed version.

The non root build is also the one that depends on the Play Store not interfering, which is the same class of problem the root route solves with zygisk-detach.

Releases are CI artefacts, and the build needs no human

The distribution model is worth understanding before you install anything.

The project says to get the latest CI release from the repository releases page, and the release list shows the artefacts are numbered rather than semantically versioned: release 120, then 119, then 118, with the older entries named for the YouTube build they carry, such as youtube-revanced-magisk-v20.14.43-all.zip. So the version number in the filename tracks the YouTube app version, and the release number tracks the build of the module itself.

The project states that every binary or APK is compiled without human intervention, and the CI badge in the readme is for a scheduled workflow. Combined with the continuous integration directory in the tree, that means the artefacts are produced by an automated pipeline rather than built and uploaded by a person.

That has two consequences. The good one is that you get fresh builds as the patch set moves, and the readme states the modules are updated with the latest versions of patches. The bad one is that the artefact identity is a number that moves, so there is no stable name to pin, and a build you installed yesterday is not the build you get today unless you pin the release.

The tree also includes a build-termux.sh script alongside build.sh, which is a second entry point for building, and a bin directory with the scripts the build invokes. The config.toml at the root holds the build configuration, and CONFIG.md documents it.

There is a warning at the very top of the readme that deserves repeating. Do not download modules from third party sources like random websites found on a Google search, and only use this repository, because the author is not responsible for anything those copies may contain. That is a sensible instruction on its own terms: a root module is arbitrary code running with the highest privileges on your device, and the module format makes no cryptographic promise about who built the copy you downloaded.

Where this approach falls short

There are several limitations, and most of them come from the moving parts rather than from the scripts themselves.

The first is the version treadmill. The release names encode a specific YouTube version, and the module handles installation of the correct version of the stock app. YouTube ships updates frequently, and the readme is explicit that the modules are updated with the latest versions of patches. So you are in a loop where a stock update can arrive ahead of the module, and the state you had working is not the state you have now. The zygisk-detach requirement exists to slow that loop down, not to stop it.

The second is the root detection problem, and the claim here deserves scepticism rather than acceptance. The project says the module should not break safetynet or trigger root detections used by certain apps. That is a statement about behaviour that only holds against specific implementations of detection, and it is a moving target on both sides. An app that tightens its detection can start failing on a module that worked yesterday.

The third is that a patched YouTube carries a different signature from the Play Store build. That is unavoidable, and it has consequences beyond installation: apps that check the signature of the YouTube package, and Play Protect warnings about modified apps, are downstream of that fact.

The fourth is the size of the dependency chain. For the root path you need Magisk or KernelSU, zygisk-detach, and the module. For the non root path you need MicroG, and you are relying on another project to convince Google Play Services of the app's identity. Neither path is self contained.

The repository is not archived and the last push was on 2026-07-26. The most recent release listed is 120, published on 2026-03-21, which is well before that push, so the release cadence and the commit cadence are not the same thing.

Against patching the APK yourself, and against a plain root install

Two comparisons put this project in context.

The first is against doing the patch and install by hand, which is what the ReVanced tooling invites on its own. The difference in approach is packaging and update handling. Hand patching produces an APK you install once, by hand, with a file manager or an installer, and every subsequent stock update undoes it. This project produces a module, which the root system installs into the package slot and updates through the Magisk app, and which additionally deals with the odex and with keeping the correct stock version available.

That is a meaningful amount of machinery, and it is machinery you would otherwise write yourself. It is also machinery that ties you to a particular root ecosystem, since the module format and the update channel are Magisk concepts.

The second comparison is against installing the stock app on a rooted device and stopping there. In many cases that is the right answer. If your interest in YouTube patches is cosmetic, a rooted device with the stock app gives you the same playback behaviour, plus the ability to use other root modules, with none of the patching, the version treadmill or the signature mismatch.

The genuine reasons to reach for this project are specific. You want a particular patch, you want the patched build to survive stock updates through the module update channel, or you want the non root route with MicroG so you can keep an unrooted device. If none of those apply, the module is a lot of moving parts for a cosmetic difference.

Editorial conclusion

Adopt this repository if you already run Magisk or KernelSU, already use the ReVanced patch set, and want the patched builds delivered as a module that receives updates from the Magisk app rather than as APKs you sideload by hand. Skip it if you are on a non root device without MicroG, since the non root path depends on an additional project, and skip it if you want a stable build you can pin, since the artefacts are CI releases tracked by number. Verify first that your device's Play Store can be prevented from updating YouTube through zygisk-detach, because otherwise the stock app replaces the patched one, and only install modules from this repository as the project instructs.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. NoName-exe/revanced on GitHub
4. README
5. Releases