Windows Subsystem for Android™️

Article
05/29/2024

Windows Subsystem for Android™️ enables your Windows 11 device to run Android applications that are available in the Amazon Appstore. Android is a trademark of Google LLC. If you're a developer interested in targeting Windows desktop devices and optimizing for the Windows operating system, this guide is for you.

Important

Microsoft is ending support for the Windows Subsystem for Android™️ (WSA). As a result, the Amazon Appstore on Windows and all applications and games dependent on WSA will no longer be supported beginning March 5, 2025. Until then, technical support will remain available to customers.
Customers that have installed the Amazon Appstore or Android apps prior to March 5, 2024, will continue to have access to those apps through the deprecation date of March 5, 2025. Please reach out to our support team for further questions at support.microsoft.com. We are grateful for the support of our developer community and remain committed to listening to feedback as we evolve experiences.

To make your Android app available on Windows 11 devices, you must:

Submit your app to the Amazon Appstore.

For more information or support:

Sign up for updates to the Amazon Appstore on Windows program.
Visit the Amazon developer support portal where you can find articles, forums, FAQs, or reach out for direct support via the Appstore "Contact us" page once you set up an Amazon Developer account.

This guide can help you test and debug your Android app on Windows:

Set up your development environment, including prerequisites, installing the Amazon Appstore, and using the Settings.
Test and debug your app on a Windows 11 device.
Handle input compatibility considerations for Windows devices, such as: keyboard input, mouse input, and window management and resizing.
Troubleshoot and find answers.

Developer GitHub

Want to learn more about Windows Subsystem for Android™️ roadmap, discuss developer issues and file bugs or feature requests with the subsystem team? Visit the Windows Subsystem for Android™️ Developers GitHub.

Preview Program

The Windows Subsystem for Android™️ Preview Program is no longer available.

Set up your development environment

To test your Android app in the Windows desktop environment, a bit of set up will be required.

Prerequisites

Windows Subsystem for Android™️ is available on Windows 11. Your device must meet specific requirements: Device requirements.

Install the Amazon Appstore

The Microsoft Store will automatically install Windows Subsystem for Android™️ silently in the background when either of the two following user actions are taken:

Install the Amazon Appstore from the Microsoft Store. Selecting Get will begin the installation of the app.
Install an Android app from the Microsoft Store for the first time, which will also install the Amazon Appstore.

The Amazon Appstore app will then appear in the Windows 11 Start menu and be available on search, offering a catalogue of Android apps. The Windows Subsystem for Android™️ app, which lets you control mobile app settings and features, will also appear in the Start menu.

Screenshot of Microsoft Store page featuring the Get button on the Amazon App Store

Note

The Amazon Appstore on Windows (a requirement for running Android apps on Windows 11) is available in select regions.

Windows Subsystem for Android™️ Settings

To modify Windows Subsystem for Android™️ settings, go to: Start > All Apps > Windows Subsystem for Android™️. Learn more about specific settings app features: Manage settings for mobile apps on Windows.

Screenshot of Latte app settings

Test and debug

To test and debug your app on a Windows 11 device using the Windows Subsystem for Android™️ the following set up steps are required.

Enable developer mode in Windows Settings

You must first enable developer mode. Open the Windows Subsystem for Android™️ settings. Once open, enable Developer mode under Advanced settings.

Connect to the Windows Subsystem for Android™️ for debugging

To connect to the Windows Subsystem for Android™️ VM for debugging:

Launch an Android app that was installed using the Amazon Appstore.
You can connect using adb connect with the following command (you must have adb installed):
```
adb connect 127.0.0.1:58526
```

Connect to a test device

To connect to a test device (with Windows Subsystem for Android™️ installed) on the same network from Windows/Mac:

On the test device (where Windows Subsystem for Android™️ is installed) open a PowerShell window and identify the IP address of the test device by running the command:
```
ipconfig
```
Using the debugging device terminal where Android Studio and the Android SDK is installed (Mac/Windows), enter the command:
```
adb connect <TEST DEVICE IP ADDRESS>:58526
```

