[TrimmableTypeMap][NativeAOT] Initialize trimmable typemap runtime

[simonrozsival]

Summary

Fix NativeAOT startup with the trimmable typemap implementation enabled, and make the generated trimmable typemap usable for NativeAOT without rooting the full Mono.Android framework ACW closure.

Key changes:

• Initialize generated trimmable typemap data before creating the NativeAOT Java.Interop runtime.
• Register trimmable typemap native methods after JniRuntime.Current is available.
• Add generated typemap assemblies to ILC inputs before ILC input computation and emit --typemap-entry-assembly for the root typemap assembly.
• Keep generated framework typemap assemblies as ILC references, but do not export them as unmanaged-entrypoint assemblies.
• Populate NativeAOT JnienvInitializeArgs with GC-user-peer class refs and GREF threshold so managed runtime state matches the Mono/CoreCLR init path.
• Add an explicit RuntimeFeature.IsNativeAotRuntime switch for NativeAOT-specific runtime identity.
• Mark framework assemblies during scanning and treat framework ACW implementors as conditional trim-target entries instead of unconditional user ACW roots.
• Keep array-rank anchors internal to generated typemap assemblies and emit framework array typemap entries only for framework types referenced by app/library assemblies, so NativeAOT supports explicit framework array shapes without rooting every framework array shape.

Fixes #11052.

Current state

The repo HelloWorld sample builds, installs, and launches with NativeAOT + trimmable typemap enabled after merging latest main.

Current clean android-arm64 Release output after mirroring legacy framework JCW generation:

Type map	signed APK	signed AAB	libHelloWorld.DotNet.so
trimmable	3,638,382 bytes	1,569,830 bytes	3,513,624 bytes
managed (legacy NativeAOT typemap)	5,129,326 bytes	2,132,927 bytes	5,069,400 bytes

The ILC response now uses the normal root typemap assembly, keeps framework typemap assemblies as references, and only exports the app/library typemap assemblies plus Microsoft.Android.Runtime.NativeAOT:

--typemap-entry-assembly:_Microsoft.Android.TypeMaps
--runtimeknob:System.Runtime.InteropServices.TypeMappingEntryAssembly=_Microsoft.Android.TypeMaps
-r:obj/Release/net11.0-android/android-arm64/typemap/_Mono.Android.TypeMap.dll
--generateunmanagedentrypoints:System.Private.CoreLib,HIDDEN
--generateunmanagedentrypoints:_HelloLibrary.DotNet.TypeMap
--generateunmanagedentrypoints:_HelloWorld.DotNet.TypeMap
--generateunmanagedentrypoints:Microsoft.Android.Runtime.NativeAOT

The trimmable NativeAOT output remains smaller than the legacy managed-typemap NativeAOT output after framework JCW generation was broadened to mirror the legacy path.

Latest smoke launch on emulator-5554 was successful:

Status: ok
LaunchState: COLD
TotalTime: 471
WaitTime: 473

No fatal exception/native crash lines were found in logcat for that launch.

Validation

make prepare CONFIGURATION=Debug V=0
make all CONFIGURATION=Debug V=0

MSBUILDDISABLENODEREUSE=1 ./dotnet-local.sh build \
  src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.csproj \
  -c Debug -nr:false --nologo

MSBUILDDISABLENODEREUSE=1 ./dotnet-local.sh build \
  samples/HelloWorld/HelloWorld/HelloWorld.DotNet.csproj \
  -c Release \
  -p:PublishAot=true \
  -p:_AndroidTypeMapImplementation=trimmable \
  -p:RuntimeIdentifier=android-arm64 \
  -p:AndroidPackageFormat=apk \
  -nr:false --nologo

MSBUILDDISABLENODEREUSE=1 ./dotnet-local.sh build \
  samples/HelloWorld/HelloWorld/HelloWorld.DotNet.csproj \
  -c Release \
  -p:PublishAot=true \
  -p:_AndroidTypeMapImplementation=trimmable \
  -p:RuntimeIdentifier=android-arm64 \
  -p:AndroidPackageFormat=aab \
  -nr:false --nologo

Results:

• make prepare passed.
• make all passed.
• Xamarin.Android.Build.Tasks.csproj build passed.
• Microsoft.Android.Sdk.TrimmableTypeMap.Tests.csproj passed: 493/493 tests.
• clean HelloWorld NativeAOT trimmable APK and AAB builds passed.
• clean HelloWorld NativeAOT managed/legacy APK and AAB builds passed for comparison.
• HelloWorld installed, launched, and handled a button tap successfully on emulator-5554.

[Copilot]

Pull request overview

This PR wires the trimmable typemap path into NativeAOT startup and build-time ILC inputs so NativeAOT apps can initialize the managed/runtime typemap state before Java interop begins.

Changes:

