Leaving .NET for Android

Historical migration inventory. It describes the Xamarin baseline before .NET for Android was removed on 2026-09-26. Present-tense statements below refer to that baseline; current status is in the overview and the roadmap.

Xamarin (.NET for Android) provided two different things: application capabilities and bootstrap infrastructure. Most of the bootstrap infrastructure should be deleted, not reimplemented. Only application capabilities observed in execution are candidates for replacement.

This inventory was taken from what runs today, working inward: the host that setup.ps1 emits (New-AndroidHostTypes and its phases), the six-opcode OnCreate shim, Profile.ps1, and CellCanvas as a workload. CellCanvas is evidence of required capabilities, not an architecture to reproduce.

Every proposed replacement below is a candidate. None has crossed the evidence boundary until its removal gate passes on hardware.

How the app starts today

mono.MonoRuntimeProvider (acquired classes.dex) → libmonodroid.so → coreclr_initialize with properties from libxamarin-app.so → assemblies from the XABA store → Java peer MainActivity (classes2.dex) → JNI-registered n_onCreate → Mono.Android Activity.OnCreate → the six-opcode shim → AdmitActivity → runspace → Profile.ps1.

Everything above AdmitActivity exists because Xamarin is the host.

Classifications

• KEEP: the capability stays and already has no Xamarin in it.
• REPLACE: the capability stays; the mechanism changes.
• MOVE TO SCRIPT: belongs in a script, not the host.
• RECOVERY-ONLY: needed only by the recovery screen.
• DELETE: exists only because Xamarin is the host.

Mechanisms: C API, JNI, owned emitted DEX forwarder, CoreCLR/runtime, PowerShell.

1. Admission and lifetime

2. Files and identity

3. Console surface (CellCanvas as evidence)

4. Recovery only

5. Deleted with Xamarin

What the admission boundary already provides

ANativeActivity_onCreate receives an ANativeActivity* that the framework has populated (lib/native_activity.h):

• JavaVM* vm (line 64): the Java VM for any later JNI work.
• JNIEnv* env (lines 67-71): usable only on the main thread. A PowerShell or console thread that needs JNI must attach through vm.
• internalDataPath (line 88): the candidate for HOME, without JNI.
• sdkVersion (line 98) and AAssetManager* assetManager (line 111).
• Callbacks (lines 123-124) run on the main thread and are all NULL until set, so an entry point that installs none is valid.

Gate 1 result

Passed on all three targets with -Admission NativeActivity: the framework android.app.NativeActivity loaded the emitted libpwsh-host.so and it logged GATE1 ANativeActivity_onCreate on the main thread (Samsung Galaxy S23 arm64, x86_64 emulator, arm32 device). The APK has four entries and no application DEX, no MonoRuntimeProvider, and no Xamarin libraries.

Gate 2a result

Passed on the x86_64 emulator and on an arm64 physical device (Samsung Galaxy S23) with -Admission NativeActivity: the emitted libpwsh-host.so started CoreCLR through its own host_runtime_contract, served System.Private.CoreLib.dll and Pwsh.dll from the mapped store through external_assembly_probe, and logged GATE2A Admit returned 0x50575348. The APK carries no DEX, libmonodroid or libxamarin-app. arm32, SMA and the full payload are the next gates.

Gates 2b and 2c result

Passed with -Admission NativeActivity on the x86_64 emulator, an arm64 physical device (Samsung Galaxy S23) and an arm32 device, whose host is Thumb-2. The owned host calls NativeHost.Admit, requires 0x50575348, then calls NativeHost.RunPowerShell, which opens a UseCurrentThread runspace with CreateDefault2, sets DefaultRunspace and runs 0x50575348. Two things stood in the way, and neither was Xamarin: the store placed images at unaligned offsets, which CoreCLR tolerates only because the .NET for Android host copies every assembly, and the NativeActivity APK lacked libpsl-native.so. The NativeActivity store now aligns every image to 16 bytes and the APK carries libpsl-native.so. Gate 2e, the Android compatibility surface, is next.

Gate 2d result

The profile execution substrate passed on all three backends with controlled fixtures: the product's case-insensitive lookup, $PSScriptRoot, execution as an external script in the existing runspace, the HadErrors rule, state kept afterward, and the missing-profile case. The Activity-dependent parts wait for gate 2e. CellCanvas is the workload in the Profile.ps1 role; its exact bytes run at gate 2f.

Open questions

1. Who owns assembly resolution at CoreCLR startup, and which runtime properties and callbacks are required? Answered for gate 2a on x86_64 and arm64: the owned contract with external_assembly_probe over the existing store and the three properties the pinned host sets (HOST_RUNTIME_CONTRACT, RUNTIME_IDENTIFIER, APP_CONTEXT_BASE_DIRECTORY) suffice; the rest of this item is the background. Extraction to disk is not forced: the pinned host contract (lib/host_runtime_contract.h, v11.0.0-rc.1.26425.128) has external_assembly_probe, which returns a pointer and size for an assembly from memory the host owns. Candidate shapes:

   • loose assemblies listed in TRUSTED_PLATFORM_ASSEMBLIES;
   • a hybrid of files on disk and a store;
   • an owned HOST_RUNTIME_CONTRACT whose external_assembly_probe serves assemblies from the existing XABA store, mapped by dlopen of libassembly-store.so and _assembly_store.

   The third keeps the store proven on three architectures and deletes libmonodroid and libxamarin-app. Rule it out before accepting the first-run writes and duplicate storage that extraction costs. The current .NET for Android CoreCLR host is the oracle for the minimal property set. This decides milestone gate 2.

2. libSystem.Security.Cryptography.Native.Android.so and the Java VM. A dlopen from CoreCLR does not run JNI_OnLoad; the host may have to pass activity->vm explicitly before hashing or TLS work.

3. The emitted host .so is real code. It builds argument arrays and calls coreclr_initialize; its structure needs a design before the encoders grow.

4. Glyph rasterization. JNI to Paint once at startup, or an owned rasterizer.

5. Get-ChildItem and Get-Process. Unrelated to Xamarin: they need Microsoft.PowerShell.Commands.Management, and Microsoft.PowerShell.Commands.Utility for formatting. A payload decision.

First executable gates

Milestone 1 is split so that a failure points at one layer:

1. NativeActivity → emitted host .so → liblog. Proves admission without Xamarin or any DEX.
2. NativeActivity → emitted host .so → CoreCLR → the smallest managed entry. Proves runtime ownership. Needs open question 1 decided first.

Gate 1 is deliberately minimal: android:hasCode="false", the framework android.app.NativeActivity, android.app.lib_name naming the host library, an exported ANativeActivity_onCreate that makes one __android_log_write call through DT_NEEDED liblog.so and returns. It passes only if the APK also proves absence: no .dex entries, no MonoRuntimeProvider, no libmonodroid.so or libxamarin-app.so. It is a separate build mode; the Xamarin build stays the oracle until gate 1 holds on all three targets.