WebUI X: Portable runs and debugs Android WebUIs without the MMRL app

What WXP is: a runtime host, not the MMRL application

The project states its own scope in the first line of the description: WebUI X from MMRL but portable. The name in the README is WebUI X: Portable, abbreviated WXP, and it is described as an advanced WebUI runtime host and developer environment for Android web interfaces.

That word runtime host is doing the real work. A WebUI in this ecosystem is a web interface that a root management module installs, normally alongside a script, so that a user can configure the module from a phone rather than from a terminal. WXP provides the environment those web interfaces run in, so you can run, inspect and debug them. It is a developer tool in the sense that the built-in tooling is aimed at whoever is writing the WebUI, not at whoever is only using the finished module.

The distinction matters because the surrounding application, MMRL, is a module manager. WXP is the part that hosts a WebUI, packaged so it can be installed and run on its own. For a module author that means you can iterate on a WebUI without installing the full manager, and on a device without root, since the README lists non-root ADB environments among the supported setups.

The repository is a Kotlin Android project with the usual Gradle layout: a build-logic directory, an app module, a datastore module, a jna directory, a webui directory, scripts, assets and a settings.gradle.kts. That jna directory is worth noting, because it points at native library access, and the webui directory at the root is where the runtime's own web assets live.

Running the same WebUI on KernelSU, Magisk, APatch and plain ADB

The first core feature the README lists is universal environment support: it runs on KernelSU, Magisk, APatch and non-root ADB environments. That list is the whole point of the portable framing, and it is a meaningfully different design constraint from the one MMRL operates under.

Within the rooting frameworks, a module WebUI normally gains access to privileged operations through an interface the framework provides. KernelSU in particular is named separately in the extensibility line, where the README says the architecture supports Dex and Lua plugins, custom JS interfaces and extended KernelSU I/O APIs. So under a rooted framework the WebUI can reach file and system operations, and the differences between frameworks show up as differences in what that interface exposes.

Under plain ADB with no root, the same WebUI loads without those privileged bridges, which is what makes the runtime usable for UI work on a device you do not want to modify. The system diagnostics feature, described as a dashboard providing device information, system status and module metrics, is the visible part of that: it gives you a readout of the environment regardless of which of the four setups you are in.

The trade is straightforward. The fewer privileges the runtime has, the less a WebUI can actually configure. A module whose WebUI writes to system paths will behave differently in a non-root ADB session than under Magisk, and the README does not document a compatibility matrix that would let you predict which features degrade.

The DevTools suite is the reason to use a separate host

The third core feature is a full DevTools suite, described as a built-in DOM inspector, network monitoring, console history and snippet execution. On a phone, that is the difference between guessing at why a WebUI misbehaves and being able to look.

The DOM inspector answers what is in the tree, network monitoring answers what the interface actually requested, console history captures what it logged, and snippet execution lets you evaluate expressions against the live page without rebuilding the module. For someone writing a WebUI, that set covers the loop that would otherwise require a desktop browser connected over a debugging bridge.

The file explorer and editor sits next to it in the feature list, described as an integrated File Explorer with a TextMate-powered code editor for real-time script modifications. Being able to open a script on the device, change it and see the effect is a real shortening of the edit and test cycle, and it is the feature that pairs most naturally with running a WebUI in a portable host.

Two things are worth flagging about the scope here. The engine is described as a native MX engine, a WebUI runtime with automatic inset padding and custom theme handling, which is about presentation rather than debugging. And the console history is a record of what the page logged, not a full remote debugging protocol, so the tool is built for inspecting behaviour, not for attaching an external debugger to the process.

Where to get WXP and what the build layout tells you

The README carries two release badges, one pointing at the latest GitHub release and one at a Google Play listing under the package id com.dergoogler.mmrl.wx, and the translation widget points at a Weblate project for the mmrlapp organisation. The project documentation lives at mmrl.dev under a webuix guide path.

