メインコンテンツまでスキップ

Reviving Astoria - Windows's lost Android

· 約13分
阮誠忠 (げんまさただ)
ソフトウェアメーカー

Are you a die-hard fan of Project Astoria, Microsoft's former solution to bridging the app gap on Windows 10 Mobile? Or are you just tired of your average sluggish, resource-hogging Android emulator?

This post, exploring the method to bring Astoria to various unsupported Windows versions, from different platforms like Desktop to higher builds like the Anniversary Update (RS1) and beyond, is just for you.

Android from a lost window

Generated by Microsoft Copilot.

Introduction

Project Astoria, (a.k.a Windows Bridge for Android), was an attempt to allow Android apps to run on early prerelease builds of Windows 10 Mobile. It was available exclusively to Mobile builds and canceled before the public release of Windows version 1511 ("Thresold 2").

The solution features an Android 4.4 environment running on a compatibility layer (lxcore.sys) that translates Linux syscalls issued by the Android runtime to equivalent Windows NT calls. With the help of more glue services, Astoria allowed many Android applications to run alongside with native Windows apps and seamlessly integrate into the environment with little performance penalty, unlike existing solutions which spawns a full virtual machine.

While only released for mobile, the design of Astoria theoretically also supports other variants of Windows 10. After its demise, the project had a second life as the Windows Subsystem for Linux, created to run console Linux applications, before being abandoned in favor of a brute-force Hyper-V solution in 2020.

Prerequisites

  • General Windows power user techniques (e.g. modifying the registry and system files).
  • Using Project Astoria to install APKs on supported Windows 10 Mobile versions. A general guide can be found here.

Preparing

Being a complex component, Astoria involves multiple files and expects the system to have certain features and configurations available.

Overview of Components of Project Astoria.

Overview of Components of Project Astoria.

Windows 10 Version

This guide is tested on Windows 10 x86 build 10563.

32-bit Windows 10 variants up to build 10572 should work.

Some features may work on early Redstone 1 preview 32-bit builds (builds 14251 - 14346).

Full access to the filesystem and registry is expected. This is generally true for Administrators on normal Windows, but may require additional setup on Windows 10 Mobile.

Why?

As shown on the diagram above, the core driver of Astoria requires a specific kernel function, PsRegisterPicoProvider.

Windows TH2 builds starting from 10575 are known to block this function entirely, returning an error code in all cases. This function got unblocked in the RS1 branch to pave the way for WSL, but experienced an ABI break starting from build 14347, preventing Astoria drivers to load on newer versions of Windows.

Since Windows 10 Mobile is 32-bit only (arm32 for native devices and x86 for emulators), and Astoria is only published for Windows 10 Mobile, the component is exclusive to 32-bit Windows editions.

While early RS1 builds possess the necessary kernel facilities, breaking changes have been made to userland services handling AppX packages and UWP apps, preventing the deployment of Astoria- based AppX files. For Mobile variants, the latest known fully functional build is 14320, while on Desktop, none of the RS1 builds can deploy Astoria packages correctly, despite having correctly launched the Android container.

Overcoming the Time Bomb

All of the listed supported builds are Windows Insider Preview builds with a fixed expiration date long long ago.

Before installing or booting, make sure your hardware clock is set to some time in 2015 and any time synchronization mechanism is disabled. Otherwise, installation will fail and/or Windows will refuse to boot (hence, the "Time Bomb").

If you are using VMWare, adding these lines to your .vmx configuration might help:

rtc.startTime = "1450962000"
tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
time.synchronize.tools.enable = "FALSE"
time.synchronize.resume.host = "FALSE"

Files

The following files should be extracted from a Windows 10 Mobile image with a close build number. Files for late TH2 builds (builds 105xx) should work for supported RS1 installations (builds 14xxx).

The guide includes files and registry values extracted from Windows 10 Mobile Emulator Build 10563. Registry keys and deployment tools can be shared across architectures, but drivers, core AoW files, and security catalogs must match the architecture of your target system.

You can download all the files used in this guide in this big zip file.

Core Drivers (C:\Windows\System32\drivers)

Two files are required: adss.sys and lxcore.sys.

