LSPosed Framework supplies an Xposed-compatible ART hooking environment for Android 8.1 through 14, applying module-defined behavior in memory through Zygisk or the older Riru integration.
Scoped ART Hooking
A framework for running Xposed modules without permanently modifying application APK files.
ART Hooking
LSPlant provides the core runtime hooks used to intercept selected Java methods inside Android Runtime processes.
Xposed APIs
The framework is designed to preserve compatibility with original Xposed APIs, allowing supported modules to alter application or system behavior.
Per-App Scope
The manager lets users assign each Xposed module only to the applications or framework processes that require it.
Requirements and Release Variants
- The official documentation covers Android 8.1 through Android 14 and requires Magisk 24 or newer.
- The Zygisk archive is the normal choice when the Zygisk feature is enabled in Magisk.
- The Riru archive is a legacy alternative and requires Riru 26.1.7 or newer.
- Version 1.9.2 is the latest stable release listed by the project; newer Android compatibility should not be inferred from that range.
- KernelSU and APatch are not marked compatible here because the upstream installation guide documents Magisk rather than those root environments.
Installation
- Confirm that the device is running Magisk 24 or newer and falls within the documented Android version range.
- For the legacy Riru build, install Riru 26.1.7 or newer first; otherwise enable Zygisk and use the Zygisk release.
- Install the appropriate LSPosed ZIP from the Modules section of the Magisk application.
- Reboot the device and open LSPosed Manager from the notification created after startup.
- Enable only trusted Xposed modules and assign the narrowest application scope required for each one.
Operational Model
LSPosed does not provide user-facing modifications by itself. It hosts separate Xposed modules, injects their hooks into the selected processes, and applies those changes at runtime. Deactivating a module and rebooting normally removes its in-memory behavior, although data or settings written by that module may remain. Troubleshooting should begin by disabling the most recently enabled module or removing its affected scope.