Amazon Appstore and WSA heads off into the sunset

Microsoft's decision to sunset Windows Subsystem for Android (WSA) and, with it, the Amazon Appstore on Windows 11, is now fully in the rear-view mirror. Support ended on March 5, 2025, and as of 2026 the dust has well and truly settled. What remains is a clear-eyed post-mortem on one of the more ambitious — and ultimately ill-fated — cross-platform experiments in recent Windows history, and a practical guide to where Windows users who want Android apps should turn today.

In this article we examine the background to that decision, the reasons it was always likely to happen, what it meant for users and developers at the time, and — crucially — what the realistic options look like now that the project is definitively gone.

TL;DR: Microsoft threw in the towel. If you want seamless Android on a computing device, a Chromebook or an Android tablet remains the cleanest path. If you are a developer who needs to test Android apps on a desktop, Android Studio's built-in emulator — regularly updated by Google and now running Android 15 — is the right tool.

Why the sunset of Windows Subsystem for Android was always coming

Microsoft's decision to end WSA surprised some commentators, but the warning signs had been accumulating for well over a year before the announcement. The project had its public preview in February 2022, followed by a series of roughly bimonthly releases through to June 2023 — and then nothing. No release for the remainder of Microsoft's financial year. In any large technology organisation, a project that goes quiet across an entire fiscal year is rarely being quietly perfected; it is being quietly wound down.

There is also a historical precedent that should have given anyone watching pause. BlackBerry integrated Android APIs and delivered the Amazon Appstore inside BlackBerry 10 as a late-stage attempt to rescue a dying platform. The parallels are uncomfortable: a proprietary platform, a third-party app store standing in for Google Play, and a fundamental unwillingness — or inability — to licence the Google services that make Android apps actually work for mainstream users. BlackBerry World failed. The Amazon Appstore on BlackBerry 10 failed. The entire BlackBerry OS failed. WSA followed a structurally identical path on a much larger platform.

The sheer scale of engineering effort involved in keeping WSA current was also unsustainable without a clear commercial return. The January 2023 release note "Windows Subsystem for Android updated to Android 13" sounds innocuous, but migrating an entire virtualised Android stack to a new major OS version — with all the build, integration, and hardware compatibility testing that entails — is a significant undertaking. Doing that work indefinitely for a product with limited adoption and no viable path to Google Play is a hard case to make in any budget cycle.

What was the Windows Subsystem for Android?

What it was and how it worked

Windows Subsystem for Android, introduced in 2022, was Microsoft's attempt to bridge the Windows and Android ecosystems. At its core it was a virtual machine running the Android Open Source Project (AOSP), packaged for the Microsoft Store and front-ended with the Amazon Appstore as the mechanism for installing apps. It was not an emulator in the traditional sense — it ran Android natively inside a Hyper-V container — but it was also not a full Android environment in any way a mainstream user would recognise.

The development drew on the success of Windows Subsystem for Linux, which had proven that running a foreign OS environment inside Windows could be genuinely useful. WSA aimed for a similar outcome with Android. The competitive pressure was real: Apple Silicon Macs had been running iOS and iPadOS apps natively from the App Store since late 2020, and Chromebooks had offered seamless Google Play integration for years. Microsoft's mobile app story on Windows had been weak since the collapse of Windows Phone, and WSA was the attempt to address that gap.

What it could and could not do

At the point of the end-of-life announcement, WSA had reached Android 13 and supported a reasonable range of hardware features. Camera, microphone, Wi-Fi, location, multitouch, multi-monitor output, picture-in-picture, and Widevine L3 DRM were all functional. However, Bluetooth, USB, Android widgets, hardware DRM, quick tiles, and seamless file transfer were either absent or incomplete. The roadmap items — file transfer, shortcuts, local network access by default — were never delivered.

More importantly, none of that feature work addressed the fundamental problem: without Google Play Services, the majority of Android apps that mainstream users actually want either would not install, would not function correctly, or would lack push notifications entirely. The feature table on the GitHub repository was impressive in places, but it was a table of work done on the wrong problem.

The Google Play problem — the real reason WSA failed

Every post-mortem of WSA eventually arrives at the same place: Google Play and Google Play Services. Android may be open source through AOSP, but Google licences Play Services and the Play Store under strict criteria that require device manufacturers to pre-install a defined suite of Google applications. This is a deliberate and effective control point over the Android ecosystem, and it is one that Microsoft was never going to satisfy on its own platform.

The BlackBerry comparison is instructive here. BlackBerry's management reportedly could not accept the requirement to ship Gmail, Google Maps, Google Calendar, and the full suite of Google applications pre-installed on their devices as a condition of Play Services licencing. Without that agreement, BlackBerry could not offer a credible Android experience. Microsoft faced an identical structural problem — and the idea of Google effectively mandating which applications ship on Windows devices was never a negotiation that was going to conclude happily for either party.

This was confirmed shortly after the end-of-life announcement by what appeared to be a Microsoft product manager on 𝕏, and subsequently reported by 9to5Google. The absence of Google Play Services was not a technical oversight or a future roadmap item — it was a commercial and political dead end that had been apparent from the beginning.

