RFC for final stable API

[Dr-TSNG]

After the merge, the release will be prepared for MavenCentral, and no further breaking changes are permitted.

Key changes:

1. Raise api module minSdk from 24 → 26
2. Replace getFrameworkPrivilege with getFrameworkCapabilities
3. Hookers switch back to classical callback object mechanism. The side effects of individual hooker class are too severe while introducing minimum advantage. Because dsl and lambda becomes impossible, every module would implement its own hook dispatchers, making cooperation impossible and destroy hook dump readability.
4. The return object of hook method renamed to HookHandle. Abandoned AOP style interface. Use OkHttp style interceptor for method hooks.
5. Remove no priority & tag logging, only keeping the rich log interface
6. Remove constructor parameters for XposedModule, use attachFramework method similar to Android SDK code style
7. Add onModuleLoaded interface, which is guaranteed to be called exactly once for a process

[Copilot]

Pull request overview

This PR refines the public LibXposed API toward a “final stable” shape by introducing an explicit module-load callback, restructuring hook handle types around Executable, and raising the Android minSdk accordingly.

Changes:

• Add onModuleLoaded(ModuleLoadedParam) callback to separate “module attached” from instantiation timing.
• Redesign hooking APIs: replace Member/MethodUnhooker with Executable-based generics and new hook handle types.
• Raise api module minSdk from 24 → 26 to support java.lang.reflect.Executable in the public surface.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
api/src/main/java/io/github/libxposed/api/XposedModuleInterface.java	Adds onModuleLoaded callback and related Javadoc.
api/src/main/java/io/github/libxposed/api/XposedModule.java	Removes constructor-based initialization and updates guidance to use onModuleLoaded.
api/src/main/java/io/github/libxposed/api/XposedInterfaceWrapper.java	Switches to late attachment (attachFramework) and updates wrapper methods to new hook APIs.
api/src/main/java/io/github/libxposed/api/XposedInterface.java	Updates core API types to Executable, introduces hook handle interfaces, and adjusts invocation/deoptimize APIs.
api/build.gradle.kts	Bumps minSdk to 26 to match new Executable usage.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[DavidBerdik]

I see that #15 has been closed but it does not look to me like it was implemented in this pull request. Have the plans to implement it been scrapped?

[programminghoch10]

Hi,
where are the resource and layout hooks defined that were present on the previous Xposed API (93)?
For UI modification modules these hooks are absolutely mandatory and would force many great modules to completely rewrite functionality using much more unstable/unreliable code hooks.
Having a centralized proper framework implementation of resource and layout hooks, like the previous API had, would be essential for these kind of modules.

[Dr-TSNG]

Hi, where are the resource and layout hooks defined that were present on the previous Xposed API (93)? For UI modification modules these hooks are absolutely mandatory and would force many great modules to completely rewrite functionality using much more unstable/unreliable code hooks. Having a centralized proper framework implementation of resource and layout hooks, like the previous API had, would be essential for these kind of modules.

Resource hooks are removed in new API because of already low compatibility with new Android versions. We may offer a more modern resource hook solution in the future, but it is not currently part of the API 100 initiative.

[binarynoise]

It would be nice if you updated the example repo so we can see how using the new api would look like

[Dr-TSNG]

It would be nice if you updated the example repo so we can see how using the new api would look like

https://github.com/libxposed/example/tree/rfc

[yashikada]

This:

        hook(exampleMethod, object : XposedInterface.SimpleHooker<Method> {
            override fun before(callback: XposedInterface.BeforeHookCallback<Method>) {
                log(Log.INFO, TAG, "before Application.attach")
            }
        })

is betterr than:
hook(exampleMethod, MyHooker::class.java)
but it doesn't solve all cases.

Previously (rovo api), I could pass an instantiated object with data into variables, but now, within the class, in the before/after methods, I have to invoke get* methods each time to get the values ​​I need, because I no longer have an object but a static class.
With these new APIs, the convenience of object-oriented languages ​​is lost.
In my opinion, this is a worsening of the situation.

[Dr-TSNG]

This:

        hook(exampleMethod, object : XposedInterface.SimpleHooker<Method> {
            override fun before(callback: XposedInterface.BeforeHookCallback<Method>) {
                log(Log.INFO, TAG, "before Application.attach")
            }
        })

is betterr than: hook(exampleMethod, MyHooker::class.java) but it doesn't solve all cases.

Previously (rovo api), I could pass an instantiated object with data into variables, but now, within the class, in the before/after methods, I have to invoke get* methods each time to get the values ​​I need, because I no longer have an object but a static class. With these new APIs, the convenience of object-oriented languages ​​is lost. In my opinion, this is a worsening of the situation.

Thank you for your suggestion. For your concern, I don't understand fully because there isn't a static class but a hooker object. We currently redesigned a new OkHttp style interceptor interface to replace the old AOP style one. You can have a look at the example repo to see if this meets your need.

[yashikada]

because there isn't a static class but a hooker object.

sorry my fault, I analyzed the patch badly, I'll wait for the merge to try it

[vvb2060]

@programminghoch10 Resource hooks have been replaced by SDK API, we will redesign resource hooks based on runtime resource overlay.

[programminghoch10]

Resource hooks have been replaced by SDK API, we will redesign resource hooks based on runtime resource overlay.

Sure, a resource hook overlay mechanism similar to or using FabricatedOverlay would be an useful API for resource hooks and would allow replacing resources in a similar fashion as before.
It would be nice if the new API would support the same devices as before, there are many devices on SDK <34 where FabricatedOverlay didn't exist yet. Furthermore overlays itself have been introduced in SDK 26, so devices older than that would be out of the question for newly developed modules completely.

More importantly however, resource overlays do not enable layout hooking, programmatically modifying the layout after inflation but before it is inserted into the view tree is very useful for many UI modification modules.
Will there be a suitable replacement for layout hooks?