YukiHookAPI: a Kotlin rebuild of the Xposed API for module authors

A Kotlin layer over Xposed rather than a new runtime

The repository describes itself as an efficient Hook API and Xposed Module solution built in Kotlin, and that description is accurate in a specific way. This is not a new runtime that injects code into Android apps. It is a Kotlin layer sitting on top of the existing Xposed API, giving it Kotlin-shaped extensions for writing modules. The README calls it a rebuild based on the Xposed API, and the project has a lineage that explains the shape. It was formerly the Innocent Xposed API, used inside the fankes/TMore development learning project, before being renamed and open sourced under the HighCapable organization.

The name comes from a character rather than from a technical idea. The README credits Yuki Kurihara from the anime series it links. That detail is worth noting only because it tells you how the project presents itself: as a polished, self-branded library with its own documentation site, badge row and chat channels, not as a research prototype left on a shelf.

At 2,186 stars, 158 forks and 3 open issues, under Apache-2.0 with Kotlin as the primary language, this sits in the small group of Android hooking libraries that are still being maintained.

Three Gradle modules and a matched pair of samples

The repository tree is short and it carries most of the architecture. Three Gradle modules make up the library: `yukihookapi-core/`, `yukihookapi-ksp-xposed/` and `yukihookapi-stub/`. The names describe their jobs. The core module holds the API surface. The KSP module is a Kotlin Symbol Processing plugin, which is how a modern Kotlin project generates hook metadata at compile time rather than discovering members reflectively at runtime. The stub module exists so your code can compile against the hook framework without the framework being on the compile classpath, which is the normal arrangement for modules that load into a process where the real API classes are supplied by the runtime.

Alongside those sit `samples/demo-app/` and `samples/demo-module/`. A demo app paired with a demo module is the correct combination here, because you need an APK you control so the module has something to hook, and you need the module to show how a real entry point is declared. The root of the tree is conventional Gradle, with `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties`, `gradlew` and `gradlew.bat`, plus `docs-source/`, which is the documentation site living in the repository rather than in a separate docs project.

Who is actually shipping modules on top of it

The adopters table is the most concrete evidence that the library survives outside the author's own projects, and the list is heavily weighted toward Chinese Android customization modules. It includes TSBattery for battery information, MIUI and ColorOS notification icon modules, and modules for forcing screen rotation, refusing forced brightness, enabling WebView debugging, suppressing MIUI gestures, restoring the splash screen, forcing landscape orientation and enabling NFC automatically. There are also reading-app modules such as QDReadHook, HXReadHook and WxRecordRead, and several ad removal projects including Fuck AD, Zuiyou ADFree and Dingda ADFree.

Two observations follow from that list. The recurring themes are manufacturer skin behaviours and deliberately locked features, which is the niche Xposed exists for and where no equivalent public API exists. Second, the same handful of developers appear across many entries, so the table demonstrates sustained use more convincingly than it demonstrates a broad independent ecosystem. The README and its Simplified Chinese counterpart are maintained in parallel, which fits where those adopters are.

For a reader deciding whether to adopt the library, the honest read is that the adopter list shows the library works on real devices against real vendor skins, and that its community is concentrated rather than diffuse.

The 1.3.0 release removed a pile of old constraints

Release 1.3.0, published on 2025-06-25, is the version to read first if you are porting an existing module, because it lifted several constraints at once. The project's own reflection API was deprecated in favour of KavaRef, a separate reflection library from the same author that the README describes as the driver behind YukiHookAPI's reflection handling. The old limitation on duplicate hooks was deprecated, so the same method can now be hooked repeatedly instead of being rejected as a conflict. The `ModuleAppActivity` and `ModuleAppCompatActivity` classes were deprecated in favour of `ModuleActivity`, which means a proxy Activity is your own subclass now. `YLog` accepts any object as its message and converts it to a string for printing, and `FreeReflection` was dropped in favour of AndroidHiddenApiBypass from the LSPosed project.

The two releases after it are smaller and read like maintenance. 1.3.1, from 2025-09-13, fixed Activity proxy issues on Android 9 and earlier, and fixed a case where return values were still being checked when a hook method's return type was `Object`. 1.3.2, published on 2026-05-30, moved the target SDK to 37, resolved dependency conflicts with BetterAndroid, and adjusted API code style without changing function signatures. The release notes themselves point to a changelog page on the documentation site for the detail rather than carrying it inline.

Two version lines running at once

The current development line is 1.5.0, and the README describes it as recruiting for public beta with one specific feature: building modules against the libxposed framework. The README gives an end point of around 2026.10 for the beta, after which the first official release is planned. That framing says something about the project's priorities. The Xposed API that YukiHookAPI wraps has been superseded by libxposed, and a hook library supporting only the older interface would be building against a shrinking target.

There is a second track running alongside it. The README points to a `2.x` branch where the version is being refactored, and says you can switch to that branch to see current progress. So the project maintains two lines simultaneously: a 1.x line being stabilised for libxposed, and a 2.x line undergoing structural change. The default branch is `master`. Anyone starting a new module today has to decide whether to target 1.5.0 when it ships or wait for 2.x, and the README does not settle that question. It only tells you both tracks exist.

Where the repository stops and the documentation site begins

The README is short by design, and unusually so for a library of this size. It contains no install command, no Gradle dependency snippet and no runnable code fence at all. That means the repository page cannot get you from clone to a compiling module on its own. What it does offer is a route: the documentation site at highcapable.github.io/YukiHookAPI holds the tutorials, and a separate supportive page is linked for the background material around them.

The documentation source is not kept somewhere else. `docs-source/` sits in the tree, so the site content is versioned alongside the code, and the release notes link to a changelog page on the same site. This split has a practical consequence for evaluating the project. The repository tells you the module layout, the release history, the deprecations, the branch strategy and the adopter list, which are exactly the things worth reading before committing to a library. It does not tell you how to declare a hook, how the KSP processor is configured in a build file, or what the 2.x architecture changes are. Those answers live on the site.

The last push recorded on the repository is dated 2026-09-26, and the project is not archived, which is consistent with a library in active development across both lines.

Editorial conclusion

YukiHookAPI is a well-organised Kotlin layer over Xposed rather than a new hooking runtime, and its value shows up in the details: a compile-time KSP module, a stub for building against the framework, and a sample app paired with a sample module. The 1.3.0 release removed the rough edges that would have bitten anyone porting an older module, and 1.5.0 is aimed at libxposed rather than the API it grew up on. The gap worth planning around is documentation, because the README carries no runnable example at all. Start with the module layout in the repository, then work through the 1.3.x migration guide if you are porting, and treat the 2.x branch as something to watch rather than something to build on.

Frequently asked questions

Official sources

1. HighCapable/YukiHookAPI on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases