MultiApp runs cloned Android apps by replacing the binder rather than proxying it

The repository is unmaintained and the developer says why

The README opens with a Business Warning that is worth reading in full, because it explains the current state of the project better than any changelog could.

Over a long period of time in the past, through user feedback, servers, internet safety departments and other channels, we have discovered a variety of cheat software that seriously infringed on commercialization and Internet security. We have emphasized industry security from the beginning and prohibited illegal uses. From today on, github will no longer be maintained. If you need to use multi-open software, please download from GooglePlay Store. For business cooperation, please contact the only legal WeChat: WaxMoon2018.

The Maintenance Status section says the same thing more briefly. This repository is no longer maintained as of 2023; please contact directly for commercial use.

So there are two things going on. The open source repository is frozen as of 2023, and the commercial product continues as a Google Play application, MultiApp Ultra at com.waxmoon.ma.nova.gp and the simpler GooglePlay MultiApp at com.waxmoon.ma.gp.

The last push to the branch was on 2026-06-27, so something moved in the repository after the announcement, and the release history stops at v1.0.12 from 2023-08-10, with v1.0.11 in May 2023 and v1.0.10 a week earlier. The tags are tightly packed and old.

The licence is AGPL-3.0, which is a significant fact for anyone who wants to use the code. The AGPL reaches network use, and the copyright header on the file is the usual one. The project is Kotlin, the badges say Android 6.0 to 13 and the architectures are armeabi-v7a and arm64-v8a, and the README links a Chinese version of the readme at docs/READEME-zh-CN.md.

The author also points out that the SDK is a separate thing. You can use the api provided by opensdk to open more apps, and in addition, we will continue to fix problems and update opensdk code to provide you with the best experience. The opensdk directory is a submodule at the top level, alongside app/, assist/ and docs/, so the SDK is developed in its own repository and consumed here.

The technical argument is about proxies overlapping

The Principle Introduction section is the part of the README with real engineering content, and it argues a specific point.

The traditional multi-opening solution relies on java dynamic proxy, inline hook, proxy forwarding and others to ensure the app runs in the virtual process. The problem follows immediately. If the third-party app also uses the java dynamic proxy, there will be a problem because the proxies will overlap each other, which will cause the third-party app's code logic to change when it is running. The README calls the resulting logic changes crazy and says they may affect the app's earnings, and concludes that traditional solutions cannot be defined as containers.

That is a good framing of the problem. If an app uses dynamic proxy itself, for a plugin system or for a mocking layer, and the container also injects a proxy at the same interception point, the two proxies nest. The app then sees a different call path than it would natively, and behaviour that depends on the identity or the type of an object changes. A banking app or a game with anti-cheat logic that inspects a call stack is exactly where this shows up.

The design decision follows from that diagnosis. At the beginning of MultiApp's technology selection, java dynamic proxy was abandoned, and binder components such as service, receiver and provider are all maintained by the MultiApp engine itself. The Activity component has to keep its life cycle through a proxy, which the author calls a pity, but the project uses a more reliable solution to ensure it does not affect the code logic of the app.

And there is a second mechanism. The project has developed a more effective svc hook solution based on seccomp and bpf in native hook technology, and will enable it in some scenarios such as the 360 shell app. The conclusion the README draws is that in general, we are closer to the sandbox concept.

So the architecture is: do not proxy what the app may proxy itself, own the binder plumbing so the interception point is inside the platform rather than inside the app's own process, and use a syscall level hook for the remaining cases.

Two demos that make the proxy argument checkable

The README backs the proxy claim with two concrete demonstrations, and that is what makes the argument verifiable rather than assertive.

The first is a stack trace comparison. The demo prints the code running stack in the Activity.onCreate function, and the same app is opened three ways, with traditional multi-open software, with MultiApp and with the android system.

public class MainActivity extends ButtonActivity {

    final static String TAG = "MainActivity";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        new Exception().printStackTrace();
    }
}

The README then states the result plainly. The code stack of the first picture is abnormal because the app is running in traditional multi-open software, the second picture is the code stack run by MultiApp and the third is the android system. The three images are in docs/res as stack_other.png, stack_MultiApp.png and stack_system.png.

So the demonstration is that the stack under the traditional approach contains frames that should not be there, and the stack under MultiApp resembles the system's own. That is a checkable claim, and the second demo checks the mechanism directly.

The second demo determines whether the binder interface of ActivityManager is dynamically proxied, and it runs in traditional multi-open software and in MultiApp.

Class<?> class_ActivityManagerNative = Class.forName("android.app.ActivityManagerNative");
Method method_getDefault = class_ActivityManagerNative.getDeclaredMethod("getDefault");
IInterface remote_ActivityManager = (IInterface) method_getDefault.invoke(null);
boolean isProxy = remote_ActivityManager instanceof Proxy;

So it reflectively fetches the ActivityManagerNative singleton, calls getDefault to obtain the binder proxy and then asks whether that object is itself a java.lang.reflect.Proxy. Under a traditional implementation the answer is yes, and under MultiApp it is no, because the binder is owned by the engine rather than layered with a dynamic proxy on top.