• Adds NativeAOT-specific build plumbing for trimmable typemap assemblies and runtime feature switches.
• Updates NativeAOT host/runtime initialization so typemap data is initialized earlier and native registration happens after JniRuntime.Current is available.
• Aligns NativeAOT runtime state with the Mono/CoreCLR init path for GREF/GC-user-peer setup and runtime identification.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.TypeMap.Trimmable.NativeAOT.targets	Adds typemap assemblies to NativeAOT ILC inputs and sets the typemap entry assembly.
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk.NativeAOT.targets	Adds a NativeAOT runtime feature switch to host configuration.
src/native/nativeaot/host/host.cc	Populates NativeAOT init args with GREF threshold and GC-user-peer class refs.
src/Mono.Android/Microsoft.Android.Runtime/RuntimeFeature.cs	Introduces IsNativeAotRuntime runtime identity switch.
src/Mono.Android/Android.Runtime/JNIEnvInit.cs	Splits NativeAOT typemap initialization/registration into explicit helper steps and applies more init state from args.
src/Mono.Android/Android.Runtime/JNIEnv.cs	Treats NativeAOT like CoreCLR for uncaught exception propagation.
src/Mono.Android/Android.Runtime/AndroidRuntimeInternal.cs	Treats NativeAOT like CoreCLR for unhandled-exception callback selection.
src/Microsoft.Android.Runtime.NativeAOT/Android.Runtime.NativeAOT/JavaInteropRuntime.cs	Reorders NativeAOT startup to initialize typemap data before runtime creation and register natives afterward.

[simonrozsival]

Additional NativeAOT testing update:

• Made ForceUnconditionalEntries configurable and disabled it for NativeAOT trimmable typemap builds only.
• Rebuilt HelloWorld as single-RID android-arm64 across the measured configs using -p:RuntimeIdentifier=android-arm64.

Arm64-only local Debug-pack measurements:

Variant	APK size	TotalTime avg / median	Runs
Mono	8.47 MiB	242.8 / 210 ms	414, 211, 198, 210, 181
CoreCLR llvm-ir typemap	14.64 MiB	259.6 / 235 ms	381, 210, 235, 218, 254
CoreCLR trimmable typemap	24.70 MiB	290.0 / 264 ms	404, 304, 229, 249, 264
NativeAOT original managed typemap	4.86 MiB	169.8 / 163 ms	230, 165, 152, 139, 163
NativeAOT trimmable typemap, ForceUnconditionalEntries=false	11.84 MiB	186.6 / 170 ms	262, 164, 171, 170, 166

No fatal/crash logcat hits were found for these runs. The NativeAOT trimmable APK contains only lib/arm64-v8a/libHelloWorld.DotNet.so after switching to RuntimeIdentifier=android-arm64.

[simonrozsival]

Follow-up on blanket rooting for NativeAOT trimmable typemap:

• The current NativeAOT trimmable ILC response has no --root: entries and no root descriptors.
• I found one real blanket root item: we were passing every generated typemap assembly to UnmanagedEntryPointsAssembly, which emitted:
  • _HelloLibrary.DotNet.TypeMap
  • _HelloWorld.DotNet.TypeMap
  • _Java.Interop.TypeMap
  • _Microsoft.Android.TypeMaps
  • _Mono.Android.TypeMap
• I narrowed this so only app/library typemap assemblies are exported for JNI UCO wrappers. Framework/root typemap assemblies stay as IlcReference inputs, but are no longer unmanaged-entrypoint roots.

Validated NativeAOT trimmable arm64 after the change:

--scanreflection
--generateunmanagedentrypoints:System.Private.CoreLib,HIDDEN
--generateunmanagedentrypoints:_HelloLibrary.DotNet.TypeMap
--generateunmanagedentrypoints:_HelloWorld.DotNet.TypeMap
--generateunmanagedentrypoints:Microsoft.Android.Runtime.NativeAOT

Result:

APK: 13,124,718 bytes / 12.52 MiB
libHelloWorld.DotNet.so: 13,000,904 bytes / 12.40 MiB
TotalTime runs: 266, 166, 165, 168, 169 ms
TotalTime avg/median: 186.8 / 168.0 ms
No fatal/crash logcat hits

I also tried disabling IlcScanReflection for this path. That produced much smaller APKs, but it is not currently runnable:

• without scanreflection: APK 3.22 MiB, crash in TypeMapLazyDictionary.CreateExternalTypeMap(RuntimeType) for Java.Lang.Object
• with narrow rd.xml / dynamic dependencies: APK ~4.0-4.3 MiB, same crash
• with IlcGenerateCompleteTypeMetadata=true: APK 13.76 MiB, same crash

So --scanreflection appears to be required today for ILC to emit the NativeAOT type-map blob consumed by TypeMapLazyDictionary, even though --typemap-entry-assembly:_Microsoft.Android.TypeMaps is present. I did not commit the broken no-scan experiment.

[simonrozsival]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

✅ LGTM — Well-structured NativeAOT trimmable typemap initialization

