# wsa-app-compatibility: a community table of what runs under Windows Subsystem for Android

> This repository is a single Markdown page that records how individual Android apps behave inside the Windows Subsystem for Android, with a four-level support legend, an OS feature table and workarounds for two common problems. It is useful as a reference before you sideload an app, and it is not a tool, a test suite, or a source of anything other than community observations.

**riverar/wsa-app-compatibility** — Keeping track of Android apps and their compatibility with the Windows Subsystem for Android

- Repository: https://github.com/riverar/wsa-app-compatibility
- Stars: 559 · Forks: 214
- Language: Unknown
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/riverar-wsa-app-compatibility

## One Markdown file, no code

The repository has a single top level entry, `README.md`, and nothing else. There is no source directory, no build configuration, no package manifest, and the project description is the whole pitch: keeping track of Android apps and their compatibility with the Windows Subsystem for Android.

That makes the review of this project mostly a review of a data format, which is unusual but not a problem. What you are adopting is a convention: a table with a fixed set of columns, a fixed legend, and a stated contribution process, maintained by whoever has the device to test on.

The language is recorded as unknown and the licence is not stated either, so there is no licence file to consult and no declared terms. If you plan to reuse the table in your own documentation, that is a question to settle with the repository owner rather than a detail you can read off the page.

There are no GitHub releases, and the last push was on 2026-07-26. So this is a living document with a maintenance history, not a published dataset with a version you can pin your tooling to.

## The four-level legend and why the middle grades exist

The page uses a legend of four support levels, each marked with a Unicode character, and the distinctions between them are the actual contribution to compatibility knowledge.

The first level is works, which means the app runs as expected. The second is works, but needs Google Mobile Services, which is the interesting one: the app depends on the Google services framework that the Windows Subsystem for Android does not ship by default, so a community member may have installed a workaround to test it. The third is works, but with some notable problems, which covers apps that launch and are usable but misbehave in a way the row explains. The fourth is broken.

That the Google Mobile Services level is a separate grade rather than a note is a good design decision. The distinction between an app that fails because of a missing framework and an app that fails because of a genuine bug matters to anyone planning to run it, and the same applies to the problems grade, which is where the table records the failures that would otherwise be invisible.

The page notes that the legend uses characters from Unicode Emoji 1.0 and invites readers to open an issue if they cannot see them. A practical side effect is that the table renders badly in some terminals and in any toolchain that strips emoji, so a script consuming this data has to match on text, not on the glyph.

## What the OS feature table says about WSA itself

Before the per-app tables, the page carries a second table covering operating system features rather than applications, with columns for the feature, its support level and notes. This is arguably the more durable half of the page, because an OS capability does not change as often as an app release does.

The entries are specific and include the reason for each verdict. Multi-touch is marked as working, with a demo linked. Virtual Wifi is marked as working. Bluetooth is marked as broken, citing a GitHub issue and noting that it failed while pairing a smartwatch through the FitCloudPro app. IPv6 is marked as working, with a note that loading an IPv6 host in Fennec F-Droid on a PC with IPv6 access works well.

The fingerprint reader is marked as broken, with the note that the test failed on an ROG Flow X13 using the SATRIA app, which is careful attribution: it names the hardware, the app and the result rather than making a general claim. VPN is given a split verdict, since the VPN connection request dialog does not appear, but some VPNs may not need it, and Tunnelbear is named as an example. OpenGL ES 3.1 is marked as broken, and Vulkan is marked as working, with a note that it was added as an experimental feature in build 2307.40000.2.0.

That last point is the pattern to watch. The verdicts are tied to specific WSA builds, so a row that was true for one build can be stale for another, and the page does not record a per-row build number.

## Two workarounds you can act on immediately

The page documents workarounds for two problems, and both are concrete enough to use without further research.

The first is VPN activation. The page states that there is no `com.android.vpndialogs` component in WSA, and that the VPN activation permission can be granted manually with AppOps through `adb shell`:

```shell
appops set [package name] ACTIVATE_VPN allow
```

The second is launching an app directly by package name, using the custom URI scheme Microsoft provides for WSA:

```shell
wsa://[App Package Name]
```

The page then gives a concrete example of that scheme used to launch Apple Music:

```shell
wsa://com.apple.android.music
```

These are the two pieces of the page that will save you time. The first turns a missing dialog into a one-line command you can script. The second removes the need to hunt through the WSA app list, which matters when you are setting up a device with a dozen sideloaded apps.

One caveat on the first workaround: it requires adb access to the WSA instance, and granting a permission by hand is exactly the kind of change that a future WSA update could invalidate. The AdGuard row in the app table is a case in point, since it notes that local VPN does not work even with the workaround applied, and that HTTPS filtering fails because manually installed certificates are not properly recognised.