Amazon's Fire OS is the only meaningful example of an AOSP-derived platform succeeding without Google Play, and that success is built on a very specific foundation: cheap, subsidised tablets sold primarily as consumption devices for Amazon's own content ecosystem — Prime Video, Kindle, Amazon Music. There was never a realistic version of that dynamic applying to Windows 11 desktops and laptops. The Amazon Appstore on WSA had no equivalent gravitational pull.

Sideloading apps via Android Debug Bridge (ADB) was technically possible but was aimed squarely at developers and hobbyists. It was never going to drive mainstream adoption, and Microsoft treated it as such — barely acknowledged in official documentation and unsupported in any practical sense for ordinary users.

Where things stand in 2026

With WSA gone and the March 2025 support deadline now passed, the question for anyone who was using it — or who is arriving at this article wondering what their options are — is what actually works today.

The honest answer is that nothing on Windows has filled the gap WSA left, because the gap WSA left was never as large as the project's ambition suggested. The users who genuinely needed to run Android apps on Windows were always a relatively small population, and most of them have migrated to one of three paths.

For end users who want Android apps as part of their daily computing life, a Chromebook remains the most coherent answer. Google Play integration on ChromeOS is mature, well-maintained, and covers the overwhelming majority of Android apps. Chromebook hardware in 2026 spans a wide range of price points and form factors, and the platform has continued to receive investment from Google in ways that WSA never received from Microsoft. For users who are already in the Android ecosystem — with a Pixel phone or a Samsung Galaxy device — the continuity between phone and Chromebook is natural.

For developers, Android Studio from Google is the current standard. The built-in emulator now runs Android 15, is regularly updated alongside new Android releases, and supports the full range of Google Play Services in a way that WSA never could. It runs on Windows, macOS, and Linux. It is not a consumer product, but developers who were using WSA for testing were already operating in developer territory — Android Studio is simply the correct tool for that job, and it has been for years.

There is also a renewed conversation in 2026 around whether Microsoft will make another attempt at Android integration, particularly given the continued growth of ARM-based Windows devices and the Surface Pro line. The architectural alignment between modern Windows on ARM and Android on ARM makes the technical case more interesting than it was in 2022. But any future attempt would face the same fundamental commercial obstacle: Google Play Services licencing. Until that negotiation changes — and there is no current indication that it will — any WSA successor would be building on the same broken foundation.

Impact on users and developers

Users

The population of users who relied on WSA was always limited by the Amazon Appstore's catalogue. Without Google Play Services, apps requiring push notifications, Google Maps integration, Google Sign-In, or Firebase-based features either failed silently or required significant workarounds. The apps that worked well on WSA tended to be games and simple utilities — a narrow slice of what most people actually use Android for.

Those users have now had well over a year since the March 2025 deadline to find alternatives. For most, the transition was not as painful as the headlines at the time suggested, precisely because the dependency was shallower than it appeared.

Developers

Developers who invested in WSA-specific compatibility work should have deprecated that code well before the March 2025 deadline — and most sensible teams did. Any code paths added specifically to handle the WSA environment, or to work around the absence of Google Play Services in that context, are now dead weight. The distribution channel no longer exists.

The broader lesson for developers is one that was already well understood but bears repeating: building for a platform whose commercial viability depends on a licencing agreement between two large companies that have competing interests is a significant risk. The Amazon Appstore on Windows was always contingent on a set of relationships that were never stable.

Industry response and what it revealed

The tech press response to the WSA shutdown was consistent: near-universal identification of Google Play Services as the core problem, with secondary commentary on Microsoft's pattern of launching and then abandoning platform experiments. That pattern — from Windows Phone to Cortana to Mixer to WSA — is a recurring theme in how Microsoft's ambitions in consumer and platform spaces tend to resolve.

Apple and Google were not materially affected. Apple Silicon Macs continue to run iOS and iPadOS apps from the App Store with no friction. ChromeOS continues to offer Google Play. Neither platform had to do anything differently as a result of WSA's closure — they were already further ahead than WSA ever managed to get.

What the episode did usefully illustrate is the degree to which Google's control over the Android ecosystem extends beyond the open-source layer. AOSP is genuinely open. But AOSP without Play Services is, for most users and most apps, not Android in any meaningful sense. That distinction matters for anyone evaluating Android-adjacent platforms — whether that is a future Microsoft product, a new Chinese device manufacturer, or an open-source Android fork.

Conclusion

Microsoft's Windows Subsystem for Android was a technically ambitious project that ran into a commercially immovable obstacle. The engineering work was real and in places impressive — running Android 13 inside a Windows virtual machine with camera, GPS, multitouch, and DRM support is not trivial. But the project was solving the wrong problem. The question was never whether Android could run on Windows. The question was whether the apps people actually use — the ones built on Google Play Services — could run on Windows without Google's participation. They could not, and Google was not going to participate on terms acceptable to Microsoft.

The cautionary note here is not unique to Microsoft. Large technology companies regularly invest in platform experiments that are structurally dependent on cooperation from a competitor who has no incentive to cooperate. The business case for WSA presumably rested on revenue from the Amazon Appstore, but that revenue potential was always capped by the Appstore's catalogue, which was always capped by the absence of Google Play Services. The ceiling was visible from the beginning.

Stopping a project that has no viable path forward is the right call, even when the sunk cost is significant. What is harder to defend is starting a project of this scale without resolving the central commercial dependency first. That is the real lesson of WSA — and it applies well beyond this particular episode.