MustardChef/WSABuilds: prebuilt WSA with Google Play and Magisk

What WSABuilds actually distributes

Microsoft shipped Windows Subsystem for Android as a component of Windows, then stopped developing it. WSABuilds does not reimplement that runtime. It takes the Microsoft WSA image and repackages it with the pieces Microsoft did not include: MindTheGapps for Google Play Services and the Play Store, and Magisk or KernelSU for root. The output is a set of .7z archives published as GitHub releases, tagged by Windows version and build, for example Windows_11_2407.40000.4.0_LTS_8 and Windows_10_2407.40000.4.0_LTS_8.

The audience is narrow and specific. You are on Windows 10 or Windows 11, you want Android apps running through the Microsoft subsystem rather than through BlueStacks or another emulator, and you want either the Play Store or root, or both. If any of those three conditions does not hold, this project is not aimed at you. The repository itself is Python, but the primary language entry describes the build tooling, not something you install to use the releases.

The README frames the project as MagiskOnWSA for Windows 10 and 11, which is the honest description: this is a distribution and build-automation effort around someone else's runtime.

How the build and install path is structured

The repository layout shows the shape of the work. MagiskOnWSA/ and MagiskOnWSAOld/ hold the build logic, Documentation/ holds prose guides, and WSABuilds Utilities/ holds helper scripts. Releases are the artifact channel, not the source tree. Nothing here asks you to compile WSA; you download a finished archive.

That matters because it fixes where failures come from. When the runtime misbehaves, the cause is usually upstream Microsoft code, the GApps integration, or the Windows build underneath, not the packaging script. The README reflects this: the fixes it points to are workarounds inside issue threads, not patches in the tree.

The LTS naming is also a signal. The September 2026 releases are described as a hotfix for the ARM translation layer (Libhoudini), which tells you the project tracks upstream component breakage and reissues archives when a layer stops working. You are consuming a maintained binary stream, not a stable API.

Installing WSABuilds and getting to a first app

Start at the downloads table in the README and pick the archive matching your Windows version and architecture. Windows 11 x64, Windows 11 arm64 and Windows 10 x64 each have their own release tag. Older builds live in Documentation/WSABuilds/OldBuilds.md if the current one does not work on your machine.

The README gives no extraction or registration command sequence, and the repository files do not contain one either. What the README does give is the archive itself and the release tags: you download the .7z for your platform, extract it, and use the contents. The README's first troubleshooting instruction is not to inspect a script but to confirm you are on the latest LTS release, because the September 2026 hotfix exists precisely because older archives broke.

Once the subsystem is registered and running, the Play Store is present in GApps builds, and Magisk appears as an app in the Android app list. If you downloaded a NoGApps archive, neither is there, which is the point of that variant.

For the current GApps crash, the README points to a specific comment rather than a general fix. The recommended workaround it names is the comment at https://github.com/MustardChef/WSABuilds/issues/593#issuecomment-3172749449. Read that thread before you install, not after.

The GApps crash is the deciding constraint

The README opens with a caution block stating that GApps builds have been crashing on all Windows 11 builds after June 2025, and that fixes are being worked on in issue 700. This is the single most important fact about the project right now, and it is stated by the maintainer, not inferred.

The workarounds listed are concrete. Use the recommended fix in issue 593. Or switch to a NoGApps build, identifiable because the .7z archive name contains NoGApps. Or fall back to very old WSA builds, 2211 and 2210, which the README says are known to be working.

Each of those is a real trade-off. NoGApps means no Play Store and no Google services, which defeats the main reason most people come here. Rolling back to 2211 or 2210 means running a runtime several years behind, with whatever app compatibility that implies. The issue-593 fix is a workaround, and the README describes it as such.

If your use case depends on Google Play working reliably on a current Windows 11 build, that dependency is not currently satisfied by this project's own account. Treat that as the gating question, not as a footnote.

Where WSABuilds is the wrong tool

WSABuilds is the wrong choice if you want an Android environment with a support contract, a release cadence you can plan against, or a vendor to escalate to. There is no vendor. The maintainer is explicit that fixes are in progress and directs users to GitHub issues and a Discord community for status.

It is also the wrong choice if you do not specifically need the Microsoft subsystem. Someone who wants to run Android apps on Windows and has no attachment to WSA is better served by a standalone emulator, which brings its own graphics stack and does not depend on a Windows component Microsoft has stopped developing. Choosing WSABuilds means accepting that upstream risk in exchange for tighter Windows integration and root access.

A third case: if you need Google Play on a Windows 11 build after June 2025 and cannot tolerate the issue-593 workaround, the README's own guidance points you away from GApps builds entirely. That is the project telling you it is not the right tool for that configuration today.

Finally, if you are on an architecture or Windows edition the downloads table does not cover, there is no archive to install. The table lists Windows 11 x64, Windows 11 arm64 and Windows 10 x64. Anything else is outside the supported set.

WSABuilds versus a standalone Android emulator

The comparison people search for is WSABuilds against BlueStacks, and the difference is architectural rather than a matter of features. BlueStacks is an emulator: it ships its own Android runtime, its own graphics translation, and its own update channel, all under one vendor. WSABuilds ships a repackaged Microsoft subsystem, so the runtime underneath is Microsoft's, the Google services come from MindTheGapps, and the root layer comes from Magisk or KernelSU.

That produces different failure modes. With an emulator, an app that will not start is the emulator vendor's problem, and you have a support path. With WSABuilds, an app that will not start may be the Microsoft WSA layer, the GApps integration, or your Windows build, and the resolution path runs through a GitHub issue thread. The September 2026 hotfix for Libhoudini is a good illustration: a translation layer inside the runtime broke, and the project's response was to reissue archives.

The upside of the WSABuilds approach is integration and control. WSA is a Windows component, so it behaves like one, and the Magisk or KernelSU layer gives you root in a way a stock emulator does not. If you need root inside Android on Windows, that is the reason to pick this over an emulator. If you need predictable app compatibility, the emulator is the safer bet.

Licence, maintenance and upgrade cost

The repository is AGPL-3.0, and there is a second licence file, LICENSE-CC-BY-NC-ND, which by its name covers non-commercial, no-derivatives use of some content. The split suggests the code and the documentation or assets are licensed differently. Read both files before redistributing anything from the tree, and note that AGPL-3.0 carries network-use obligations that matter if you build a service on top of the code. That is a description of the licences, not legal advice.

The upgrade cost is real and it is recurring. The README's top notice tells users affected by app breakage after 1 September 2026 to update to the latest LTS release, and the September 2026 releases are hotfixes rather than feature work. That means upgrades are sometimes mandatory to keep existing apps running, and the README warns that even after updating, some apps may need their data and cache cleared or a reinstall, with a clean install as the fallback. Plan for a backup before every upgrade.

The last push to the repository was on 2026-09-15, and the most recent releases are dated 2026-09-04. The project is not archived. Whether it is actively developed is a separate question from whether it is being patched, and the README's own framing (fixes in progress, tracked in issue 700) is the better guide than any activity metric.

Editorial conclusion

Adopt WSABuilds if you specifically need the Microsoft WSA runtime rather than a third-party emulator, and you are willing to track GitHub issue 593 for the GApps crash on Windows 11 builds after June 2025. Do not adopt it if you need a supported product with a vendor behind it, or if a plain Android emulator would meet the requirement. Before installing, verify which archive you downloaded (GApps or NoGApps), confirm your Windows build, and check whether the issue thread still lists the crash as open.

Frequently asked questions

Official sources

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