[CoreCLR] Stabilize Debug typemaps across C# rebuilds

[jonathanpeppers]

---

Pull Request
title and
description
should follow the
commit-messages.md workflow documentation, and in particular should include:

• Useful description of why the change is necessary.
• Links to issues fixed: N/A
• Unit tests

CoreCLR Debug typemaps embedded application assembly MVIDs. Because an MVID changes on every compilation, a C#-only rebuild rewrote the native typemap even when no Java mappings had changed. That cascaded into native compilation, APK rebuilding, and re-signing on every Fast Deployment cycle.

This changes Debug managed-to-Java entries to key on stable assembly full names and removes the Debug MVID table entirely. Release continues to use its MVID-based lookup, and a trimmer feature switch prevents Assembly.FullName retrieval and marshalling from being rooted in Release builds.

Runtime

clr_typemap_managed_to_java now takes an assembly display name alongside the type name, and TypeMapper::managed_to_java is split on RELEASE so each configuration only sees the parameter it uses. When $(RuntimeFeature.ManagedToJavaUsesAssemblyFullName) is enabled, JNIEnv.TypemapManagedToJava skips computing the MVID altogether rather than computing it and discarding it. A null display name is left for the native side to report, which keeps a single diagnostic path for all callers.

TypeMapCecilAdapter.GetRuntimeAssemblyFullName reproduces reflection's escaping and PublicKeyToken formatting so that the build-time name matches what Assembly.FullName returns at runtime; a mismatch here would silently break every lookup.

Tests

IncrementalBuildTest performs a C#-only change on the CoreCLR Debug path and asserts the typemap and signed APK are byte-for-byte unchanged, and that _CompileNativeAssemblySources, _CreateApplicationSharedLibraries, _BuildApkFastDev, and _Sign are all skipped.

FastDeployUpdatesTypeMapAfterAssemblyEdit is a device test covering three deployments, parameterized over both FastDeploy and FastDeploy2:

1. Deploy with only MainActivity.
2. Add a SecondActivity. This is a C#-only edit, but it introduces a new Java-callable type. Fast deployment only syncs managed assemblies, so the Java stubs, .dex, typemap, APK and signature must all be rebuilt and the package reinstalled. This confirms a typemap-affecting C# change is picked up automatically, with no clean required.
3. Add a Console.WriteLine() to SecondActivity.OnCreate(). No Java-callable types change, so the packaging and signing targets are skipped and the APK is not reinstalled. The message is asserted in logcat to prove the updated assembly really was deployed rather than merely that nothing was rebuilt.

BuildOutput.IsApkInstalled now throws below LoggerVerbosity.Detailed. It scans for an Installed Package message logged at MessageImportance.Low, so at a lower verbosity it silently returned false no matter what the build did — which broke the new test on CI and had been quietly making some pre-existing Assert.IsFalse calls vacuous.

[Copilot]

Pull request overview

Stabilizes CoreCLR Debug typemap generation so C#-only rebuilds don’t force native typemap regeneration (and therefore avoid unnecessary native compilation, APK rebuild, and signing) during Fast Deployment. This is done by switching Debug managed-to-Java typemap keys from assembly MVID-based lookup to stable assembly identity strings, while keeping Release behavior MVID-based behind a feature switch.

Changes:

