程序包 io.github.libxposed.api

package io.github.libxposed.api
Modern Xposed Module API.

This package provides the public API for developing Xposed modules using the modern Xposed framework. It replaces the legacy XposedBridge API with a redesigned, type-safe interface.

Getting Started

Module entry classes should extend XposedModule. The framework calls attachFramework() automatically; modules should not perform initialization work before onModuleLoaded() is called.

Entry Registration

Java entry classes are listed in META-INF/xposed/java_init.list (one fully-qualified class name per line); native entries use META-INF/xposed/native_init.list. Place these files under src/main/resources/META-INF/xposed/ and Gradle will package them into the APK automatically.

Module Configuration

Module metadata is specified via standard Android resources (android:label for the module name, android:description for the description) and META-INF/xposed/module.prop (Java Properties format). Required properties:

  • minApiVersion – minimum Xposed API version required
  • targetApiVersion – target Xposed API version

Optional properties:

  • staticScope (boolean) – whether the module scope is fixed and users should not apply the module on apps outside the scope list
  • exceptionMode (string) [protective|passthrough] - Default to protective, see XposedInterface.ExceptionMode

Scope

Module scope is defined by a list of package names in META-INF/xposed/scope.list. The framework injects the module into all regular processes declared by those packages. After injection, every loaded package in that process will trigger callbacks. As a result, modules may receive callbacks beyond the originally scoped packages, so they should always filter by process name and package name.

A special case applies to components declared with android:process="system" in a android:sharedUserId="android.uid.system" package: they run in system server. For packages whose components all run in system server, adding the package name itself to the scope has no effect. Instead, system server is represented by the special virtual package name system, which should be used explicitly.

Note that android package is still a valid scope target because some of its components declare android:process=":ui" and therefore do not run in system server. Modules scoped to android can still receive events for android package loading even though android package has no code. By contrast, com.android.providers.settings is not a valid scope target, modules should use the system scope and then wait for the com.android.providers.settings package loading event.

Hook Model

The API uses an interceptor-chain model (similar to OkHttp interceptors). Modules implement Hooker and its intercept(Chain) method. Hooking is performed through a builder returned by hook(Executable):


 HookHandle handle = hook(method)
     .setPriority(PRIORITY_DEFAULT)
     .setExceptionMode(ExceptionMode.PROTECTIVE)
     .intercept(chain -> {
         // pre-processing
         Object result = chain.proceed();
         // post-processing
         return result;
     });

Invoker System

To call the original (or hooked) method bypassing access checks, obtain an Invoker via getInvoker(Method) or getInvoker(Constructor). The invoker type controls what part of the hook chain is executed (see Invoker.Type).

Module Lifecycle Callbacks

Override the following callbacks in XposedModule:

Error Handling

Framework-level errors are reported via subclasses of XposedFrameworkError. In particular, HookFailedError indicates a fatal hook failure that should be reported to the framework maintainers instead of handled by the module.

另请参阅: