Windows Subsystem for Android: What's the point?
Project Astoria – which evolved into Windows Subsystem for Linux – returns with its original intent
Hands on Microsoft has previewed the Subsystem for Android on Windows 11, and The Register took it for a spin.
Android apps for Windows 11 was made available by Microsoft earlier this month via its Windows Insider programme, seemingly making it as hard as possible for users to get it working. The official route is a matter of first being in the US, then having the latest beta (not the more bleeding-edge "dev channel") of Windows 11, and then meeting requirements for processor, memory and storage type (SSD only).
The Amazon Appstore app is the official route for acquiring and installing applications, and it only fully installs for those who have a US Amazon account. An annoying limitation for users is that the Amazon Appstore – primarily aimed at users of Amazon Fire tablets – is nothing like the equal of Google's official Play Store, although it does boast 460,000 apps (the Play Store has around 2.7 million according to AppBrain).
Microsoft must have its reasons, but it appears that many of these restrictions are artificial and can be bypassed with careful use of PowerShell commands like Add-AppxPackage, along with the ability to sideload Android applications using the adb (Android Debug Bridge) tool. Sideloading the Amazon Appstore app itself gives access to the full range of apps.
Aidan Marcuss (corporate veep of Windows) and Giorgio Sardo (GM of the Microsoft Store) said that Windows Subsystem for Android (WSA) is about "living our commitment to openness," enabling Windows users to run apps "regardless of the technology used".
Android apps run on a Hyper-V virtual machine on both Intel and Arm processor types, and Arm-only apps are supported via Intel Bridge technology, described as a "runtime post compiler".
Details are sketchy but it is a software solution that works on AMD as well as Intel processors. Microsoft notes in the official documentation that "the emulation layer will induce a performance overhead – for optimal performance please submit your application for the x86-64 architecture."
Once installed, WSA offers a remarkably smooth experience. Each Android app runs in its own window, multiple apps can be open at once, and they appear in the Start menu and can be pinned to the taskbar, in the same way as Windows apps. Android apps can be resized like Windows applications, though this only works for apps that support it and some will snap back to a smartphone-like shape. Sound works, so does touch control, keyboard and mouse.
Perhaps oddly, the app called Windows Subsystem for Android does not run WSA directly but is a settings application. Opening this and clicking Files runs the actual WSA and gives access to user folders in its file system as you would expect.
Users can also enable developer mode and see the IP number and port for use by adb. Once enabled, there is also access to developer settings, including USB debugging which is on by default. And there is an option for "Continuous" – which runs WSA in the background all the time, as opposed to the default "As needed".
One key aspect of WSA is support for developers testing and debugging Android applications. We installed Android Studio on the PC with WSA and created a project. Next, it is a matter of opening a command prompt and running adb to connect to WSA. Finally, it is back to Android Studio and Run – Debug. Our first attempt failed because we had not agreed the license terms for the Android SDK command-line tools. The solution is to install these tools from the Android Studio SDK manager, which pops up the license agreement. Once done, we were able to run and debug the application running on WSA.
It is a smoother experience than using the Android emulator, though it lacks the normal facilities for things like emulating location or setting device size. It will also not be suitable if the application needs access to Google Play Services. This is great though for getting started with an Android application, with further testing on actual devices or with the emulator at a later stage – or indeed for developing specifically for WSA, in order to reuse Android code for Windows.
Windows developers may remember Project Astoria – one of two Microsoft efforts to boost development for Windows Phone and Windows 10. Project Islandwood let developers port iOS Apps to Windows, while Project Astoria was for running Android apps. Part of Project Astoria was an Android subsystem for Windows Phone, which appeared in some preview releases. Project Astoria was put on indefinite hold back in 2015, but the technology later resurfaced as Windows Subsystem for Linux, which has proved to be among the best features of Windows 10. How much of Project Astoria remains in WSA is open to speculation, but its appearance now feels like the completion of a circle.
Other than letting Android developers on Windows avoid the emulator, what is the point of WSA? Our brief hands-on suggests that Android apps run well enough that it is a good solution for running apps that are otherwise unavailable.
Users who love casual games may be delighted, as the Amazon Appstore seems to be stuffed full of them – but is there anything else? It may turn out that the developer appeal is its most significant advantage. WSL has already improved Windows for web and Linux developers; now WSA promises to improve it for Android as well. ®