Running Xposed Modules on Non‑Root Android: Virtualization & Hooking Guide

Xposed is a well‑known open‑source framework for Android that enables dynamic modification of the system or apps through Java hooks, consisting of the Xposed framework and Xposed modules.

The framework’s source code is hosted at https://github.com/rovo89 and its project structure is shown in the image below.

Installation of Xposed requires replacing system partition files, specifically swapping the original app_process (and libart.so for the ART VM) with modified versions. The left side of the next diagram shows the normal Android app launch flow, while the right side illustrates the flow after Xposed installation.

Using Xposed presupposes a rooted device because the root privilege is needed to replace system files. The article asks whether alternative implementation paths exist without root.

Analysis of the Xposed source code reveals that, for a target app to run Xposed modules, the framework must establish an Xposed runtime environment during the app’s startup, load the modules, and start them.

A third‑party Android app that cannot control other app processes due to permission restrictions can still perform all operations internally because it runs under the same Linux user. If such an app provides a sandbox that can host other Android apps and offers Java hook capabilities, it can enable Xposed functionality on non‑root devices.

The article then describes the concept of application dual‑open (virtualization) and Xposed migration, starting with an overall framework diagram.

Application Dual‑Open

The core principle of dual‑open is to virtualize an Android system using sandbox technology. Android virtualization simulates a full Android OS within a single app, isolating the virtualized environment from the host system.

To achieve this, the following components must be built and initialized:

Application runtime construction and initialization

Management of the four Android component lifecycles

Transparent communication between the dual‑open app and the virtualized Android system

IO redirection

Xposed Migration

Porting the Xposed framework involves two parts: migrating the C++ native libraries ( libxposed_dalvik.so and libxposed_art.so) that provide Java hook capabilities, and migrating the Java component ( XposedBridge.jar).

The Dalvik library can be used directly after compilation, while the ART library is more complex because it depends on a modified libart.so. Implementing a new Java hook mechanism is required for ART.

Migration of XposedBridge.jar focuses on code that loads and starts Xposed modules.

On the ART VM, two main Java hook approaches exist: inline hook and virtual method replacement.

When the ART VM loads a class, it creates an ArtMethod structure containing runtime information and a pointer to the method’s instructions, which enables hooking.

Inline Hook replaces the beginning of a function with a jump to custom code, preserving the original call interface, but cannot hook very short functions.

Virtual method replacement swaps the ArtMethod structure of the original method with that of a new method at the native layer. Because the ArtMethod layout varies across Android versions, implementations differ; an example for Android 6.0 is shown below.

In a dual‑open scenario, two Application instances run simultaneously: the host application and the virtualized application. Before the host Application starts, DexClassLoader can load XposedBridge.jar into the process, establishing the Xposed runtime, after which Xposed modules are loaded and started.

Conclusion

From a technical perspective, the article demonstrates that running Xposed plugins on non‑root Android devices is feasible by employing sandbox virtualization and custom Java hook mechanisms. Commercial products such as “分身大师X版” already implement this approach, confirming its practicality.