[TrimmableTypeMap] Add JavaPeerScanner using System.Reflection.Metadata

[simonrozsival]

Part of #10789
Closes #10798

Summary

This PR adds the Microsoft.Android.Sdk.TrimmableTypeMap project with the JavaPeerScanner — a System.Reflection.Metadata-based assembly scanner that identifies Java peer types, their JNI signatures, and type relationships needed for the trimmable typemap.

What's included

Scanner (JavaPeerScanner)

• Scans assemblies for types with [Register] attributes (Java peers)
• Resolves JNI type names and method signatures using SRM
• Computes CRC64-based JNI names for user types without explicit [Register]
• Computes CompatJniName (lowercased namespace) for acw-map.txt backward compatibility
• Detects base class relationships (ExtendsJavaPeer with cycle detection + caching)
• Resolves base Java type names and implemented Java interfaces (including generic instantiations)
• Extracts [Application] attribute properties (BackupAgent, ManageSpaceActivity) for unconditional forcing
• Detects component attributes ([Activity], [Service], etc.) for unconditional marking
• Supports IJniNameProviderAttribute for custom JNI name resolution
• Collects marshal methods ([Register] + [Export]) and Java constructors in a single pass
• Resolves activation constructors (XI and JI styles) with hierarchy walking

Supporting types

• AssemblyIndex — Phase 1 index builder with shared static helpers for cross-assembly type resolution
• CustomAttributeTypeProvider — Decodes custom attribute blobs (including enums and nested types)
• SignatureTypeProvider — Resolves method signatures from metadata (singleton, handles nested types)
• JavaPeerInfo — Data model for scanner results (all fields needed by downstream JCW/typemap generators)

Edge cases found and handled via side-by-side testing

Testing against Mono.Android.dll (~8,000 types) gives false confidence — all MCW binding types have explicit [Register] attributes, so the hard logic paths are never exercised. A UserTypesFixture.dll with real user-type patterns was essential:

• Nested type JNI name inheritance: OuterClass+InnerHelper where OuterClass has [Register("com/example/OuterClass")] must produce com/example/OuterClass_InnerHelper, not an independent CRC64 name. The scanner walks up declaring types and uses the parent's registered JNI name as prefix, matching JavaNativeTypeManager.ToJniName behavior.

• Component-attributed base types: A DerivedActivity extending a BaseActivity that has [Activity] but no [Register] must still be recognized as a Java peer. ExtendsJavaPeerCore checks both RegisterInfoByType and AttributesByType.

• Generic interface implementations: IList<T> is a TypeSpecification in metadata, not a TypeReference. The scanner reads the raw signature blob (GENERICINST → CLASS/VALUETYPE → coded token) to resolve the underlying type definition.

• Nested TypeReference resolution scope: A nested type defined in another assembly has a ResolutionScope that points to another TypeReference (its declaring type), not directly to an AssemblyReference. The shared ResolveTypeReference helper recurses up the scope chain.

• Assembly-qualified type names: [Application(BackupAgent=typeof(X))] serializes as "Ns.Type, Assembly, Version=..." — must strip the assembly qualification before looking up in resultsByManagedName.

• [Export] methods: [Export("doWork")] generates Java callable wrappers via a different mechanism than [Register]. The scanner handles both via ParseExportAttribute, including ThrownNames and SuperArgumentsString.

CRC64 polynomial

The scanner uses System.IO.Hashing.Crc64 (ECMA polynomial) instead of the legacy Crc64Helper (Jones polynomial). This is intentional — the CRC64 hash only needs to be self-consistent within a single compilation. The scanner computes crc64{hash}/TypeName, the JCW generator creates a .java file with that name, and the typemap records it. All consumers read from the same scan pass.

Tests

• 75 unit tests covering scanner logic, JNI name computation, parsing, edge cases
• 10 integration tests — side-by-side comparison with legacy Cecil-based scanner on both Mono.Android.dll and UserTypesFixture.dll

Follow-up

• [TrimmableTypeMap] Decompose _GenerateJavaStubs: shared tasks for trimmable path #10807 — Decompose _GenerateJavaStubs mega-target for shared tasks

[simonrozsival]

This PR has been split into 3 stacked PRs to simplify the review:

1. [TrimmableTypeMap] Java peer scanner core #10823

   • Scanner project, data model, metadata providers, AssemblyIndex, JavaPeerScanner logic.

2. [TrimmableTypeMap] Scanner unit tests #10813

   • Test fixtures, foundational tests, behavior/contract tests, edge-case regressions, CI wiring.

3. [TrimmableTypeMap] Integration parity tests #10827

   • Side-by-side comparison tests against the existing scanner, CI wiring.

[Copilot]

Pull request overview

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

[Copilot]

The Microsoft.Android.Sdk.TrimmableTypeMap.Tests project is missing from the solution file. While the CI pipeline explicitly references the test project and runs the tests, developers won't be able to build or run these tests from Visual Studio or other IDEs that use the solution file. This creates an inconsistent developer experience.

Add a project entry for Microsoft.Android.Sdk.TrimmableTypeMap.Tests similar to the IntegrationTests project already included here.

Suggested change

	EndProject
	EndProject
	Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Microsoft.Android.Sdk.TrimmableTypeMap.Tests", "tests\Microsoft.Android.Sdk.TrimmableTypeMap.Tests\Microsoft.Android.Sdk.TrimmableTypeMap.Tests.csproj", "{B6D8D9E3-4C8B-4B3E-9F37-6A4A5F0D8E21}"
	EndProject

[Copilot]

Potential resource leak: File.OpenRead returns a FileStream that's passed to PEReader. If an exception occurs in Build() before completion, the FileStream may not be properly disposed. PEReader will dispose the stream when it's disposed, but only if the PEReader construction succeeds.

Consider wrapping the Create method body in a try-catch to ensure proper cleanup, or use a using statement for the FileStream before passing it to PEReader.

Suggested change

	var peReader = new PEReader (File.OpenRead (filePath));
	var reader = peReader.GetMetadataReader ();
	var assemblyName = reader.GetString (reader.GetAssemblyDefinition ().Name);
	var index = new AssemblyIndex (peReader, reader, assemblyName, filePath);
	index.Build ();
	return index;
	FileStream? stream = null;
	PEReader? peReader = null;
	try {
	stream = File.OpenRead (filePath);
	peReader = new PEReader (stream);
	var reader = peReader.GetMetadataReader ();
	var assemblyName = reader.GetString (reader.GetAssemblyDefinition ().Name);
	var index = new AssemblyIndex (peReader, reader, assemblyName, filePath);
	index.Build ();
	return index;
	} catch {
	if (peReader != null) {
	peReader.Dispose ();
	} else if (stream != null) {
	stream.Dispose ();
	}
	throw;
	}