## Reading a row: version, Android, symptom

The app tables have a fixed shape with six columns: the application, the latest tested version, the Android versions tested against, the support level, known issues and notes. Games have their own table alongside the apps one.

The content in a typical row is much more informative than the verdict. Aurora Store is listed at 4.7.5 across Android 13, 12 and 11, with a note that opening the spoof manager sometimes crashes the app, and that it supports the advanced install types such as rooted installs with Magisk or KernelSU or installs via Shizuku.

Activity Launcher carries a version-specific failure: as of WSA version 2209.40000.28.0 you cannot pin shortcuts to a home area of a launcher such as Lawnchair or Rootless Pixel Launcher, and the error text is quoted verbatim. The Known Issues column names WSA and the release it was tested against, and the Notes column covers the rest.

Bouncer is simply marked as working with some notable problems and no explanation, which is the weakest kind of entry. Apple Music is the opposite case, with a long procedure for reaching Hi-Res Lossless audio that involves changing the WSA sound settings before starting the subsystem.

The columns are useful, but the table is unordered, it is not filtered by anything a script could rely on, and the level column mixes application behaviour with system integration, so it cannot be treated as data without a good deal of cleaning.

## The contribution rules are the maintenance policy

The page documents how to contribute in three rules, and they are worth reading because they explain what kind of data the table holds.

Contributions are made by editing the page and submitting a pull request, and a reviewer merges changes. That is a low barrier and it means the table grows by whatever someone bothered to test.

The first rule forbids linking to any APKs, which is a sensible constraint that keeps the repository free of application binaries and keeps it safe to mirror. The second asks contributors to double-check spelling and grammar, and the third is the one with real consequences: in the Android column, list the latest version of Android first, and separate subsequent versions with a comma, for example `11`, `12, 11`, or `13, 12, 11`.

That ordering convention is what makes the column readable at a glance, since the newest Android version is the one that matters for a current device, and the older ones tell you whether the app is likely to run on an older device you own.

The project also states plainly what it is not. It says that support cannot be offered for the Windows Subsystem for Android or for Android apps, and points readers to the WSA subreddit instead. This is a good sign of scope discipline, and it also means a broken row is a report from one person on one device rather than a verified verdict, so anyone acting on it should reproduce the symptom first.

## Conclusion

This page earns a place in the notes of anyone sideloading Android apps on a Windows 11 machine, because it records per-app failures with the specific symptom, such as a VPN dialog that never appears or an installer that needs several attempts, rather than a bare works or does not work verdict. It does not serve a team that needs a tested compatibility matrix for a product decision, since there is no code to run, no releases, and no stated licence. Before you rely on a row, check the tested Android version against the version your device will receive, treat the broken entries as reports rather than confirmed failures, and plan on the adb AppOps workaround for VPN apps rather than expecting a native settings toggle.

## FAQ

### What does the wsa-app-compatibility repository contain?

It contains a single `README.md` page that records how Android apps behave under the Windows Subsystem for Android. The page has a four-level support legend, a table of operating system features, a table of applications and a table of games, plus workarounds for VPN activation and app launching.

### How do I grant VPN permission to an app under WSA?

The page states that there is no `com.android.vpndialogs` in WSA, and that the VPN activation permission can be granted manually with AppOps through `adb shell` using `appops set [package name] ACTIVATE_VPN allow`. The AdGuard row notes that local VPN still does not work with this workaround.

### How do I launch an Android app directly in Windows Subsystem for Android?

Microsoft provides a custom URI scheme for WSA, given in the project page as `wsa://[App Package Name]`. The page shows `wsa://com.apple.android.music` as the example for launching Apple Music.

### What do the support levels in the wsa-app-compatibility table mean?

The legend defines four levels: works, works but needs Google Mobile Services, works but with some notable problems, and broken. The Google Mobile Services level is kept separate because the app depends on a framework that the subsystem does not ship by default.

### How do I contribute a compatibility result to wsa-app-compatibility?

You edit the page and submit a pull request, and a reviewer merges it. The contribution rules say not to link to any APKs, to double-check spelling and grammar, and to list the latest version of Android first in the Android column with subsequent versions separated by commas.

## Sources

- [Issues](https://github.com/riverar/wsa-app-compatibility/issues)
- [README](https://github.com/riverar/wsa-app-compatibility/blob/master/README.md)
- [riverar/wsa-app-compatibility on GitHub](https://github.com/riverar/wsa-app-compatibility)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/riverar-wsa-app-compatibility