The README does not give a command to install the application, so there is nothing to reproduce here for a package step. What the repository does show is a conventional Gradle build: build.gradle.kts and settings.gradle.kts at the top level, a gradle.properties file, the gradlew and gradlew.bat wrapper scripts, and a build-logic directory for convention plugins. A checkout therefore builds with the wrapper in the usual way, and the release artefacts are distributed as an APK through GitHub releases and a Play listing rather than through a package manager.

The scripts directory and commits.sh at the root suggest the release numbering is produced by a script rather than by hand. That is consistent with the release history, where v612, v614 and v616 are tagged close together on 2026-10-09 and 2026-10-10, which reads like a build-numbering scheme incrementing per build rather than a semantic version per feature. The last push was on 2026-10-10, matching the newest tag, and the repository is not archived.

The datastore directory is worth a mention for anyone who looks at the code. It indicates that the application keeps persistent state through a dedicated data layer rather than writing preferences ad hoc in each screen, which is the kind of structural choice that makes a later migration of stored settings possible.

Plugins and custom JS interfaces, with a thin description

Extensibility is listed as a core feature: support for Dex and Lua plugins, custom JS interfaces, and extended KernelSU I/O APIs. The custom JS interface is the part that matters most for module authors, because it is how a WebUI's JavaScript reaches the native side of the runtime, and how a module can offer a JavaScript API to its own WebUI.

Dex and Lua plugin support means the runtime can be extended without forking the application, which is a useful escape hatch for a tool that has to work across several root frameworks. Loading compiled code is also a trust decision. A Dex plugin runs with the application's privileges, so where you obtain one is as important as what it does, and the README does not describe a permission model, a signing check or a sandbox for plugins. That absence is not necessarily a problem, but it does mean the trust boundary sits with the person installing the plugin rather than with the runtime.

Documentation is the weak point in this area. The README gives the extensibility line and stops, with no plugin API reference, no list of the available JS interfaces and no example. Anyone building a plugin here is working from the source and from the guide pages linked in the README, which is a different experience from the guided onboarding that the other core features imply.

Where WXP is the wrong tool

The clearest wrong-tool case is module management. WXP hosts and debugs WebUIs; the README does not claim it installs root modules, manages boot images or performs the broader duties of a module manager. If your requirement is to install and manage modules on a phone, MMRL is the application described by the project page, and WXP is the part of that world that runs the web interface.

The second wrong-tool case is a production deployment. This is a developer runtime with a debug-oriented feature set: console history, snippet execution, an in-app code editor, a file explorer that can edit scripts on the device. Tools that let you evaluate arbitrary code against a live page and rewrite files are exactly what you do not want in the app you ship to end users. WXP is meant to sit on your own desk, connected to a device, not on a customer's handset.

The third is the non-root case with a privileged module. If the WebUI you are developing genuinely needs root operations to function, running it in the non-root ADB environment is a different program from the one users will run. The portable runtime is convenient for layout and logic work, and a developer should be careful not to conclude that a module is finished when it has only been verified there.

On licensing, the project is GPL-3.0, which matters if you plan to redistribute the application or integrate it into something you ship. A GPL-3.0 application carries copyleft obligations on redistribution, and a developer who intends to bundle WXP with a proprietary product needs to review that obligation rather than assume it away. The README also points at a Weblate project, so the interface is translated by the community into many languages, which is a genuine advantage for a tool used across regions.

Editorial conclusion

Adopt WebUI X: Portable if you develop WebUI modules and want a runtime that stands on its own, runs without root, and lets you inspect the DOM, watch network traffic and edit scripts on the device, since the DevTools suite and the file explorer are the reason this project exists separately from the MMRL app. Do not adopt it as a replacement for MMRL itself, because it is a WebUI host and the README does not describe it as a general module manager, and do not expect the plugin surface to be stable, since the Dex and Lua plugin support is described in one line and the releases are numbered v612, v614 and v616. Verify first that your target environment is one of the four the README lists, KernelSU, Magisk, APatch or non-root ADB, that the WebUI module you are testing targets this runtime rather than the one bundled with MMRL, and that the GPL-3.0 licence is acceptable for how you intend to redistribute the APK.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. MMRLApp/WebUI-X-Portable on GitHub
3. Project website
4. README
5. Releases