The <TEST DEVICE IP ADDRESS> can be found in the output of "ipconfig" from the test device. You can also deploy and debug apps from Android Studio.

To use Android Debug Bridge (ADB) to connect your development workstation directly to your Android device so you can install packages and evaluate changes, see Android Debug Bridge in the Android Open Source Project docs.

Debug your app

While apps should be installed using the Amazon Appstore, debugging an Android app on a Windows device is possible using an APK (Android application package) and adb (Android Debug Bridge).

To debug an APK using adb:

Follow the steps to connect to the Windows Subsystem for Android™️ VM above.
Install the APK using the adb install command: adb install app-debug.apk

Expected Output:
```
Performing Streamed Install
Success
```
A successful "app installed" notification will appear in the Windows notification menu and the app will launch once selected.

Building Universal APKs

Windows Subsystem for Android™️ utilizes Intel Bridge Technology to enable Arm applications on x86 based processors. Arm applications will run on Arm-based processors natively. The emulation layer will induce a performance overhead – for optimal performance, submit your application for both the x86-64 and Arm64 architectures.

Input compatibility considerations for Windows devices

There are a few unique input behaviors to consider that will likely require updates to your Android app code, designed for handheld devices, to be compatible when running on a Windows desktop device via the Amazon Appstore.

Keyboard input

For text input fields handled by an on-screen virtual keyboard input method (or IME), such as EditText, apps should behave as expected. (EditText class in the Android docs).

For keystrokes that cannot be anticipated by the framework, apps will need to handle the behavior themselves. If this is already implemented in-app, no extra work is required.

As an example, some games may already support movement facilitated via keyboard, through w a s d keys, alongside touch input.

The following are keyboard inputs that developers should consider code updates for when building for Windows 11 devices:

Enter Key
Arrow-key and Tab-key Navigation
Change Selected Item Highlight Color
Ctrl-based Shortcuts

Learn more about how to optimize for these keyboard input scenarios on desktop devices by following the Android documentation:

Mouse input

Developers should consider updating code for the following mouse inputs when building for Windows devices:

Right Click
Tooltips / Hover Text
Hover Effects
Mouse Scroll Wheel Action
Drag and Drop

Mouse input, similar to keyboard input, must follow the official Android app guidelines. This means using the InputDevice class paired with the SOURCE_MOUSE constant. Learn more about how to optimize for these mouse input scenarios on desktop devices by following the Android documentation:

Window management and resizing

Unlike traditional mobile form factors, Android apps running on Windows 11 can be freely resized, should be responsive in their resizing, and can be snapped using Windows actions/gestures.

Minimum screen requirement

Windows 11 enforces a minimum screen requirement of 720p resolution (1280x720) with a >9" screen.

Letter & pillar boxing

When the aspect ratio of a window size does not align between the device screen sizes that window is being displayed on, the result may be Letterboxing (the window is wider than it is high, or horizontally longer) or Pillarboxing (the window is more narrow than it is wide, or vertically longer). The result is bars being placed on the sides of the window in order to center it. These bars may be light- or dark-themed depending on the system settings selected. This will only occur as necessary when the Android app is snapped or maximized, allowing Android apps to take advantage of the rich snapping features in Windows and integrate into the windowing model.

Letterboxing and Pillarboxing example showing blank bars that center the window

Additional resizing considerations

The following should also be considered when updating an Android app to run on a Windows 11 device with respect to window management and resizing:

Initial launch size
Window dimensions
- Content bounds
- Free form resizing
Screen Orientation

Learn more about how to optimize for window resizing scenarios on desktop devices by following the Window Management guide in the Android docs.

Application Lifecycle Events

Developing Android applications for a multi-window environment has an impact on the lifecycle events that you choose to utilize in your application. While overriding the onPause event may achieve the results you'd like on a phone or tablet, it's typically the wrong event to use if you're changing your app's UX.