That is a well-constructed pair of demonstrations. The first shows the symptom and the second identifies the cause, and a reader who wants to check the claim can run the same code against their own build.

The product is a multi-account assistant, and the docs say so

The two Google Play products are described separately and they are not the same thing.

MultiApp Ultra is a modern-style Android multi-account assistant that allows you to use multiple instances of the same app and run multiple accounts simultaneously on a single phone, including WhatsApp, Facebook, Instagram and WeChat. The README gives three properties: it is compatible with major smartphone brands such as Xiaomi, Samsung, Huawei, OPPO and Vivo, and supports Android versions 8 through 17, with Google Play Services support giving access to premium games and apps from both domestic and international markets, and it operates within an independent virtual environment, free from system restrictions, ensuring a simple, stable and efficient experience. The feature list under the Chinese heading covers the home page, the navigation page, a private space, a storage manager and settings.

GooglePlay MultiApp is the simpler and free one, described as a simple and easy-to-use Android multi-opening assistant that can use multiple identical applications and run multiple accounts on one mobile phone, with the same list of apps.

So the commercial positioning is a multi-account assistant, and the open source repository is the sample UI and the container engine behind it. The Project Introduction section says so. MultiApp is a virtual Android container which can open more apps, and this project provides a simple UI for you to experience, and if you are an Android developer you can also customize your own UI, and you do not need to pay attention to the technical details that are difficult to understand.

The best practice section points at a separate repository, MultiAppDemo, and the video links in the README show a run without Google Play installed and a run with multiple Facebook instances open, and the clips are hosted in the repository.

For a developer, the realistic use of this code is the opensdk, since that is what the author says is still being updated.

Where MultiApp is the wrong choice

The first wrong case is a team that needs a maintained codebase. The repository is no longer maintained as of 2023, the last tagged release is v1.0.12 from August 2023, and the author directs users to the Play Store build. A team that wants to build a product on this code is depending on a frozen snapshot and on a separate SDK whose maintenance is promised but not scheduled.

The second wrong case is a project that needs the app to behave exactly as it does natively. The author's own claim is that the Activity component still has to keep its life cycle through a proxy, which he describes as a pity, and that the seccomp and bpf hook is only enabled in some scenarios such as the 360 shell app. So the fidelity is high but not perfect, and a target app that is sensitive to the difference may still misbehave.

The third wrong case is anything on a modern Android. The badges say Android 6.0 to 13, and the engine relies on maintaining binder components, which is exactly the part of the platform that changes between releases. A container that owns the binder plumbing has to be rebuilt whenever the platform's internals move, and the project stopped doing that.

The fourth wrong case is a commercial deployment that needs support, which is where the author's business warning becomes a practical obstacle. There is no issue tracker to file with, the supported path is the Play Store application, and commercial use is routed to a WeChat contact rather than to a public support channel.

How it differs from the usual cloned-app approach

The comparison worth making is with the class of tools that make multiple instances of an app on one phone, and the difference in approach is where the interception happens.

The usual approach, and the one the README describes as traditional, injects into the target app's process. A helper library is loaded, it installs java dynamic proxy on system services, it intercepts calls and redirects them to a virtualised instance. The result is that the app believes it is talking to the system while it is talking to the proxy, and the proxy forwards to a container it maintains.

MultiApp's approach is to own the layer below. The binder components, service, receiver and provider, are maintained by the engine, so the interception happens in the platform plumbing rather than in a proxy wrapped around it. The Activity lifecycle is the acknowledged exception.

The second difference is what a third-party app sees. A stack trace under the traditional approach contains frames that are not part of the app, and an app that inspects its own call stack, or that checks whether a binder object is a Proxy, can tell. That is not hypothetical for apps that use dynamic proxy for their own plugin systems, and it is why the README's second demo exists.

The third difference is the fallback. When owning the binder is not enough, the project uses a native hook based on seccomp and bpf to intercept at the syscall level, which is a much lower level than the app can observe. That is the direction the project describes itself as moving in, closer to the sandbox concept.

The fourth difference is the honesty about the trade. A container that intercepts below the app sees more and changes less, but it also has to track the platform's internals closely, which is why this approach needs a dedicated engine and why the alternative, a proxy, is easier to ship and easier to keep working across Android versions. The README argues the proxy route is not really a container at all, and the two demos are the argument.

Editorial conclusion

MultiApp is worth reading as a technical reference, because the README explains in unusual detail why the usual approach to cloning an Android app breaks, and it is accompanied by a separate open source SDK that the author says is still being updated. It does not fit a project that needs a maintained codebase to build on, since the repository is no longer maintained as of 2023 and the last push was on 2026-06-27, and the author asks users to take the binary from Google Play rather than build from source. Before adopting anything from it, read the licensing terms, since AGPL-3.0 applies to the source, and check the opensdk repository, which the README says receives the ongoing updates.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. WaxMoon/MultiApp on GitHub