What are they?

These are the core drivers responsible for translating Linux system calls to Windows NT equivalents. They are the lowest level components of Astoria.

AoW Files (C:\Windows\System32\aow)

The whole aow directory is required.

What are they?

The folder name, aow - Android on Windows - should be self-explanatory.

It contains a full Android image (aow.wim), Windows services used to start and communicate with the Android container, and some other libraries used by Astoria components.

Registry Keys

Several registry keys need to be imported.

Registry entries should be the same for both ARM32 and x86 versions of Windows.

Drivers

Apply adss.reg to register the core Astoria drivers.

Keys involved
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\adss]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ManufacturingMode\Default\Services\adss]

The first key is essential for all Windows driver registrations.
The second key does not appear to be important but is present in W10M builds with Astoria.

Services

Apply AoWSM.reg to register the AoW Session Manager service. This is the main userland component of Astoria.

Keys involved
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AoWSM]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AoWSM\parameters]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AoWSM\Security]

Also, run AoWSM.cmd as Administrator to add the service to the correct service user.

Keys involved
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost]
Why a script?

The installation process involves updating a REG_MULTI_SZ value by appending the service name (AoWSM) to an existing list. The list of services may be different in each build and each Windows installation.

Windows .reg files only support replacing whole values, not appending a new entry to a REG_MULTI_SZ. Therefore, commands are used to read the whole list, add the required value, and write the list back again.

SET ContentsToBeAppended=\0AoWSM
FOR /F "tokens=2,3*" %%G IN ('REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v netsvcs') DO SET EntryContents=%%H
SET NewEntryContents=%EntryContents%%ContentsToBeAppended%

REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v netsvcs /t REG_MULTI_SZ /d "%NewEntryContents%" /f
Certificates

Apply MicrosoftTestRootAuthority.reg to register the Microsoft Test Root Authority. This is the authority for certificates found in Astoria and other test components in Win10M preview builds.

Keys involved
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\2BD63D28D7BCD0E251195AEB519243C13142EBC3]
Policies

Apply AllowWindowsBridgeForAndroidAppExecution.reg to enable a hidden policy allowing AoW apps to run. Without this policy set to enabled, Astoria services simply refuse to start.

Keys involved
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\ApplicationManagement\AllowWindowsBridgeForAndroidAppExecution]
AoW Configuration

Apply AoWCOM.reg to register necessary COM interfaces used by Astoria.

Keys involved
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppId\{86a8127c-3121-4879-bef7-08df0ed05a76}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppId\{a4557610-bef7-40d6-844d-83dc4e1ea6f2}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{4abf46cc-e506-434c-afa4-9927f3668e60}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{4abf46cc-e506-434c-afa4-9927f3668e60}\InProcServer32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7930ac88-f36c-44fd-8202-8b95b5b06acb}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7930ac88-f36c-44fd-8202-8b95b5b06acb}\InProcServer32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{86a8127c-3121-4879-bef7-08df0ed05a76}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{86a8127c-3121-4879-bef7-08df0ed05a76}\LocalServer32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{910065f3-db2c-41c8-a50a-aa258afac2e8}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{da3739a3-46a5-4e9b-b2b5-9545eeea93e6}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{da3739a3-46a5-4e9b-b2b5-9545eeea93e6}\InProcServer32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{e213b5d9-4ee5-4e2d-945e-6508c1d050fb}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{e213b5d9-4ee5-4e2d-945e-6508c1d050fb}\InProcServer32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{292997c8-fa0d-4fb6-8bc5-366f9382cc81}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{292997c8-fa0d-4fb6-8bc5-366f9382cc81}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{355C3D14-8434-4F35-8377-FDD880F5758A}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{355C3D14-8434-4F35-8377-FDD880F5758A}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{38530252-eb81-4164-8854-89e763e44514}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{38530252-eb81-4164-8854-89e763e44514}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{623bbb59-1aa9-46b2-a2e6-e4a749305fcd}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{623bbb59-1aa9-46b2-a2e6-e4a749305fcd}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{75888062-7a77-46c0-9494-e59f2dd4df0f}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{75888062-7a77-46c0-9494-e59f2dd4df0f}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{782b2d14-179c-4540-bfc8-3599213f764e}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{782b2d14-179c-4540-bfc8-3599213f764e}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{8ab860cb-32ff-4903-8f2a-5ca76ed80301}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{8ab860cb-32ff-4903-8f2a-5ca76ed80301}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{a0c5d6c2-48ce-4429-a73c-5c4df8cc2a54}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{a0c5d6c2-48ce-4429-a73c-5c4df8cc2a54}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{a1411706-05ec-4f1a-914a-31f7e8b12a9e}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{a1411706-05ec-4f1a-914a-31f7e8b12a9e}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{b65c0692-57f8-472d-b3e4-cd754ccdcc6a}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{b65c0692-57f8-472d-b3e4-cd754ccdcc6a}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{c60b7e58-8fe7-4a9c-a86e-42ca6926cc40}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{c60b7e58-8fe7-4a9c-a86e-42ca6926cc40}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{e6521960-71d3-4e9f-8ecd-bb87a99313f9}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{e6521960-71d3-4e9f-8ecd-bb87a99313f9}\ProxyStubClsid32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\FullTrust]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\FullTrust\AowHost]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AOW]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AOW\Instance]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsRuntime\AllowedCOMCLSIDs\{da3739a3-46a5-4e9b-b2b5-9545eeea93e6}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsRuntime\AllowedCOMCLSIDs\{e213b5d9-4ee5-4e2d-945e-6508c1d050fb}]
Host Configuration