• CoreCLR Debug managed-to-Java typemap entries now use Assembly.FullName-based keys; removed the Debug MVID table/type_map_unique_assemblies plumbing.
• Added a runtime feature switch (enabled for Debug via MSBuild) to control whether managed-to-Java lookup passes/uses assembly full name.
• Extended incremental build coverage to verify typemap + signed APK remain unchanged for C#-only edits and that key fast-deploy targets are skipped.

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Xamarin.Android.Build.Tasks/Utilities/TypeMappingDebugNativeAssemblyGeneratorCLR.cs	Switch Debug managed-to-Java entries to assembly full name; remove unique-assemblies MVID table emission.
src/Xamarin.Android.Build.Tasks/Utilities/TypeMapObjectsXmlFile.cs	Persist/import assembly-full-name for Debug typemap object XML.
src/Xamarin.Android.Build.Tasks/Utilities/TypeMapGenerator.cs	Add AssemblyFullName to debug typemap entry model.
src/Xamarin.Android.Build.Tasks/Utilities/TypeMapCecilAdapter.cs	Populate AssemblyFullName from Cecil for debug entries.
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/IncrementalBuildTest.cs	Add incremental test ensuring typemap and signed APK unchanged for C#-only edits (CoreCLR Debug).
src/Xamarin.Android.Build.Tasks/Tasks/GenerateEmptyTypemapStub.cs	Remove debug unique-assemblies stub symbol to match new Debug layout.
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.CoreCLR.targets	Enable new runtime feature switch for Debug via RuntimeHostConfigurationOption.
src/Xamarin.Android.Build.Tasks/Linker/MonoDroid.Tuner/FindTypeMapObjectsStep.cs	Emit assembly full name into typemap XML in Debug.
src/native/nativeaot/host/internal-pinvoke-stubs.cc	Update internal-pinvoke stub signature for new parameter.
src/native/clr/xamarin-app-stub/application_dso_stub.cc	Remove Debug unique-assemblies fields/symbols from stub DSO.
src/native/clr/include/xamarin-app.hh	Remove Debug TypeMapAssembly + type_map_unique_assemblies exports; adjust TypeMap layout.
src/native/clr/include/runtime-base/internal-pinvokes.hh	Update clr_typemap_managed_to_java signature to include assembly full name.
src/native/clr/include/host/typemap.hh	Conditionalize managed-to-Java API for Release (MVID) vs Debug (assembly full name).
src/native/clr/host/typemap.cc	Implement Debug lookup via typeName + \", \" + assemblyFullName; remove MVID-to-name lookup path.
src/native/clr/host/internal-pinvokes-clr.cc	Route managed-to-Java internal pinvoke to the new Debug signature vs Release signature.
src/Mono.Android/Microsoft.Android.Runtime/RuntimeFeature.cs	Add ManagedToJavaUsesAssemblyFullName feature switch definition.
src/Mono.Android/Android.Runtime/RuntimeNativeMethods.cs	Extend P/Invoke to pass optional assembly full name.
src/Mono.Android/Android.Runtime/JNIEnv.cs	In CoreCLR path, pass assembly full name only when feature is enabled.

[jonathanpeppers]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

🤖 Code Review — ⚠️ Looks solid, minor suggestions

Thorough, well-scoped change. The Debug CoreCLR typemap now keys managed→Java lookups on the stable assembly full name (Name, Version, Culture, PublicKeyToken) embedded directly in the string blob, dropping the per-assembly MVID table (type_map_unique_assemblies) and its binary search. Because MVIDs change on every C# rebuild, removing them from the Debug typemap is what lets a C#-only edit skip native compile / APK rebuild / signing during Fast Deployment — the incremental test verifies exactly that. Release keeps its MVID-based lookup untouched.

Design consistency verified. All three Debug/Release toggles line up on $(AndroidIncludeDebugSymbols):

• native runtime flavor (libnet-android.debug vs .release, i.e. DEBUG/RELEASE compile) — ProcessNativeLibraries
• _TypeMapKind = strings-asm vs mvid
• the new ManagedToJavaUsesAssemblyFullName feature switch

So the managed side only pays type.Assembly.FullName in Debug, the trimmer can drop it in Release, and there's no Debug-native/Release-typemap mismatch. The #if RELEASE split of managed_to_java/clr_typemap_managed_to_java and the null-assemblyFullName guard are correct, and the NativeAOT/stub signatures were updated in lockstep. The UniqueAssemblies sort was switched from MVID order to Ordinal name order, which is what makes the assembly-names blob deterministic across rebuilds. 👍

Suggestions (non-blocking): 2 inline 💡 comments

• Confirm/harden the assumption that the build-time GetRuntimeAssemblyFullName is byte-identical to runtime Assembly.FullName for all mapped assemblies (a unit test would help).
• Optional simplification of the EndsWith/Substring reconstruction and a note that AssemblyFullName isn't validated non-empty.