Summary: This PR cleanly separates NativeAOT runtime initialization from MonoVM/CoreCLR, introduces framework assembly awareness to the typemap scanner/generator, and correctly scopes ILC inputs to avoid rooting the full framework ACW closure. The size improvements are significant (~30% smaller APK for the HelloWorld sample).

Highlights:

• Good refactoring of JNIEnvInit — InitializeCommonState eliminates duplicated field assignments across init paths
• CreateTypeManager/CreateValueManager factory methods are now shared between NativeAOT and MonoVM/CoreCLR
• The framework array entry filtering (MarkFrameworkArrayEntryPeers) is a smart approach — only generating array entries for types actually referenced by app assemblies
• _ReadGeneratedTrimmableTypeMapAssemblies target with the list file is a clean solution for passing typemap assembly lists across target boundaries
• Good test coverage: unit tests for framework ACW conditional entries, array entry skipping, scanner framework marking, and integration tests for ILC response file validation

Issues found: 0 ❌, 1 ⚠️, 5 💡

Severity	Category	File
⚠️	MSBuild targets	Microsoft.Android.Sdk.TypeMap.Trimmable.NativeAOT.targets — framework ILC assembly items may reference non-existent files
💡	Documentation	JNIEnvInit.cs:91 — stale comment referencing removed method
💡	Patterns	JavaPeerInfo.cs — mutable set property on otherwise-immutable record
💡	Code organization	JNIEnvInit.cs:111-115 — redundant runtime guard
💡	Code duplication	AndroidRuntimeInternal.cs / JNIEnv.cs — identical NativeAOT and CoreCLR branches
💡	Positive	Clean validation logic and non-required array property conventions

CI: All public checks pass (license/cla ✅, dotnet-android ✅).

Generated by Android PR Reviewer for issue #11292 · ● 42.6M

Comments that could not be inline-anchored

src/Mono.Android/Android.Runtime/JNIEnvInit.cs:114

🤖 💡 Code organization — The check on line 111 (!IsNativeAotRuntime) already guarantees that NativeAOT is not active. The second guard on lines 113-115 (IsMonoRuntime || IsCoreClrRuntime) is therefore redundant unless you want to also reject a scenario where none of the three runtime flags are set. If that's the intent, a comment would help clarify.

Rule: Comments explain "why", not "what"

src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/JavaPeerInfo.cs:54

🤖 💡 Patterns — GenerateArrayEntries uses { get; set; } on a sealed record, making it the only mutable property. This is intentionally mutated by MarkFrameworkArrayEntryPeers after construction, but it breaks the otherwise-immutable contract of the record. Worth adding a brief comment explaining why mutability is needed here, or alternatively, consider returning a new collection from MarkFrameworkArrayEntryPeers using with { GenerateArrayEntries = ... } and changing this to `in…

src/Mono.Android/Android.Runtime/JNIEnvInit.cs:91

🤖 💡 Documentation — Stale comment references InitializeJniRuntime, which was renamed to InitializeNativeAotRuntime in this PR. Consider updating to match the new method name.

Rule: Remove stale comments (Postmortem #59)

src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.TypeMap.Trimmable.NativeAOT.targets:28

🤖 ⚠️ MSBuild targets — _TrimmableTypeMapFrameworkIlcAssemblies constructs paths like $(_TypeMapOutputDirectory)_%(Filename).TypeMap.dll based on ResolvedFrameworkAssemblies, PrivateSdkAssemblies, and ReferencePath. If a framework assembly listed here doesn't produce a corresponding typemap DLL (e.g., it has no Java peers), the item will reference a non-existent file. Is ILC tolerant of non-existent -r: references, or should these items be filtered with `Condition=" Exists('%(Id…

src/Xamarin.Android.Build.Tasks/Tasks/GenerateTrimmableTypeMap.cs:93

🤖 💡 MSBuild tasks — ResolvedFrameworkAssemblies is not marked [Required] (correct), but it's initialized to [] which means it's non-nullable. Good — this is consistent with the convention for non-required array properties.

Rule: Positive callout

src/Mono.Android/Android.Runtime/AndroidRuntimeInternal.cs:22

🤖 💡 Code organization — The NativeAOT branch here is identical to the CoreCLR branch (CoreClrUnhandledException). Similarly in JNIEnv.cs line 140. If these runtimes will always share the same handler, consider combining them: RuntimeFeature.IsCoreClrRuntime || RuntimeFeature.IsNativeAotRuntime. This would reduce duplication and make it clear they intentionally share behavior.

Rule: Code duplication

src/Mono.Android/Android.Runtime/JNIEnvInit.cs:141

🤖 💡 Code organization — Nice refactoring: the runtime-identity validation IsMonoRuntime == IsCoreClrRuntime (exactly-one-must-be-true) is cleaner and more correct than the old IsMonoRuntime && IsCoreClrRuntime (only-both-not-both) check. The new check correctly rejects the case where neither is set.

Rule: Positive callout