Encore Tweaks: a Magisk module that tunes Android performance at the root level

Encore Tweaks is a Magisk module, not an installable app

Encore Tweaks describes itself as a special performance module for your device, and the README is direct about the delivery model. It is a Magisk module, a dynamic one according to the project text, built to maximise gaming performance while preserving battery life in everyday use. That framing matters for anyone deciding whether it fits, because a Magisk module has no standalone package you install from a store. It is applied through a root manager, and it changes system behaviour at a level above what any ordinary app permission can reach.

The project is written primarily in C++ and the repository root carries the directories you would expect from a module of that kind: a jni folder for native code, a module folder for the files that make up the flashable payload, scripts, prebuilt binaries, a config directory and a webui directory. The homepage for the project is encore.rem01gaming.dev, and the code is open under the Apache-2.0 license.

That combination puts Encore Tweaks in a specific niche. It is for rooted Android owners who play demanding games and who want the tuning applied system wide, and who accept that a module run from a root manager can alter behaviour their daily driver depends on.

One package, three root managers, and a web UI that does not work everywhere

The README lists APatch, KernelSU and Magisk as the supported root managers. Next to Magisk it adds a parenthetical note pointing at a Magisk issue about the absence of a WebUI, which tells you that the configuration interface is not simply a Magisk feature but a separate layer the project has to ship.

A second list covers the interfaces that can host that layer. KsuWebUI, WebUI-X and MMRL are named as also supported, and MMRL appears without a web marker, which suggests it is used as a package manager and install target rather than only as a UI host. In practice, the practical consequence for a reader is that the module and its settings interface are two separate pieces, and the pair has to be assembled from the right root manager and the right companion app.

This is where a quick verification pays off. The README does not state a minimum version for APatch, KernelSU, Magisk, MMRL or the WebUI projects, and it does not say what happens when the WebUI is missing on a setup that is otherwise supported. Anyone testing on a new device should confirm the interface appears before assuming the module is broken.

The tuning logic sits in native code, not in the interface

The repository listing shows a jni directory and a prebuilt directory next to scripts and module. Primary language is C++, and the presence of a native build layer alongside prebuilt artefacts is the usual shape for a module that has to do work that a shell script cannot: touching kernel interfaces, reading and writing system state, or applying settings in a way that has to survive a reboot and be undone cleanly on removal.

The practical point for an adopter is that the interface you configure is not the logic itself. Scripts and the module directory hold what is installed on the device, the jni folder holds code compiled for it, and the prebuilt folder holds binaries that are shipped rather than compiled on the target. Since the README says the module is dynamic, the module can also pull in or act on additional components at runtime rather than shipping one fixed set of files.

None of this is documented in detail. The README does not list the native interfaces that are touched, does not describe the boot sequence, and does not explain what the dynamic behaviour actually changes on each boot. That absence is a real limit on evaluation, and it is the reason to treat the module as something you test rather than something you reason about from the source tree alone.

A gamelist at the repository root hints at how games are handled

One file name in the repository root stands out: gamelist.txt. The layout also includes a config directory, which is where a module of this kind would keep per-setting values, and a scripts directory that would run at install or boot time.

The README says nothing about any of it. There is no description of the gamelist.txt format, no example entry, no indication of whether the file names packages, process names or match rules, and no explanation of what the module does differently for a listed game. The configuration guide is hosted off the repository, on the project website, at the guide path for webui and configuration, and the README links to it as the place to learn how to configure the WebUI.

So the mechanism is visible in outline but not in detail. That gap is worth naming plainly, because a file like gamelist.txt is where a lot of the real behaviour lives, and a reader who wants to predict what the module will do to a given game has to look either at the hosted guide or at the file itself.

Getting the module onto a device, without a documented command

There is no build step and no command line here, which is worth stating early. The repository is a source tree that produces a flashable module, and the README routes downloads to a separate page on the project site:

- Download, linked from the README as the page that gets you the latest version: https://encore.rem01gaming.dev/download - Configuration guide for the WebUI: https://encore.rem01gaming.dev/guide/webui-and-configuration.html - FAQ page: https://encore.rem01gaming.dev/guide/faq.html

The README does not document a flash command, a recovery install, or a list of files that must be present on the device. What it does document is the set of tools you flash into: a supported root manager from the list of three, and, where you want a graphical settings panel, one of the WebUI companion projects or MMRL.

Because the package format and the flashing steps are not written down in the repository, the first real use has to be planned around the hosted documentation and around your own recovery path. Confirm before flashing that you know how to remove a module in your chosen root manager, since the README does not document rollback for Encore Tweaks.

Translation, docs site and a changelog live in the same tree

The repository is broader than the module payload. There is a website directory, which is consistent with the hosted documentation the README points to, a changelog.md at the root, a version file, a NOTICE.md alongside the LICENSE, and a .github directory with the usual automation and community files. Translations are handled through Weblate, and the README links the project there so contributors can help extend the interface into more languages.

That last point has an operational side. A settings interface that is translated by a crowd of volunteers can lag behind the English strings when a new key is introduced, and that is precisely where tuning tools become confusing to operate, since the mapping between a label and a value is the whole point of the panel.

The version file at the root, together with the changelog and the release tags, gives you three ways to check that what you flashed matches what you think you flashed. The README also points at a Telegram channel for announcements and at the issue tracker for bugs, which is where a mismatch between the installed version and the visible behaviour would be reported.

Three releases in 2026, with a gap in the middle

The published releases are Encore Tweaks 5.2 on 2026-07-04, Encore Tweaks 5.2.1 on 2026-07-10 and Encore Tweaks 5.2.2 on 2026-10-05. The repository is not archived, and the last push was on 2026-10-09, four days after the 5.2.2 release, so the tree was being worked on immediately after the tag was cut.

The pattern across those three tags is a minor release followed by a point release, which reads as a conventional maintenance line rather than a rapid iteration cadence. The gap between 5.2.1 and 5.2.2 is close to three months, so it is fair to expect a couple of months between a published build and its follow-up rather than weekly binaries.

The README does not publish a changelog summary, so the content of each point release is only visible in the changelog.md file and the release entries themselves. Before you upgrade from 5.2.1 to 5.2.2, read those entries rather than assuming a point release only contains fixes.

Editorial conclusion

Encore Tweaks suits rooted Android owners who want a single module package for gaming and battery tuning and who are comfortable reading a web UI without a written key reference. It does not suit unrooted users, anyone who needs per-setting documentation, or teams that need a reproducible config file in version control. Before flashing, check that your root manager appears in the supported list, read the configuration guide linked from the project site, and keep a way to remove the module, since the README does not document rollback.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Rem01Gaming/encore on GitHub