Testing: Good coverage — new incremental assertion (typemap .ll + signed APK unchanged, _CompileNativeAssemblySources/_CreateApplicationSharedLibraries/_BuildApkFastDev/_Sign skipped after a C#-only change) plus the GetRuntimeAssemblyFullName escaping unit test.

CI: In progress at review time; Linux build and the completed test legs are green, no failures observed. Verify all dotnet-android legs (especially the CoreCLR Debug device/emulator tests) go green before merge.

Generated by Android PR Reviewer for #12216 · 208.4 AIC · ⌖ 13.5 AIC · ⊞ 6.8K
_{Comment /review to run again}

[jonathanpeppers]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

⚠️ Review Summary — Needs Changes (minor)

Solid, well-scoped change. Replacing the Debug MVID-based typemap with stable assembly full names is the right fix for the incremental/fast-deploy churn, and the C++/C# struct layouts stay in sync (TypeMap, TypeMapManagedTypeInfo, the stub in application_dso_stub.cc, and GenerateEmptyTypemapStub all match). Release keeps its MVID path, correctly gated behind the ManagedToJavaUsesAssemblyFullName feature switch, which is driven by the same $(AndroidIncludeDebugSymbols) property that selects the debug native runtime and the strings-based typemap — so the managed switch and native DEBUG/RELEASE compile path stay consistent. Good test coverage: the new IncrementalBuildTest asserts typemap + APK hash stability across a C#-only change, and LlvmIrGeneratorTests covers the escaping/strong-name formatting of GetRuntimeAssemblyFullName.

Issue counts: ⚠️ 1 · 💡 2 (all inline)

Positive callouts:

• Removing the TypeMapAssembly table and its binary-search-by-MVID meaningfully simplifies managed_to_java_debug.
• GetRuntimeAssemblyFullName correctly reproduces reflection escaping/PublicKeyToken formatting rather than relying on Cecil's FullName.
• NativeAOT and CoreCLR p/invoke stubs were both updated for the new signature.

Main thing to confirm (inline): the removed native fallback means a build-time vs runtime assembly-full-name mismatch now fails silently. Please confirm behavior for projects with non-deterministic/wildcard assembly versions, or document that stable versions are required for Debug fast deployment.

Note: mergeable_state is blocked (pending review/required checks) — not verified as a code failure here.

Generated by Android PR Reviewer for #12216 · 151.1 AIC · ⌖ 19 AIC · ⊞ 6.8K
_{Comment /review to run again}

[rolfbjarne]

The existing incremental build test now performs a C#-only change and verifies that the typemap and signed APK remain unchanged and that _CompileNativeAssemblySources, _CreateApplicationSharedLibraries, _BuildApkFastDev, and _Sign are skipped.

What if the C#-only change is such that the type map should change? Is that automatically detected, or will users have to clean their projects to get the right things to rebuild?

[jonathanpeppers]

What if the C#-only change is such that the type map should change? Is that automatically detected, or will users have to clean their projects to get the right things to rebuild?

This test does this:

android/tests/MSBuildDeviceIntegration/Tests/FastDevTest.cs

Lines 41 to 82 in fb30bbf

	[Test]
	public void FastDeployUpdatesTypeMapAfterAssemblyEdit ()
	{
	var proj = new XamarinAndroidApplicationProject {
	PackageName = "com.xamarin.fastdeploy_typemap",
	};
	proj.SetDefaultTargetDevice ();
	proj.SetProperty ("_AndroidFastDevStrategy", "FastDeploy");
	proj.MainActivity = proj.DefaultMainActivity
	.Replace ("//${AFTER_ONCREATE}", "StartActivity (new Android.Content.Intent (this, typeof (SecondActivity)));")
	.Replace ("//${AFTER_MAINACTIVITY}", """
	[Activity (Label = "Fast Deploy Result")]
	public sealed class SecondActivity : Activity
	{
	}
	""");
	using var builder = CreateApkBuilder ();
	Assert.IsTrue (builder.Install (proj), "Initial install should have succeeded.");
	AssertSecondActivityStarts ("initial-launch.log");
	proj.MainActivity += "// Incremental C# edit.";
	proj.Touch ("MainActivity.cs");
	Assert.IsTrue (builder.Install (proj, doNotCleanupOnUpdate: true, saveProject: false), "Incremental install should have succeeded.");
	AssertSecondActivityStarts ("incremental-launch.log");
	Assert.IsTrue (builder.Uninstall (proj), "Uninstall should have succeeded.");
	void AssertSecondActivityStarts (string logFileName)
	{
	ClearAdbLogcat ();
	AdbStartActivity ($"{proj.PackageName}/{proj.JavaPackageName}.MainActivity");
	Assert.IsTrue (
	WaitForActivityToStart (
	proj.PackageName,
	"SecondActivity",
	Path.Combine (Root, builder.ProjectDirectory, logFileName),
	ActivityStartTimeoutInSeconds
	),
	"SecondActivity should have started."
	);
	}
	}

Asserts a new activity class can be navigated to, which means the Java code and typemap were updated.

Let me add some assertions to it, to verify the appropriate targets are skipped/not skipped.

[jonathanpeppers]

Actually, the above test should only add the activity on the second deploy.