[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.

Visibility & signing changes

• Makes scanner/generator types (JavaPeerScanner, JavaPeerInfo, JcwJavaSourceGenerator, TypeMapAssemblyGenerator, RootTypeMapAssemblyGenerator, etc.) public so they can be consumed by the MSBuild task in Xamarin.Android.Build.Tasks.
• Adds strong-name signing (product.snk) to Microsoft.Android.Sdk.TrimmableTypeMap and its unit test project — required because Xamarin.Android.Build.Tasks is strong-name signed.

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.

[simonrozsival]

🤖 AI Review Summary

Verdict: ⚠️ Needs Changes

Found 4 issues (0 errors, 2 warnings, 2 suggestions).

• ⚠️ MSBuild targets: Generated typemap assemblies and Java files under $(IntermediateOutputPath)typemap\ are not registered in @(FileWrites). IncrementalClean may delete them while the stamp file remains, breaking subsequent builds. (Trimmable.targets:47)
• ⚠️ MSBuild targets: Item group empty check '@(_GeneratedTypeMapAssemblies)' != '' should use ->Count() to avoid joining all paths into a string. (CoreCLR.targets:10, NativeAOT.targets:10)
• 💡 API design: Several types were changed from internal to public but are only consumed by the GenerateTrimmableTypeMap MSBuild task. Consider adding [InternalsVisibleTo] for Xamarin.Android.Build.Tasks instead to keep the API surface minimal. (JavaPeerScanner.cs:17, JavaPeerInfo.cs:11, and 5 more files)
• 💡 Nullable: GenerateTrimmableTypeMap.cs uses nullable annotations (ITaskItem[]?) but lacks #nullable enable — nullable flow analysis isn't active for this file. Other new task files in this project use per-file #nullable enable. (GenerateTrimmableTypeMap.cs:1)

👍 Positive callouts:

• Clean AndroidTask implementation with correct return !Log.HasLoggedErrors pattern and proper [Required]/[Output] property declarations.
• Good per-assembly incremental check via IsUpToDate timestamp comparison.
• Thorough test coverage including empty inputs, real assembly scanning, incrementality, touched-source regeneration, and TFV parsing.
• The FileWrites pattern from LlvmIr.targets (the existing typemap path) is a good reference for how to fix the FileWrites concern.

CI status: Pending — strong-name signing fix was just pushed. Previous run failed with CS8002 (unsigned assembly).

---

Review generated by android-reviewer from review guidelines.

[simonrozsival]

🤖 💡 API design — This type (and JavaPeerInfo, MarshalMethodInfo, JniParameterInfo, JavaConstructorInfo, ActivationCtorInfo, ActivationCtorStyle, JcwJavaSourceGenerator, RootTypeMapAssemblyGenerator, TypeMapAssemblyGenerator) were changed from internal to public. These are only consumed by the GenerateTrimmableTypeMap MSBuild task in Xamarin.Android.Build.Tasks. Making them public exposes them as API surface that customers could depend on.

Consider keeping them internal and adding [InternalsVisibleTo("Xamarin.Android.Build.Tasks")] in the TrimmableTypeMap csproj instead. This is consistent with the existing InternalsVisibleTo entries for test projects.

Rule: New helpers default to internal (Code Organization #4)

[simonrozsival]

Intentionally keeping these public. The benchmark script in the PR description consumes them directly, and they'll also be useful for the pre-generation step in #10760 which runs outside of Xamarin.Android.Build.Tasks. This assembly isn't part of the public SDK surface shipped to customers — it's an internal build-time dependency.

[jonathanpeppers]

I think this is ok for a first pass, but I think we could let MSBuild natively do the timestamp checking & run the target partially.

If you had:

<Target
  Inputs="a.in;b.in;c.in"
  Outputs="a.out;b.out;c.out"

  <!-- ... -->
  <MyTask InFiles="a.in;b.in;c.in" />

If only b.in changes during an incremental build, MSBuild can run the target "partially", and it would automatically only pass in b.in to the task.

The Inputs/Outputs need to be 1-1, and then you can have additional Inputs files at the end of the list -- so you'd have to make sure the files coming are ordered that way.

If we did this, we'd get rid of _GenerateJavaStubs.stamp.

There is a AssertTargetIsPartiallyBuilt, we have in a few tests.

[simonrozsival]

Agreed — MSBuild partial builds with 1-1 Inputs/Outputs would be the right approach here. We iterated on the incremental build story during this PR and it was getting out of hand, so I'd like to tackle it in a dedicated follow-up PR once the trimmable typemap path is functionally complete. The current timestamp check inside the task is a reasonable first pass.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[jonathanpeppers]

Xamarin.Android-PR CI Failure Summary (build 13546162)

1. BuildWithTrimmableTypeMapSucceeds — MSB4062: Task assembly not found (Windows)

error MSB4062: The "Xamarin.Android.Tasks.GenerateTrimmableTypeMap" task could not be loaded from the assembly ...Xamarin.Android.Build.Tasks.dll. The system cannot find the file specified.

The GenerateTrimmableTypeMap task can't be loaded because Xamarin.Android.Build.Tasks.dll doesn't exist at the expected SDK pack path. This looks like a packaging/deployment issue where the task DLL isn't being included in the test SDK pack correctly.

2. BinSkim BA2021 errors — 364 errors from BuildWithTrimmableTypeMapIncrementalBuild (Windows)

All BA2021 (DoNotMarkWritableSectionsAsExecutable) errors are from the BuildWithTrimmableTypeMapIncrementalBuild test output directory. This is a Debug/CoreCLR build where R2R assemblies have writable executable sections. This appears to be a pre-existing BinSkim issue (the Guardian scan picks up test output assemblies), but it's triggered here because the BuildWithTrimmableTypeMapIncrementalBuild test is new.

3. Emulator launch timeout — macOS emulator failed to start (macOS)

error: Emulator '-s emulator-5570' did not finish launching in 1200000 ms.

This is an infrastructure flake — the emulator didn't boot within 20 minutes. Unrelated to the PR.

4. AppWithStyleableUsageRuns(False,True,False,False) — Build failure (macOS emulator)

Failed during Install target with a build failure. This is a device/emulator integration test — likely cascading from the emulator timeout (#3) or a pre-existing flake.

5. BuildXAMLChange(False) — Performance timeout (macOS emulator)

Exceeded expected time of 3000ms, actual 3010.549ms

Flaky performance test — exceeded the threshold by just 10ms. Unrelated to this PR.

Verdict

Only #1 is caused by this PR — the GenerateTrimmableTypeMap task assembly isn't being found at runtime. The rest are pre-existing BinSkim noise, infra flakes, and timing flakes.

[simonrozsival]

Thanks for the analysis! Fixed #1 in 2c91e1e — the UsingTask was using a bare Xamarin.Android.Build.Tasks.dll filename instead of $(_XamarinAndroidBuildTasksAssembly) like all the other shipped tasks. The rest are pre-existing/infra as you noted.

[elinor-fung]

Is it worth seeing how/if having the JcwJavaSourceGenerator generate source for each type in parallel affects the build times? From what I can tell from #10917, each generation should be pretty independent.

[elinor-fung]

Same question for scanning.

[simonrozsival]

I will open an issue so we revisit this later and improve build time if possible.

[simonrozsival]

Filed #10958 to track this and other build-time optimization opportunities.