asLody/VirtualApp: the open source Android sandbox that stopped shipping code in 2017

What VirtualApp actually does, and who the README is written for

VirtualApp, abbreviated VA in its own documentation, is a sandbox that runs Android apps inside another Android app. The host app integrates the VA library, and apps installed into that library run without being installed by the system. The README calls the product a lightweight Android virtual machine and describes its form as an extensible, customizable SDK.

The stated use cases are broad: app cloning for multiple accounts, collections of small games, game accelerators, account rental, gamepad activation without root, VR program porting, blockchain, mobile office security, data isolation for government and military use, scripted automation, plugin development, hot updates and cloud control. That list is the README's own, and it is a marketing list rather than a set of documented integrations. The realistic audience is an Android engineer who needs one of two things: to run a second copy of an app the user already has installed, or to install and run an APK that the system never sees.

One detail matters more than the feature list. The README states plainly that the GitHub code stopped updating in December 2017, and that the commercial version keeps updating. The repository is not archived and the last push to master was on 2026-09-15, but the README's own statement about the public code is the thing to weigh when you decide what you are adopting.

The three layers: VA Space, VA Framework and VA Native

The core trick is deception. An app installed into VA is not installed in the system, so the system would normally refuse to run it. VA makes the system believe otherwise. The README breaks this into three layers.

VA Space is the internal area where apps destined to run inside VA are installed. It is isolated from the system. VA Framework sits between the Android framework and the virtual app, proxying both directions: when the virtual app calls a system service, VA Framework rewrites the parameters that describe the app's installation identity, replacing them with the host's parameters before forwarding the call, and some calls go to VA's own server instead. When the system returns a result, VA Framework intercepts it and restores the original parameters. The virtual app and the system can then complete the exchange without the system noticing.

VA Native handles two jobs the Java layer cannot. File IO redirection exists because some apps access hardcoded absolute paths that only exist when the app is actually installed; VA redirects those paths into the internal installation location. Native hooking covers JNI functions that cannot be hooked from VA Framework. The README does not enumerate which JNI functions fall into that category, so treat the boundary between the two layers as undocumented.

Five process types and the two-package 32/64-bit split

VA runs as five process types. CHILD covers other processes the host integrates, such as keep-alive or push processes. VA Host Main is the main package's UI process. VA Host Plugin is the plugin package's process. VAPP Client is the process created when an app installed inside VA starts, and its process name is rewritten from the internal form io.busniess.va:pxxx to the real app process name. VAServer handles requests VA does not forward to the system, app installation being the example the README gives.

The two-package requirement follows from a hard Android constraint: one package runs in one mode, 32-bit or 64-bit. To run both kinds of app, VA needs a main package and a plugin package. The README says the main package contains all of VA's code and the plugin package contains only the code that loads and executes the main package, which is why the plugin package almost never needs updating. Which package is 32-bit and which is 64-bit is set in a configuration file; the README notes that developers targeting Google Play switch to a 64-bit main package with a 32-bit plugin. That configuration file is not shown in the README, so the exact key names are not verifiable from what is published.

Installing VirtualApp and running your first virtual app

The README does not publish a Gradle coordinate, a Maven artifact or a download URL. It describes integration as similar to an ordinary Android library and presents three API calls as the whole of basic usage. Because the repository ships the VirtualApp/ directory as source, the practical path is to include that module in an Android project and call the APIs from your Application class.

The README gives the startup call for your Application:

VirtualCore.get().startup()

The second call installs a target app into VA under a user id, passing the user id and the package name:

VirtualCore.get().installPackageAsUser(userId, packageName)

The third launches it:

VActivityManager.get().launchApp(userId, packageName)

The README states that these three APIs complete basic usage. What it does not state is what startup() returns, what happens when installPackageAsUser fails, or which thread these calls must run on. Those are the first things you will hit in practice, and the README is silent on all of them.

Where VirtualApp breaks down, and when it is the wrong tool

The largest limitation is stated by the project itself: the GitHub code stopped updating in December 2017. The README's compatibility table lists support from 5.0 through 17.0, but that table describes the commercial line, not the snapshot in this repository. If you clone master expecting Android 14 or 15 support, the README gives you no basis for that expectation. The repository description mentions support for 14.0 in the business version, which is another way of saying the free code is not where that support lives.

The two-package architecture is a second constraint. You cannot ship a single APK and cover both 32-bit and 64-bit apps; you ship a main package plus a plugin package, and the plugin package must be installed for the other ABI to work. That is a real product decision, not a build detail, and it affects your store listing and your update flow.

A third issue is the README's own framing. It advertises the ability to audit user behavior, upload chat and transfer records in real time, intercept sensitive keywords, prevent screenshots and inject watermarks. Those are capabilities a sandbox of this kind enables, and the README presents them as selling points. Whether that is appropriate for your product is a decision the README does not help you make, and it is the reason the project's audience skews toward enterprise control scenarios rather than ordinary app development.

Finally, the repository states no license. The README directs anyone who wants the latest code to contact a WeChat account for authorization. Treat the code in this repository as something to study, not something to ship, until you have clarified the terms.

How VirtualApp differs from repackaging, custom ROMs and rooted Xposed

The README includes its own comparison table against three alternatives, and the comparison is the most useful technical content in the document.

Repackaging means decompiling the target app, inserting your control code and rebuilding it. The README's objection is practical: most apps now ship with hardening or tamper protection, the system may flag a repackaged app as a security risk or refuse to install it, and every app version requires fresh reverse engineering. Performance is rated excellent, compatibility poor, maintenance cost high.

A custom ROM means modifying system source and flashing it to specific devices. Performance and stability are both rated excellent, but the README notes it only works on the devices you control. Rooting the phone and flashing something like Xposed is rated excellent on performance and poor on compatibility, with the added objection that rooting is difficult to ask of users and increasingly difficult to do at all.

VA's own column claims excellent performance and stability with low maintenance cost, on the grounds that it is a process-level virtual machine rather than an interpreter. That claim is the project's, not a measurement, and the README offers no benchmark. The structural difference is real, though: repackaging and ROM modification change the app or the system, while VA leaves both alone and intercepts the boundary between them.

Maintenance, upgrades and what the license silence costs you

Upgrade cost depends entirely on which line you are on. The README says the plugin package contains only loader code and almost never needs updating, while the main package carries everything. That is a favorable update story if you are on the commercial line. On the public repository it is moot: the README states the GitHub code stopped updating in December 2017, so there is no upgrade path to plan for. The last push to master was on 2026-09-15, which is consistent with the repository being maintained as a public face while the code itself is frozen per the README.

On licensing, the repository states no license, and the README frames the current code as something you obtain authorization for by contacting a WeChat account. That is a commercial-license posture, not an open source one, regardless of where the code is hosted. I am not a lawyer and this is not legal advice, but the practical reading is that the absence of a license file means you have no granted rights to redistribute or ship this code. If your plan depends on shipping it, resolve that before you write integration code.

Editorial conclusion

VirtualApp is worth reading if you want to understand how a no-root Android sandbox intercepts framework calls and file paths, and the three-call integration in the README (VirtualCore.get().startup(), installPackageAsUser, launchApp) is enough to get a prototype running. It is the wrong choice if you need support for current Android releases, because the README states the GitHub code stopped updating in December 2017 while the commercial branch carries the newer versions. Before committing, verify the licence terms for the code in VirtualApp/, since the repository states no license, and confirm which Android versions the particular snapshot you cloned actually builds against.

Frequently asked questions

Official sources

1. asLody/VirtualApp on GitHub
2. Issues
3. README