I run Android apps on my Windows desktop the way I run any other productivity tool: pinned to the taskbar, windowed, and fully usable with mouse and keyboard — but I do it using community-maintained builds of the Windows Subsystem for Android (WSA) so I can access the Google Play ecosystem and choose the apps I need. This piece explains how that setup works, why people adopted it, how to install and manage it today, and what risks and alternatives to consider now that Microsoft has moved away from official WSA support. It draws on the original How-To Geek workflow and verifies the key technical claims against current vendor documentation and trusted community projects.
Background / Overview
Windows Subsystem for Android (WSA) was Microsoft’s solution to run Android apps seamlessly on Windows 11 by providing an AOSP-derived Android runtime in a lightweight Hyper‑V virtual machine. When WSA was delivered officially it relied on the Amazon Appstore rather than Google Play, which left a gap for users who wanted the full Play ecosystem. The subsystem behaved much like WSL: a compatibility layer that presents Android apps as first-class Windows windows and Start‑menu entries.
In early March 2024 Microsoft announced WSA and the Amazon Appstore on Windows would be deprecated and unavailable in the Microsoft Store after March 5, 2025. Microsoft’s support pages now explain that users who installed the Amazon Appstore or apps prior to March 5, 2024 would be able to use them through the March 5, 2025 deprecation date, after which official support and distribution would end. This deprecation is documented by Microsoft and has been widely reported across tech outlets. Why this matters: WSA made many mobile-first apps feel native on desktop — perfect for bank apps with limited web UIs, mobile-only games on a big display, or touch-optimized utilities on a Surface. The loss of official WSA removes that frictionless, integrated path for most users, which is why community projects and alternative approaches have become central to anyone who wants Android apps running on Windows after the deprecation.
What WSA delivered — and why people wanted it
- Seamless integration: Android apps appeared in Start, could be pinned to the taskbar, were windowed and resizable, and participated in Alt+Tab and Snap layouts — making them behave like native Windows apps.
- Multiple input modes: Apps accepted mouse, keyboard, pen, and touch input when available, improving tablet and convertible workflows.
- Low runtime overhead: Compared with full-phone emulators, WSA’s lightweight virtualization was faster to boot and simple to use for casual apps and many games.
These conveniences are exactly why enthusiasts looked for ways to restore Play Store access after Microsoft moved away from the official Amazon Appstore route.
The current landscape: official deprecation and community response
Microsoft’s deprecation notice is explicit: starting March 5, 2025, WSA and the Amazon Appstore will not be available on the Microsoft Store, and official support ends. Microsoft’s support documentation confirms the timeline and provides guidance for uninstalling the Amazon Appstore and WSA. With that official path retired, several communities stepped in to preserve functionality. Developers on GitHub repackage WSA system images and include Google Mobile Services (GMS) and Play Store installers — popular projects (for example, WSABuilds and similar repositories) publish prebuilt releases that bundle Play Store and variants of GApps like MindTheGapps. These community builds automate the registration and installation of the modified WSA package on Windows, and provide scripts such as Install.ps1 that will register the package with Windows. Important caution: community builds are unofficial. They can work well in practice but are time‑sensitive and may break with future Windows updates, and they exist in a gray area with respect to Google’s GMS licensing. Treat them as enthusiast tools, not enterprise-grade offerings.
How I set up WSA (community build) — verified, step‑by‑step
This section shows the practical flow used in the How‑To Geek post and validated by community docs. It assumes you understand the risks and have a fall‑back (image backup or system restore point).
Prerequisites and checks
- Hardware virtualization: Confirm virtualization is enabled in firmware (Intel VT‑x or AMD‑V). In Task Manager → Performance you should see “Virtualization: Enabled.” If it’s disabled, enable it in your BIOS/UEFI.
- Windows features: Enable the following: Virtual Machine Platform and Windows Hypervisor Platform (Turn Windows features on or off → check both → reboot). These are required for WSA’s lightweight VM.
- Administrator access: You will need to run PowerShell as Administrator to register custom WSA packages.
- Backup: Create a full system image or at minimum a restore point. Community builds can cause conflicts; a rollback path is essential.
Download a reputable build
- Use official GitHub release pages from established community projects (for example, WSABuilds). Look for a release labeled with a Play Store/GApps option — common build names include “MindTheGapps” and variants that say “Play Store included.” MustardChef’s WSABuilds is one widely used repository. Always download releases from the project’s official GitHub Releases page to minimize tampering.
Install the package
- Extract the downloaded archive to a folder (for example, C:\WSA-Play).
- Inside the extracted folder look for the installer script (usually Install.ps1). Right‑click and choose “Run with PowerShell” or open an elevated PowerShell and run: PowerShell.exe -ExecutionPolicy Bypass -File .\Install.ps1. The script will register the WSA package with Windows and configure the subsystem. If a GUI bootstrap is present, there may also be a Run.bat to launch WSA.
- Launch “Windows Subsystem for Android” from the Start menu (the custom build should appear after registration). On first launch you should see the WSA management window and a companion Android Settings window.
If the install fails, verify you ran PowerShell as Administrator and that Windows features and virtualization are properly enabled. Community builds sometimes require specific WSA base versions — a mismatch may need an alternate release (some users reported needing an older “build 2210” to get compatibility on certain machines; that’s an anecdote rather than a universal rule). Flag that as a troubleshooting note rather than a requirement.
Enable Developer Options and connect ADB (for sideloading)
To sideload APKs or debug, enable Developer mode inside the WSA settings:
- Open the WSA settings app and toggle Developer mode on. The client will display an ADB IPORT (often 127.0.0.1:58526 for local builds or a dynamically assigned IP).
- From your extracted Android SDK Platform Tools folder on Windows (or any folder with adb), run:
- adb devices (confirm adb is present)
- adb connect 127.0.0.1:58526 (replace with the IP shown in WSA)
- adb install path\to\myapp.apk
ADB will report the device and the success/failure of the install. If adb returns “connection refused,” toggle Developer mode off/on in WSA, click “Manage developer settings” to open Android settings, and refresh the IP — firewall/AV may also block ADB during connection attempts.
Using the Play Store inside community WSA builds
When a community build includes Google Play (GMS) and the Play Store variant (MindTheGapps is a common inclusion), the Play Store icon will appear in the WSA Apps list and the Start menu. Launch it, sign into your Google account, and install apps as you would on a phone. Expect occasional Play Services prompts and some apps that require Play Integrity or hardware attestation to refuse to run. Many common apps work fine; others may crash or misbehave depending on the GMS variant and the WSA base version.
Running and managing Android apps on Windows
Once installed:
- Apps show up in Start and can be pinned to Taskbar. They open in separate windows with their own icons. You can resize, snap, minimize, or close them like native apps.
- The WSA management UI exposes a System tab (with a file manager), an Apps tab (installed apps, Play Store), and Advanced settings (performance tweaks and Developer Options). Use it to manage permissions, storage, and developer toggles.
- When you want to remove an app, use the three‑dot menu in the WSA Apps view to open App Settings where you can uninstall, clear storage, or manage permissions.
This is precisely the “native-like” experience that made WSA attractive in the first place.
Troubleshooting: common issues and fixes
- WSA won’t start: Confirm virtualization is enabled, the Virtual Machine Platform & Windows Hypervisor Platform features are on, and you rebooted after enabling them. Try reinstalling the custom package using an administrative PowerShell.
- ADB connection refused: Toggle Developer mode in WSA, ensure the displayed IP is reachable, and temporarily disable firewall/ antivirus to test. Use the local loopback address if the build shows it (127.0.0.1) or the provided IPv4 address.
- Apps crash or fail Play Store checks: This is often due to mismatched GMS components or a Play Integrity check. Try a different build (maintainers publish variants), clear app data inside Android Settings, or sideload a previous APK version. Note that some apps simply refuse to run in virtualized environments.
Security, legal, and maintenance risks — a candid assessment
Using community WSA builds with Google Play restores convenience but increases risk in several concrete ways:
- Unsupported software stack: These builds are unofficial; Microsoft and Google do not support or maintain them. Future Windows updates can break community builds or change the WSA ABI so the build no longer runs. Users should expect manual maintenance.
- GMS licensing and legal gray areas: Google Mobile Services (GMS) components are proprietary; installing them in non‑GMS devices can violate Google’s licensing terms. Community projects navigate this gray area, but enterprises should avoid this path.
- Supply chain and integrity: You must download community artifacts from official GitHub releases and verify checksums where provided. Treat unknown downloads as high risk. Always scan APKs and installers before use.
- Privacy and telemetry: Custom builds often include Magisk, root tools, or additional plumbing that expands the attack surface. Avoid enabling root for banking or sensitive apps, and be cautious about what permissions you grant inside the Android environment.
- App compatibility: Some apps rely on hardware attestation or Play Integrity; they will refuse to run in emulators or patched WSA instances. Don’t assume every mobile app will work.
In short: community WSA restores features but at the cost of a long-term maintenance burden and real security considerations. Back up system images before experimenting and avoid running this on corporate machines unless expressly approved.
Safer and officially supported alternatives
If the risks above are unacceptable, consider these alternatives — each tradeoff is explicit:
- Phone Link (screen mirroring): Official Microsoft-supported path that mirrors your phone and allows app mirroring for supported OEMs. Apps run on the phone (better security) while Windows acts as input/display. It’s the least risky option if you have a compatible Android device.
- Emulators (BlueStacks, Nox, MEmu): Mature, actively maintained emulators that include Google Play and are designed for consumer use — simple to install and lower maintenance overhead than community WSA hacks, at the cost of less shell integration. BlueStacks remains the mainstream choice for most desktop users who need Play Store access.
- Android-x86 or BlissOS in a VM: Run a full Android OS in a traditional VM (VirtualBox, VMware). This gives a clean Android install and isolation at the expense of integration and convenience.
- Google Play Games (PC): For many games, Google and publishers are shipping PC versions through official channels; prefer those when available.
Choose the alternative that best balances integration needs, security posture, and maintenance appetite.
Practical checklist before you try a community WSA build
- Create a full disk image or system restore point.
- Use a dedicated Windows account (not your daily work account) for experimentation.
- Download community builds only from the project’s official GitHub Releases page and verify checksums if provided.
- Keep a second device (phone) available for 2FA and banking login fallback in case an app’s security checks fail in the emulated environment.
- Expect to troubleshoot after cumulative Windows updates; monitor the project’s GitHub or Discord for fixes.
Recommended approach — who should use which path
- For most users who value security and minimal fuss: use Phone Link or an official PC game client where available. These are the low‑risk, supported choices.
- For gamers and power users who need Play Store apps and accept maintenance: use a mature emulator (BlueStacks, Nox) or, if you specifically need WSA-style integration, try a community WSA build only after backing up your system.
- For developers and tinkerers who understand ADB, virtualization, and rooting implications: community WSA builds (WSABuilds, MindTheGapps variants) provide the tightest integration but require vigilance and frequent checks against Windows updates and upstream project releases.
Final analysis and conclusion
The How‑To Geek workflow — using community WSA builds to run Android apps as native-feeling Windows windows — describes a compelling and practical experience: apps run windowed, can be pinned to the taskbar, and accept keyboard and mouse, giving desktop users access to mobile-only utilities and games with minimal friction. The technical steps (enable virtualization, run Install.ps1, enable Developer Options, connect with ADB, sign into the Play Store) are reproducible and documented across community and support pages.
However, Microsoft’s official decision to deprecate WSA changes the calculus. The convenience of WSA is now balanced against the reality of an unofficial maintenance burden and legal gray areas around GMS. For those who depend on mobile apps for critical workflows — banking, authentication, or regulated data — the recommended, conservative path is to use Phone Link or approved emulators and avoid community hacks on corporate machines. For enthusiasts who accept the risks, community builds provide a path forward, but require backups, verification of downloads, and an acceptance that future Windows updates may force rebuilds or migrations. If your goal is occasional use — run a mobile‑only app on a big monitor once in a while — Phone Link or a mainstream emulator will usually do the job with far less risk. If you want the full Play Store integrated into Windows and are comfortable with advanced maintenance, test community WSA builds in a sandboxed environment, keep snapshots, and follow reputable GitHub projects for updates. The Windows‑Android experiment delivered a lot of value while it lasted. For enthusiasts who want that value back, the community has stepped up — but the tradeoffs are real, and users should proceed with eyes wide open.
Source: How-To Geek
How I run Android apps on Windows and why you would want to