See the Android documentation for a description of the lifecycle events. More often than not, you'll want to use the onStop event and not the onPause or onUserLeaveHint events. In fact, many multi-window Android implementations do not deliver the onUserLeaveHint notification, and thus any business critical logic that might be in that event handler will not be called on these platforms, including Windows Subsystem for Android™️.

VM lifecycle considerations

Windows Subsystem for Android™️ utilizes a virtual machine (VM) which provides compatibility with the AOSP framework and devices like keyboards, mice, touch, pen, etc.

There are three possible states for the VM running apps with Windows Subsystem for Android™️:

Running
Lightweight Doze: Activated after no app activity for 3 minutes. Deactivated by user activity or an app notification.
Not Running: Activated after no app activity for 7 minutes.

Transitions between these states are triggered by user activity, such as launching or interaction with the Android app or an app notification. Android apps are paused and then stopped when their window is minimized.

VM lifecycle graph showing the running, lightweight doze, and not running

VM Properties

The properties for the Windows Subsystem for Android™️ VM are listed below. Hardcoding these values is not recommended as that could cause future incompatibilities.

Property	Value
Build.MANUFACTURER	Microsoft Corporation
Build.MODEL	Subsystem for Android(TM)
Build.VERSION.SDK_INT	33
Build.BOARD	windows

Redirect to Windows apps

Windows Subsystem for Android™️ automatically redirects intents for files and common URI schemes to the corresponding Windows default file/protocol handler (if multiple intent filters match, users see a "Windows default app" option in the chooser dialog). Supported file intents include ACTION_VIEW, ACTION_EDIT, ACTION_SEND, and ACTION_SEND_MULTIPLE, which copy the file to the Windows Downloads folder before opening it. Supported URI intents include ACTION_VIEW for the http/https schemes and ACTION_VIEW and ACTION_SENDTO for the mailto scheme.

Android apps can also manually redirect to Windows apps using custom URI schemes. Set the intent action to com.microsoft.windows.LAUNCH_URI and add a string extra to the intent named com.microsoft.windows.EXTRA_URI with the custom URI as the value. For example, to launch the Windows Calculator app from an Android app (Java):

Intent intent = new Intent("com.microsoft.windows.LAUNCH_URI");
intent.putExtra("com.microsoft.windows.EXTRA_URI", "ms-calculator:");
 
try {
    startActivity(intent);
} catch (ActivityNotFoundException e) {
    // Not running in Windows Subsystem for Android&trade;️ (or running on an older build that did not contain this feature).
}

Security

Both Windows kernel-mode drivers and Windows applications running at medium integrity level (IL) can inspect arbitrary Android containers and Android app memory. There are no plans to add detection for cheats/macro/bot/suspicious behaviors detection in the short-term.

Developers querying getSecurityLevel will get SECURITY_LEVEL_SW_SECURE_CRYPTO. Learn more about getSecurityLevel in the Android API Reference guide.

Uninstalling Windows Subsystem for Android™️

You can uninstall the Windows Subsystem for Android™️, but note that all associated apps will also be uninstalled.

Uninstalling the Amazon Appstore will uninstall the Windows Subsystem for Android™️ and all other Android apps.
Uninstalling an Amazon Appstore app will only uninstall the app (same behavior as Windows apps).
Uninstalling the Windows Subsystem for Android™️ will uninstall the Amazon Appstore and all Android apps.

Troubleshooting issues

If you encounter issues specific to the Amazon Appstore on Windows, try the following troubleshooting steps:

Select Windows search from the Windows task bar.
Search for "Amazon Appstore" and right-click on the Amazon Appstore icon.
Select "App Settings" in the dropdown options.
Select "Storage and Cache" and click both "Clear Storage" and "Clear cache".
Go back and select "Force Stop".
Close the Amazon Appstore Settings window.
Relaunch the Amazon Appstore.

For further troubleshooting steps relating to the Windows Subsystem for Android™️ Settings app or to leave feedback using Feedback Hub, see Troubleshooting and FAQ for mobile apps on Windows.

For any other developer questions and support, use the Windows Subsystem for Android™️ tag on Microsoft Q&A.

Share via