[TrimmableTypeMap] Remove InvokerType from JavaPeerProxy

[simonrozsival]

Replaces #11970 (moved off the fork so PR CI runs on the dotnet-android public pipeline; branch now lives on dotnet/android).

Summary

The trimmable typemap activates managed peers exclusively through the generated JavaPeerProxy.CreateInstance, so the InvokerType exposed on the JavaPeerProxy attribute is never consumed at runtime. JavaMarshalValueManager.CreatePeer calls TrimmableTypeMap.CreateInstance and never falls back to invoker-type reflection.

This PR removes InvokerType from JavaPeerProxy and everything that fed it.

Changes

Runtime (src/Mono.Android)

• JavaPeerProxy / JavaPeerProxy<T>: dropped the invokerType constructor parameter and the InvokerType property.
• TrimmableTypeMap: removed the now-dead GetInvokerType.
• TrimmableTypeMapTypeManager.GetInvokerTypeCore: throws in the trimmable path (peers are activated via JavaPeerProxy.CreateInstance).

Generator (src/Microsoft.Android.Sdk.TrimmableTypeMap)

• TypeMapAssemblyEmitter: the generated proxy .ctor no longer passes an invoker Type/ldnull to the base constructor; base ctor refs are now (string, Type) (non-generic) and (string) (generic). The model's InvokerType is retained where genuinely required — emitting CreateInstance and UCO constructor activation for interfaces/abstract classes.

Tests

• JavaPeerProxyTests: dropped the InvokerType assertions/fixture; added coverage for the generic JavaPeerProxy<T> constructor.
• JniRuntimeJniTypeManagerTests.GetInvokerType: tagged [Category ("TrimmableTypeMapUnsupported")] (the trimmable type manager throws from GetInvokerTypeCore, so this reflection-based test only applies to the other typemap implementations).

Test plan

• Microsoft.Android.Sdk.TrimmableTypeMap.Tests: 604/604 passing.
• Device test legs (CoreCLR trimmable) via CI.

[Copilot]

Pull request overview

This PR removes the InvokerType concept from the JavaPeerProxy attribute used by the TrimmableTypeMap path, updating the runtime attribute API, the typemap generator’s emitted proxy constructors, and associated tests to reflect the new activation model (via generated CreateInstance).

Changes:

• Runtime: JavaPeerProxy / JavaPeerProxy<T> drop the InvokerType property and constructor parameter; TrimmableTypeMap removes the now-dead GetInvokerType helper.
• Generator: TypeMapAssemblyEmitter updates emitted proxy .ctor calls to match the new base constructor signatures.
• Tests: JavaPeerProxyTests are updated to validate the generic proxy constructor behavior; GetInvokerType reflection test is categorized as unsupported under TrimmableTypeMap runs.

Show a summary per file

File	Description
tests/Mono.Android-Tests/Mono.Android-Tests/Java.Interop/JavaPeerProxyTests.cs	Updates tests to no longer assert InvokerType and adds coverage for JavaPeerProxy<T> ctor behavior.
src/Mono.Android/Microsoft.Android.Runtime/TrimmableTypeMap.cs	Removes the runtime GetInvokerType helper (but currently leaves a doc-comment artifact and a ctor-call site that must be updated).
src/Mono.Android/Java.Interop/JavaPeerProxy.cs	Removes InvokerType from the attribute API and adjusts constructors accordingly.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Generator/TypeMapAssemblyEmitter.cs	Updates emitted base-ctor signatures/argument counts for generated proxy attribute types.
external/Java.Interop/tests/Java.Interop-Tests/Java.Interop/JniRuntime.JniTypeManagerTests.cs	Tags a reflection-based invoker-type test with TrimmableTypeMapUnsupported category for TrimmableTypeMap runs.

Copilot's findings

• Files reviewed: 5/5 changed files
• Comments generated: 3

[simonrozsival]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

🤖 Code Review Summary

Verdict: ⚠️ No blocking issues found in review, but CI is still running (queued/in‐progress, not yet green) — hold merge until the CoreCLR trimmable device legs pass.

This is a clean, tightly‐scoped removal of dead runtime state. I verified:

• ✅ IL emission matches the new runtime ctors. The non‐generic base ctor ref (string, Type), the generic base ctor ref (string), and the emitted .ctor arity (parameterCount: useNonGenericBase ? 2 : 1) line up exactly with JavaPeerProxy (string, Type) and JavaPeerProxy<T> (string) : base (jniName, typeof (T)).
• ✅ No dangling callers. The removed runtime JavaPeerProxy.InvokerType had no consumers other than TrimmableTypeMap.GetInvokerType (also removed). All hand‐written subclasses (MissingJavaPeerProxy, the test proxies) were updated to the new ctor shapes, and TrimmableTypeMapTypeManager.GetInvokerTypeCore already throws UnreachableException — confirming invoker types are never fetched via reflection in the trimmable path.
• ✅ Generator model InvokerType correctly retained. The JavaPeerProxyData.InvokerType (a different type from the runtime attribute) is still consumed by EmitCreateInstance and the UCO activation path for interfaces/abstract classes, so activation behaviour is unchanged.
• ✅ Tests. Swapping Constructor_StoresInvokerType for GenericConstructor_StoresJniNameAndTargetType is the right move and adds coverage for the new single‐arg generic ctor.
• ✅ Public API baselines. JavaPeerProxy/InvokerType aren't tracked in PublicAPI.*.txt, so no baseline update is required.

Findings: 0 ❌ · 0 ⚠️ · 1 💡 (inline — a metadata‐only test gap around the emitted .ctor body, the exact thing this PR changes).

Minor note (non‐blocking, description only): the PR body lists TrimmableTypeMapTypeManager.GetInvokerTypeCore: throws in the trimmable path under Changes, but that file isn't touched in this PR — the UnreachableException is pre‐existing on the base branch. Worth trimming from the description for accuracy.

Nice cleanup. 👍

Generated by Android PR Reviewer for #11971 · 238.5 AIC · ⌖ 26.1 AIC · ⊞ 6.8K
_{Comment /review to run again}

[github-actions]

🤖 💡 Testing — This is the crux of the change: the generated .ctor now calls the base ctor with arity 2/1 instead of 3/2. But TypeMapAssemblyGeneratorTests only assert that a .ctor exists by name (Assert.Contains (".ctor", methods)) and that ctorRefs.Count >= 2 — none of them decode the emitted .ctor body. A base-ctor arity/token mismatch here would sail past metadata inspection and only surface as an InvalidProgramException/TypeLoadException on the CoreCLR device legs. There's already precedent for body-level decoding (AssertCreateInstanceReturnsNull, and the JI-ctor signature decode), so consider asserting that the emitted .ctor invokes the base ctor with the expected arity for both the generic (concrete) and non-generic (interface/open-generic) paths. Not blocking — the device legs cover it at runtime.

Rule: Generator tests should validate emitted IL bodies, not just member presence

[simonrozsival]

Good call — addressed in e9647b2. Added Generate_ProxyCtor_ChainsToExpectedBaseConstructor, a [Theory] that decodes the emitted .ctor body and asserts it chains to the expected base ctor for all three paths:

• concrete class → generic JavaPeerProxy<T> base, arity 1 (string), no GetTypeFromHandle;
• interface → non-generic JavaPeerProxy base, arity 2 (string, Type), with a Type.GetTypeFromHandle call;
• open-generic → same non-generic base, arity 2.

It resolves the call token to the base-ctor MemberRef and decodes its signature arity (reusing ReadCallTokens/TypeNameSignatureDecoder), so an arity/token mismatch now fails in-suite instead of only on the device legs. 608/608 passing.