Apply ArcadiaEvents.reg to allow certain features of Arcadia, the UWP application host component of Astoria, to run correctly.

Keys involved
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BackgroundModel\EventSettings\719]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BackgroundModel\EventSettings\720]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BackgroundModel\EventSettings\721]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BackgroundModel\EventSettings\722]

Certificates

Two catalog files should be copied to C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}, the system security catalog store:

Microsoft.MS_PROJECTA.MainOS

Microsoft.MobileCore.Prod.MainOS

What are they?

On Windows, security catalogs (files with .cat extension) provide signatures to files that are otherwise not signed.

Microsoft.MS_PROJECTA.MainOS covers items deployed with Project Astoria (most, but not all, of the aow folder), and Microsoft.MobileCore.Prod.MainOS covers the rest.

Missing these catalogs prevents Windows from verifying the signature of some service binaries, resulting in a 0x80070241 - Windows cannot verify the digital signature... error.

For more information on Windows security catalogs, check out this video.

Tools

A patched version of WConnectAgent needs to be run on the machine with Project Astoria.

The other machine should have a copy of ADB. The official copy included with the Android SDK should suffice.

What does it do?

The normal procedure of deploying APKs to Windows 10 Mobile involves a tool called wconnect.exe pairing to the mobile device through Device Discovery. This tool would communicate with its counterpart on the mobile, which emulates the ADB protocol and allows APK deployment.

Since Device Discovery does not work on early Windows 10 Desktop builds, wconnect.exe cannot be used to establish a connection. Instead, the guide uses WConnectAgent, a tool bundled with the wconnect suite, to start an ADB protocol server directly on the target machine.

What are the patches?

Without patches, WConnectAgent would fail to start on many devices with this error:

80070542 Either a required impersonation level was not provided, or the provided impersonation level is invalid.

Turns out, to work around this error, a call to CoInitializeSecurity needs to be issued before creating any COM objects, similar to how CLI projects dealing with WSL function.

The patch adds this line at the start of Program.Main:

NativeMethods.CoInitializeSecurity(
IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero,
NativeMethods.RPC_C_AUTHN_LEVEL.DEFAULT,
NativeMethods.RPC_C_IMP_LEVEL.IMPERSONATE,
IntPtr.Zero,
NativeMethods.EOAC_STATIC_CLOAKING,
IntPtr.Zero
);

Installing Astoria

Copying Files

Start off by copying all the files mentioned above to your target Windows device.

Files belonging to C:\Windows\System32 should be put to the same path as where they were extracted from.

Registry keys and the WConnectAgent tool can be put anywhere.

