Katana SPatch-Update: the UI shell for a commercial Android app container

What the repository actually is

The GitHub description is one line: Update for SPatch nightly. The README opens with a different title entirely, Metaverse Engine Launcher UI, and then spends most of its length on a commercial section rather than on the code. That gap between the two is the single most useful thing to know before you clone anything.

The commercial section states that you can use the project freely, then invites you to contact the authors for SDK support through a Telegram group or by email. It says the launcher UI is based on a project called Mundo, and that the SDK is not open source: you obtain it, along with constant updates, by purchasing a commercial license.

The build instruction that follows is the practical consequence. Before compiling, place your own SDK file in the right place. The tree shows why you cannot skip that step: it is `app/`, `build.gradle`, `gradle.properties`, `settings.gradle`, `.gitignore`, `LICENSE.md` and `README.md`. There is no SDK directory, no `libs/` folder of binaries, no library module. What you would compile without the paid SDK is a Gradle project with nothing to compile against.

So the honest framing is this: the repository is a sample UI and integration example for a closed platform, published to show what building on the SDK looks like. The README even invites Android developers to customize their own UI by downloading the source, which is consistent with that reading.

The launch API is two method calls

The starter code is the entire integration surface, and it is short enough to show in full. The README offers a single-argument form first:

    MetaActivityManager.launchApp(
        applicationPackageName
    );

Then the two-argument form, which takes a user partition name first. That second parameter is the interesting one: partitions are how a container runs several instances of the same app, each with its own data, which is the core feature of the product this UI fronts.

    MetaActivityManager.launchApp(
	    userPartitionName,
        applicationPackageName
    );

The README calls this sample code for starters and noobs, then points at an external documentation site for the full API list. That is the shape of the whole project: a small readable surface here, everything else off-repo.

What is notable is what the README does not show. There is no permission declaration to copy, no manifest configuration, no initialization call for the container itself, no build.gradle snippet in the documentation. If you are evaluating whether you could build a launcher for this SDK from what is in this repository, the answer is no, and the README is upfront about needing the paid SDK and the external docs to go further.

Credits reveal what the container is built from

The most substantive part of the README is the credit list at the bottom, and it is a good map of the Android hooking stack the product depends on.

SHook comes from a Gitee repository, a Chinese code host, which tells you something about where the Xposed compatibility layer originates. LSPlant is from LSPosed, the successor to the Xposed framework that Android app hooking communities standardised on. AnyFile2Byte is credited to the same Katana organisation, so it is in-house rather than borrowed. GraphScope is Alibaba's, Il2CppDumper is Perfare's, ShadowHook and ByteHook are both from ByteDance, and dexmaker is from LinkedIn.

That list is the real technical content of the README. App cloning and containerization on Android is not a single technique: it needs inline hooking at the native level (ShadowHook, ByteHook), runtime method manipulation (dexmaker), native library loading (AnyFile2Byte), Xposed framework compatibility (SHook, LSPlant), Unity IL2CPP inspection (Il2CppDumper), and a tracing layer (GraphScope). Anyone evaluating this SDK is really evaluating that dependency set.

It also explains the feature list the README gives for SlimVXposed: Xposed framework support, GMS in a commercial flavour, game modifying, unlimited app clone, device information spoofing. Those are capabilities you would assemble from exactly these parts. The README describes SlimVXposed as a powerful Android container that can open more apps, and says this repository provides a simple UI so you can experience it.

Release history and the two products

There are three releases, and their tag naming is inconsistent in a way that will matter if you script anything against them. V1.0.29 and V1.0.28 use a capital V prefix, while 1.0.27 drops it entirely.

The most recent, V1.0.29, was published on 2026-08-27 and its entire body is two lines: bugs fixed, and support for Android 17 QPR2. V1.0.28 from 2026-04-24 says support for Android 17 and bugs fixed. The version before that, 1.0.27 from 2025-10-24, is the most informative: major issues fixed, performance optimization, and something about No Xposed functionalities improvement. The last phrase is likely a typo for non-Xposed, which would mean the 1.0.x line reduced its dependence on the Xposed framework.

