Reviving Astoria - Windows's lost Android
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.
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.
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.