Importing Registry Keys

Click on each of the files in the Keys section to import the key.

The .cmd script should be run as Administrator.

Verifying

After copying all the files and importing all the required keys, restart your device.

Then, launch a Command Prompt window as Administrator, then run this command:

sc query adss

If you get this response, the core Astoria drivers have been set up correctly and are running.

SERVICE_NAME: adss
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

To ensure that the Astoria userland services are running, run:

sc query AoWSM

Since AoWSM only starts on demand, you might get an error status of 1077:

SERVICE_NAME: AoWSM
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

In that case, just start the service manually by running:

sc start AoWSM

Run the query command again. You should get this response, indicating that the services and Android container are up and running on your target machine:

SERVICE_NAME: AoWSM
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_PRESHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

Android Apps

With Astoria up, let's install some Android apps!

Preparing the environment

Enabling Developer Mode

Go to the Windows Settings app and enable Developer Mode on your device to be able to sideload applications.

Searching for the keyword Developer should guide you to the correct page in most versions of Windows.

Adding Environment Variables

On your target device, in an Administrator Command Prompt window, run:

setx /M ARCADIA_APPX_PACKAGE_TYPE tablet
What does this do?

This environment variable instructs the bridge (WConnectAgent) to convert APK files into tablet (a.k.a. universal) AppX files instead of mobile-specific ones.

Without this set, WConnectAgent in the following steps will fail, unless you are following this guide on a Win10M installation.

Bridging to Android

On your target device, start WConnectAgent by opening a Command Prompt window at the tool's folder and running:

WConnectAgent -v -bindAll
What do these parameters mean?

-v: Put WConnectAgent in verbose mode. This allows us to collect diagnostic messages should the app deployment fail.

-bindAll: Listen to requests from external network devices as well. This switch is important for the reasons explained later.

You should get the following screen:

WConnectAgent running

indicating that an ADB proxy server has started on port 50505.

Deploying APKs

On a different device connected to the same local network, run:

adb connect [YOUR_TARGET_DEVICE_IP]:50505
Why do I need a different device?

If you try to use adb directly on the target machine, adb connect would simply bypass the proxy by WConnectAgent and connect directly to the adbd in the Android container listening at port 5555 (the default ADB port).

APK installation will succeed, but the Windows environment will have no idea that the package has been added. There will not be a corresponding UWP package for the app, and there will be no way to access this app from the Start Menu.

You should get this prompt, confirming that your device is connected:

connected to [YOUR_TARGET_DEVICE_IP]:50505

With the connection up, you can deploy your APK using:

adb install [PATH_TO_YOUR_APK]

If the procedure succeeds, you should see the app appearing in your Start Menu. Launch it like any normal UWP application.

Deploy Success

Behold, Android CPU-Z 1.07 running on Windows 10!

CPU-Z 1.07

What's Next

While Project Astoria now works, it is only available on very old beta builds. In the near future, some work will be done in lxmonika to handle different versions of the PsRegisterPicoProvider function, allowing it to act as a shim between the core Windows kernel and Project Astoria drivers. This may bring Astoria to the lastest Windows 10 Mobile build, or even Windows 10 22H2 x86.

In the long run, to gain access to more modern Android apps, and to support 64-bit OSes, lxmonika aims to port a full Linux kernel without yielding to the WSL2 VM-based architecture, allowing Linux-based Android solutions like Anbox to run natively on Windows. This solution would involve replacing the entire Astoria stack with open-source and easy-to-maintain components while still upholding the project's original spirit.

Having been abandoned by Microsoft, the future of Astoria relies on lxmonika, so don't forget to give this repo a visit, and, if possible, a star! ✨

Acknowledgements

A huge thanks to @empyreal96 and my other friends on the Windows Phone Community Telegram for providing me with invaluable resources and feedback during my journey digging ancient beta Windows builds!

This blog post marks the 5-year anniversary of the @trungnt2910 GitHub account. I would like to thank my 93+ followers for giving me 200+ stars and supporting my first steps on the journey of learning and contributing to open source! 🚀

I hope you enjoy this blog, and stay tuned for more updates from Project Reality! 👀