That reading matters, because the feature list advertises Xposed framework support as a headline capability while the newest release notes mention improving the non-Xposed path. The direction of travel is away from the framework that two of the six credited projects exist to support, which is a normal and healthy thing for a container product to do, but it means the README's feature list describes the ceiling rather than the current floor.

The repository's own changelog section is thinner still: a single entry reading Oct. 2023, Initial upload mi project. The typo is in the original. So the README changelog has not been kept up, and the GitHub releases are the only usable history. With 2,308 stars, 186 forks and 105 open issues, and a last push on 2026-08-27 matching the newest release, this is an actively maintained wrapper around a product you have to buy.

Documentation lives off the repository

Three separate destinations carry the real documentation, and none of them is on GitHub. The API documentation link is an external site at bienvenido.top, linked twice in the README with the instruction to read more documents there. The product itself is at die.lu, which appears as the official web page for the downloadable APK and as the domain behind the SlimVXposed and SPatch links. The support channel is a Telegram group.

The contact details are a bare email address at that same die.lu domain and the Telegram link. That is the entirety of the support surface for a project with 2,308 stars.

There is a licensing question worth taking seriously here. The repository's machine-readable license field is NOASSERTION, the tree contains a LICENSE.md, and the README carries a Creative Commons Attribution 4.0 International notice applied to the launcher UI artwork. Those are three different signals about three different things, or possibly one inconsistency. The CC notice reads as covering the UI assets rather than the source code, so before using any of this in a product you would build, read LICENSE.md directly and confirm with the authors what the terms are.

The language on the repository is Java with a Gradle build, which is the conventional Android stack, and the default branch is master rather than main. Neither detail tells you much, but combined with the tiny tree they set the expectation: this is a sample app, not a framework.

Who should use this, and who should not

There are two audiences and they are reading different things.

If you are an Android developer evaluating app containers, cloning this repository gets you a working reference for the launch API in about as many lines as the README shows, plus a credit list that tells you which hooking projects the platform is built from. That is a reasonable afternoon of value. The `MetaActivityManager.launchApp` call with a partition name is the piece to understand, because partitioning is the whole product.

If you are looking for an open-source Android container, this is the wrong repository. The code you would want to audit is the SDK, and the README states plainly that it is not open source. A container holds your app data and runs other apps inside it, which is a category where source availability matters more than usual, and the fact that the interesting part is closed is not a criticism of the authors so much as a fact about where the product sits.

There is also a legal dimension worth naming plainly. Android app cloning, device information spoofing and game modifying exist in a space where the line between a developer testing their own app and a user running someone else's is both blurry and enforced. GMS in a commercial flavour means Google services in a container you control. None of that makes the SDK unusual, but it does mean the deciding question is not technical: it is whether the use you have in mind is one you would want to describe publicly.

What the repository demonstrates well is that the UI half of a commercial SDK can be published without leaking the SDK itself. Two sample calls, a Gradle skeleton, an honest note that you need to buy the rest. That is a coherent publishing decision.

Editorial conclusion

SPatch-Update is a wrapper, and the repository says so in plain language rather than hiding it: the SDK is not open source and you have to place your own copy before compiling. That makes the star count a measure of interest in the SlimVXposed product rather than adoption of this code, and the credit list is a better signal of the engineering involved, since ShadowHook, ByteHook, dexmaker, LSPlant and Il2CppDumper are real projects with real authors. If you want to evaluate the container, read the README's feature list for SlimVXposed and then look at the product site, because the UI here is a sample. If you want to evaluate the code, the tree is small enough to read in one sitting and the API documentation off-repo is where the substance is.

Frequently asked questions

Official sources

1. Issues
2. Katana-Official/SPatch-Update on GitHub
3. README
4. Releases