[TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets

[simonrozsival]

Part of #10800
Stacked on #10917.

Summary

Adds the GenerateTrimmableTypeMap MSBuild task and wires it into the trimmable targets files, replacing the stub _GenerateJavaStubs target with real typemap + JCW generation.

Task (GenerateTrimmableTypeMap)

• Extends AndroidTask (TaskPrefix GTT)
• Scans resolved assemblies → groups by source assembly → generates per-assembly typemap .dll assemblies → generates root _Microsoft.Android.TypeMaps.dll → generates JCW .java source files
• Filters BCL assemblies (FrameworkAssembly=true without HasMonoAndroidReference) to skip unnecessary scanning
• Per-assembly timestamp check: skips emission when output .TypeMap.dll is newer than source .dll

Targets

• Microsoft.Android.Sdk.TypeMap.Trimmable.targets: Replaces stub with real GenerateTrimmableTypeMap task call. Defines _TypeMapOutputDirectory and _TypeMapJavaOutputDirectory (co-located under typemap/). Configures RuntimeHostConfigurationOption for TypeMappingEntryAssembly.
• Trimmable.CoreCLR.targets: Adds generated assemblies to _ResolvedAssemblies for the linker (without TrimmerRootAssembly — the trimmer must process TypeMapAttribute entries and trim ones whose target types were removed).
• Trimmable.NativeAOT.targets: Adds to IlcReference + UnmanagedEntryPointsAssembly (without TrimmerRootAssembly).

Performance

Benchmark on MacBook M1, scanning Mono.Android.dll (~8870 types), 169 iterations over 5 minutes:

Phase	Avg	P50	P95	Min
Scan (8870 types)	235ms	224ms	319ms	175ms
Emit (typemap assemblies)	86ms	75ms	181ms	51ms
JCW (315 Java files)	766ms	409ms	3167ms	102ms
Total cold	1088ms	702ms	3878ms	370ms
Total incremental (scan only)	221ms	215ms	282ms	179ms
Savings	867ms (80%)

Cold build cost is dominated by JCW file I/O (high p95 variance from disk contention). Incremental builds (unchanged assemblies) skip emit entirely — only the scan runs (~215ms).

Note: scanning currently rescans all assemblies on every build (needed for cross-assembly type resolution). This is a known limitation — future optimization could cache scan results or add a two-list scan overload that only produces JavaPeerInfo for changed assemblies while still indexing all for cross-references. Profiling is needed before optimizing.

Benchmark script

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;
using Microsoft.Android.Sdk.TrimmableTypeMap;

var monoAndroidDll = args[0];
int durationSeconds = args.Length > 1 ? int.Parse(args[1]) : 300;

// Warmup (3 runs)
for (int w = 0; w < 3; w++) {
    var d = Path.Combine(Path.GetTempPath(), $"typemap-warmup-{w}");
    Directory.CreateDirectory(d);
    var j = Path.Combine(d, "java");
    Directory.CreateDirectory(j);
    using (var s = new JavaPeerScanner()) {
        var p = s.Scan(new[] { monoAndroidDll });
        new TypeMapAssemblyGenerator(new Version(11, 0)).Generate(p, Path.Combine(d, "w.dll"), "w");
        new JcwJavaSourceGenerator().Generate(p, j);
    }
    Directory.Delete(d, true);
}

var scanT = new List<long>();
var emitT = new List<long>();
var jcwT = new List<long>();
var totalColdT = new List<long>();
var scanOnlyT = new List<long>();
var deadline = Stopwatch.StartNew();

while (deadline.Elapsed.TotalSeconds < durationSeconds) {
    var outputDir = Path.Combine(Path.GetTempPath(), $"typemap-bench-{Guid.NewGuid():N}");
    Directory.CreateDirectory(outputDir);
    var javaDir = Path.Combine(outputDir, "java");
    Directory.CreateDirectory(javaDir);
    try {
        var sw = Stopwatch.StartNew();
        List<JavaPeerInfo> peers;
        using (var scanner = new JavaPeerScanner()) { peers = scanner.Scan(new[] { monoAndroidDll }); }
        sw.Stop(); scanT.Add(sw.ElapsedMilliseconds);

        sw = Stopwatch.StartNew();
        new TypeMapAssemblyGenerator(new Version(11, 0)).Generate(peers, Path.Combine(outputDir, "_M.dll"), "_M");
        new RootTypeMapAssemblyGenerator(new Version(11, 0)).Generate(new[] { "_M" }, Path.Combine(outputDir, "_R.dll"));
        sw.Stop(); emitT.Add(sw.ElapsedMilliseconds);

        sw = Stopwatch.StartNew();
        new JcwJavaSourceGenerator().Generate(peers, javaDir);
        sw.Stop(); jcwT.Add(sw.ElapsedMilliseconds);

        totalColdT.Add(scanT[^1] + emitT[^1] + jcwT[^1]);

        sw = Stopwatch.StartNew();
        using (var scanner = new JavaPeerScanner()) { scanner.Scan(new[] { monoAndroidDll }); }
        sw.Stop(); scanOnlyT.Add(sw.ElapsedMilliseconds);
    } finally {
        try { Directory.Delete(outputDir, true); } catch {}
    }
}

Tests

Unit tests (8 tests with MockBuildEngine):

• Empty assembly list succeeds
• Real Mono.Android.dll produces per-assembly + root typemaps
• Second run skips up-to-date assemblies (timestamp unchanged, "up to date" logged)
• Source touched → regenerates only changed assembly
• Invalid TargetFrameworkVersion fails with error
• TFV parsing (v11.0, v10.0, 11.0)

Integration tests (full dotnet build):

• Build with _AndroidTypeMapImplementation=trimmable on CoreCLR succeeds
• Incremental build skips _GenerateJavaStubs

Follow-up work

• Per-assembly scan optimization (two-list Scan overload or cached indices)
• JCW file write optimization (skip unchanged files — attempted but read+compare cost negated savings)
• Pre-generate _Mono.Android.TypeMap.dll during SDK build ([CoreCLR] Build R2R images for SDK assemblies in Debug builds #10760)

[simonrozsival]

🤖 AI Review Summary

Verdict: ✅ LGTM

Found 0 issues.

Reviewed against all 14 rule categories:

• ✅ MSBuild tasks: Extends AndroidTask, TaskPrefix defined, returns !Log.HasLoggedErrors, [Required] properties have defaults, [Output] properties nullable
• ✅ MSBuild targets: Internal names prefixed with _, Inputs/Outputs with stamp file for incrementality, AfterTargets used appropriately (no DependsOn available), no TrimmerRootAssembly (correct — trimmer must process TypeMapAttributes)
• ✅ Nullable: No null-forgiving !, no #nullable enable (project-level)
• ✅ Error handling: ParseTargetFrameworkVersion throws on bad input, no empty catch blocks
• ✅ Performance: BCL assemblies filtered via FrameworkAssembly/HasMonoAndroidReference metadata, per-assembly timestamp check skips unchanged typemaps, LINQ used cleanly
• ✅ Code organization: Types made public for cross-assembly consumption (build-time only, not shipped in apps), UsingTask scoped to trimmable targets only
• ✅ Formatting: Tabs, Mono style throughout

👍 Clean task design with good incrementality (per-assembly timestamp skipping). Benchmark data in the PR description validates the approach. RuntimeHostConfigurationOption correctly shared between CoreCLR and NativeAOT. AfterTargets usage is justified since there's no DependsOn property to hook into.

---

Review generated by android-reviewer from review guidelines.