Microsoft Cancels Project Astoria, Its Android-on-Windows Bridge

In February 2016, Microsoft officially confirmed the cancellation of Project Astoria, the “Windows Bridge for Android” initiative that would have let developers port Android applications to Windows 10 Mobile with minimal code changes.

What Project Astoria actually was

Announced at Build 2015, Astoria let Android apps run on Windows 10 Mobile through an emulation-based compatibility layer — one of four parallel “Universal Windows Platform Bridge” efforts Microsoft announced together that year: Astoria for Android, Islandwood for iOS, Centennial for classic Win32/.NET desktop applications, and Westminster for packaging ordinary websites as Store apps.

Why Microsoft chose to cancel it specifically

Microsoft’s own stated reasoning was one of focus: “We received a lot of feedback that having two Bridge technologies to bring code from mobile operating systems to Windows was unnecessary, and the choice between them could be confusing.” The company chose to consolidate around the iOS-focused bridge (Project Islandwood) as its single mobile-porting strategy going forward, rather than maintain both approaches in parallel.

What happened around the same time, contextually

Microsoft’s acquisition of Xamarin closed around this same period, eventually contributing to what became .NET MAUI — a cross-platform framework covering iOS, Android, and Windows through a different technical approach than either original bridge project had taken.

Why this cancellation is relevant to WSL’s own history

Astoria’s abandonment freed up organizational focus and engineering attention that, within roughly two months, contributed to a different compatibility direction entirely — Windows Subsystem for Linux’s own first public reveal came just weeks after Astoria’s cancellation was confirmed, redirecting Microsoft’s “run foreign code on Windows” ambitions from Android apps specifically toward Linux command-line tooling instead.

What Astoria’s technical approach actually looked like

Astoria worked by providing Windows 10 Mobile with compatibility shims mimicking enough of the Android runtime environment (Dalvik/ART-adjacent behavior, common Android APIs) that unmodified or lightly-modified APK packages could run without a full source recompile — a fundamentally different technical approach from what WSL would later take, since WSL never attempted to run unmodified binaries built for a different OS’s runtime, instead running genuine Linux binaries against a real or emulated Linux kernel interface.

The competitive context driving both bridge projects

Both Astoria and its sibling iOS-focused Project Islandwood existed to solve the same underlying problem for Windows 10 Mobile specifically: a chronic shortage of native mobile applications compared to iOS and Android, which had already established dominant app ecosystems by the time Windows 10 Mobile launched. Rather than convincing developers to build native Windows Mobile apps from scratch, both bridges aimed to let existing iOS and Android codebases reach Windows with minimal additional work — a pragmatic, if ultimately insufficient, response to that competitive gap.

Why the bridge strategy didn’t ultimately save Windows Mobile

Even with both bridges available (and Astoria’s eventual cancellation narrowing focus to just the iOS bridge), Windows 10 Mobile’s market position continued to decline in the years following, and Microsoft eventually wound down active Windows Mobile development entirely. The bridge strategy addressed an app-availability symptom without changing the more fundamental market dynamics working against the platform, a pattern worth noting given how much organizational effort both bridge projects had consumed.

Why Astoria specifically was the one that got cut

Of the four bridges, only Astoria required emulating a genuinely foreign OS’s runtime environment — Centennial repackaged existing Win32 installers into a container without touching the underlying binaries, and Westminster simply wrapped web content, while Islandwood at least worked from portable Objective-C source rather than pre-compiled Android bytecode. Astoria’s Dalvik/ART-compatibility layer was the most technically involved of the four to build and maintain long-term, which lines up with Microsoft’s own stated reasoning that supporting two overlapping mobile-porting technologies was the harder one to justify keeping.

Related:

Sources: