Skip to content

Implement module hot reload support (libxposed API 102)#743

Closed
HSSkyBoy wants to merge 4 commits into
JingMatrix:masterfrom
HSSkyBoy:102
Closed

Implement module hot reload support (libxposed API 102)#743
HSSkyBoy wants to merge 4 commits into
JingMatrix:masterfrom
HSSkyBoy:102

Conversation

@HSSkyBoy

Copy link
Copy Markdown

Implement support for libxposed API 102 hot reloading in Vector. This update integrates the new server-side hot reload API, tracks reloadable Hook targets in the daemon, and adds runtime reloading workflows within xposed. Modules can now listen to onHotReloading and onHotReloaded events, while proper Hook handover behavior is guaranteed.

Changes Description

  • Implemented API 102 server-side methods for runtime target discovery and hot reload dispatching.
  • Added target registration and reload routing on the daemon side.
  • Introduced target-side hot reload bridging in xposed.
  • Implemented module reloading coordination logic in VectorModuleManager.
  • Froze active Hooks during reloading and transferred legacy Hook handles to the new instance.
  • Added support for API 102 Hook ID and Hook replacement.
  • Fixed snapshot behavior for replaced and inactive Hooks.
  • Passed module versionCode for target state tracking.
  • Maintained upstream consistency of services/libxposed. The superproject provides shared local annotation sources to satisfy compilation dependencies.

API 102 has not been officially released for now, pending further updates.
libxposed/api#62

@JingMatrix

JingMatrix commented May 29, 2026

Copy link
Copy Markdown
Owner

Please explain the implementation technical details, current pr description is not informative. You can read the subproject README to see what kind of details is expected.

@HSSkyBoy

HSSkyBoy commented May 31, 2026

Copy link
Copy Markdown
Author

Okay, clear, but this is a pre-PR because API102 has not been released officially yet

HSSkyBoy added 2 commits June 8, 2026 23:58
The final libxposed API 102 hot reload contract makes the old generation responsible for retiring its own Java and native resources before returning true from onHotReloading. The framework also does not call UnregisterNatives, JNI_OnUnload, or dlclose during hot reload, so it must avoid keeping stale framework-owned references after the new generation is handed off.

This updates the libxposed submodule pointers to the finalized API 102 revisions and aligns Vector's implementation with that contract. onHotReloading exceptions now remain diagnostic failures instead of being collapsed into a false rejection, saved state is checked for nested old-classloader objects, old entries are detached after the new state is committed, and failed pre-commit reload attempts clean up only newly-created hooks while preserving the old hook handles.

The daemon-side service status mapping is also updated for the final service API: the removed PROP_RT_HOT_RELOAD bit is no longer advertised, HOT_RELOAD_SUCCEEDED is used instead of the draft HOT_RELOAD_SUCCESS name, unsupported targets report HOT_RELOAD_UNSUPPORTED, concurrent reloads report HOT_RELOAD_IN_PROGRESS, and dead target processes report HOT_RELOAD_PROCESS_DIED.

Documentation References:

libxposed XposedModuleInterface hot reload callbacks:

https://libxposed.github.io/api/io/github/libxposed/api/XposedModuleInterface.html#onHotReloaded(io.github.libxposed.api.XposedModuleInterface.HotReloadedParam)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants