ReVanced Patcher: the Kotlin library behind ReVanced Manager and ReVanced CLI

What ReVanced Patcher actually is, and who writes code against it

The README describes ReVanced Patcher as "a library that is used to patch Android applications." That single sentence sets the audience. This is not a consumer tool and there is no APK to sideload from this repository. The people who touch it directly are patch authors and maintainers of downstream tooling. The README names three consumers: ReVanced Manager, ReVanced CLI and ReVanced Library. Patches themselves live in a separate repository, ReVanced Patches.

The problem it solves is narrow and concrete. An Android application ships as an APK containing Dalvik bytecode and compiled resources. Changing behaviour means editing both, then getting a valid, installable APK back out. ReVanced Patcher exposes that as a library API so a patch can be written once and applied by any front end that links the library. Without a shared engine, every front end would carry its own disassembler, assembler and resource decoder, and patches would be tied to one tool.

The repository layout supports that reading. The Kotlin source lives under patcher/, while the top level holds build.gradle.kts, gradle/ and gradlew, plus docs/. The package.json at the root is not a runtime dependency; it declares semantic-release plugins, which is how releases and the CHANGELOG are produced.

The mechanism: bytecode, resources and arbitrary files in one patch API

The feature list in the README names three surfaces a patch can touch. First, Dalvik VM bytecode: the library can disassemble and assemble it. Second, APK resources: it can decode and build Android APK resources. Third, arbitrary APK files: it can read and write files directly from and to the APK.

That third point matters more than it looks. A patch is not limited to method bodies. It can add or replace an asset, edit a resource, and change bytecode in the same operation, which is what makes patches for things like resource-driven UI changes possible at all. The README calls the result "modular patches", meaning a patch is a unit that can be combined with others rather than a monolithic rewrite of an app.

The topics list on the repository adds context the README does not spell out: aapt, dalvik, smali and reverse-engineering. Those point at the toolchain family the library sits in. What the README does not describe is the internal pipeline, the order in which decoding, patching and rebuilding happen, or how conflicts between two patches that touch the same method are resolved. If you need that level of detail, it belongs in docs/, not in the README.

Adding ReVanced Patcher to a Gradle project

The README gives a two-step setup. First, add the GitHub Packages registry to your project, linking to GitHub's own instructions for the Gradle registry. Second, declare the dependency. The README shows this block, with the version placeholder exactly as written:

dependencies {
    implementation("app.revanced:revanced-patcher:{$version}")
}

Note the placeholder syntax. It is written with braces around the word version, so you replace the whole token with a real version string rather than pasting it literally. The dependency coordinate is app.revanced:revanced-patcher.

There is no published minimal example inside this README beyond that block. For a working project skeleton, the README points to the ReVanced Patches template repository, which is the intended starting point for a patch project. Expect to read that template and the docs/ directory before you have a patch that compiles.

Building ReVanced Patcher itself is a separate matter. The README does not list build commands; it says to follow the ReVanced documentation for building. The repository does contain gradlew and gradlew.bat, so a Gradle wrapper build is the implied path, but the README does not state the command, and I am not going to invent one.

Where it breaks: version drift, patch conflicts and no documented rollback

The most practical failure mode is version drift between a patch and the application it targets. A patch that edits a specific method by name or signature stops matching when the app's bytecode changes. ReVanced Patcher can only apply what a patch describes; if the target is gone, the patch has nothing to attach to. The README does not document what happens in that case, whether the failure is per-patch or aborts the whole run, or whether a partially patched APK is written out. That is a real gap for anyone building a front end on top of this library, because it determines whether you need your own transactional wrapper.

Related to that, the README says nothing about rollback. There is no documented way to undo a patch set once applied, other than starting from the original APK again. If your workflow keeps only the patched output, you have no recovery path.

There is also a scope limit. This library patches Android applications. It is the wrong tool if you want to modify a running process, hook an app at runtime, or work on non-Android targets. The Dalvik bytecode and APK resource surfaces are the whole point, and they are also the boundary.

One more thing worth stating plainly: the release stream in this repository is development-oriented. The most recent releases listed are v22.1.0-dev.1 and v22.0.2-dev.1, alongside v22.0.1. If you depend on this library, pin a version and read the CHANGELOG before moving, because pre-release tags appear in the release list.

ReVanced Patcher compared with a general-purpose APK rewriting toolkit

The obvious alternative for the underlying work is a general-purpose reverse-engineering toolkit such as apktool, which decodes APK resources and smali, lets you edit files on disk, and rebuilds the APK. The difference in approach is architectural rather than a matter of capability. With apktool the unit of work is a directory tree and a shell command; you edit files and rebuild. With ReVanced Patcher the unit of work is a patch object written in Kotlin against a library API, and the front end decides when to apply it.

That distinction decides which one fits. If you are doing a one-off modification, or you want to inspect an APK by hand, the directory-and-command model is simpler and needs no code. If you are maintaining a set of changes across many app versions and want them applied reproducibly by multiple front ends, the library model is the one that scales, and it is why ReVanced Manager and ReVanced CLI can share the same patches. The cost is that you write Kotlin and you take on the patch API as a dependency.

Note also that ReVanced Patcher is not a replacement for the patch collection. ReVanced Patches is a separate repository, and the library on its own ships no patches.

Maintenance, licence and the cost of keeping up

The repository is not archived, and the last push was on 2026-06-09. The same date appears on the v22.1.0-dev.1 release, so the code and the release stream were moving together at that point. There is a release workflow badge in the README and a .releaserc file at the root, and package.json lists semantic-release with the changelog, git and backmerge plugins plus gradle-semantic-release-plugin. Releases and the CHANGELOG are therefore automated rather than hand-written, which is a point in favour of the changelog being trustworthy as a record of what changed.

The licence is GPL-3.0. The README's own summary, quoting the tl;dr, is that you may copy, distribute and modify it as long as you track changes and dates in source files, and that modifications must also be made available under the GPL along with build and install instructions. The practical consequence for a patch author is that linking this library pulls your project into the GPL's distribution terms, which is a different situation from using a permissively licensed toolkit. That is a factual difference, not legal advice; if your project is closed source, get your own reading of the licence before you build on it.

Upgrade cost is dominated by the pre-release tags. Because dev releases appear in the release list, a dependency range that floats will pick them up. Pin the version and read CHANGELOG.md between pins.

Who should not start here

If your goal is to patch an app on your phone, this repository is the wrong entry point. The README names ReVanced Manager and ReVanced CLI as the tools that use the library, and those are what an end user runs. Arriving here and looking for an APK will not work, because the repository contains Kotlin source, Gradle build files and documentation, not a distributable application.

If you are unwilling to write Kotlin, the same applies. Every extension point described in the README is a library API. There is no configuration file format documented in the README that would let you describe a patch without code, and no plugin discovery mechanism is described there either.

Finally, if you need a stable, frozen API surface with long deprecation windows, the presence of dev-tagged releases suggests you should check the release notes for each version you adopt rather than assuming compatibility across the v22 line.

Editorial conclusion

Adopt ReVanced Patcher if you are writing patches or building a tool that needs to modify Dalvik bytecode and APK resources, and you accept GPL-3.0 obligations for anything you distribute. Do not adopt it if you want an end-user application: ReVanced Manager and ReVanced CLI are the projects that consume this library, and the README points at them instead. Before you write a patch, read the docs/ directory in the repository and clone the ReVanced Patches template, because the README alone does not document the patch API, the failure behaviour when a patch does not apply, or any rollback path.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. ReVanced/revanced-patcher on GitHub