[Xamarin.Android.Build.Tasks] Generate R8 JNI remapping tables - #12848

@dalexsoto Addressed the seven blockers in three follow-up commits: 17268577b2, 5de8cb03e2, and 5af7ebd677 (current head).

1. Linked framework identities: the scanner recognizes the facade and System.Private.CoreLib implementations for both TypeMapAttribute<T> and constructor System.Type. Lookalike rejection remains. Added facade/corelib/mixed-scope tests and an actual ILLink fixture that asserts both references were forwarded to corelib before passing the linked output to the producer. That fixture deliberately roots the metadata and uses --ignore-link-attributes; it proves forwarding/consumption, not an application trimming-policy decision.
2. Java universe selection: inspect the generic group before interpreting the key. Accept the emitted shared Java.Lang.Object universe and per-assembly __TypeMapAnchor universe; ignore unrelated groups. The regression includes the real TypeMap<JavaDictionary> CLR-key shape in both facade and implementation scopes.
3. Class-only retention: record the class access independently of fields/methods. Class-only marker fixtures now assert both forward and reverse XML entries and unchanged assembly bytes.
4. Unrelated method attributes: filter for supported JNI attribute names before decoding. Added valid EditorBrowsable(Never) and TypeConverter(typeof(...)) metadata; neither is decoded by the JNI scanner.
5. Field identity: preserve name-plus-type rows and deterministically emit both descriptor-distinct fields. Name-only lookup fails on differing targets, while name-only metadata retention keeps every descriptor variant. Reverse indexes and compatibility/reachability checks use the typed rows. Added parser, linked-metadata, final XML, and generated-native-table regressions; the two-field LLVM output compiles with llc.
6. NativeAOT phantom classes: bare names have identifier boundaries, and descriptors are matched as complete Lname; tokens. Nested/longer/suffix identifiers no longer retain a phantom parent. UTF-8, UTF-16, dotted names, Unicode, arrays, and truly retained ambiguous merges are covered. Independent review also exposed that real dehydration command bytes could masquerade as UTF-16 characters, so the reader now structurally reads tagged __dehydrated_data streams and evaluates their literal regions instead. Added ELF32/ELF64 command-framed tests, including 69 03 = ZeroFill(13) + PtrReloc(0), and malformed streams fail with XA4325. Member matching remains conservative.
7. XML ownership: require the same replacements root as MergeRemapXml, stage entries per document, and commit ownership only after a complete successful read. Rejected-root and malformed-document regressions assert the required forward mapping survives generation and merge. Valid identical/conflicting inputs retain their established behavior.

Validation:

• ./dotnet-local.sh build src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/Xamarin.Android.Build.Tests.csproj --no-restore -v:quiet — passed (existing unrelated warnings remain).
• Combined R8MappingTests, JniDescriptorTextTests, JniRemappingAssemblyScannerTests, GenerateR8JniRemappingTests, and GenerateJniRemappingNativeCodeTests, with ILLinkPath and ILLinkFrameworkDirectory supplied through runsettings — 141 passed, zero failed/skipped, including the real linked fixture and llc checks.
• dotnet test src/Microsoft.Android.Build.Tasks/Tests/Microsoft.Android.Build.Tasks.Tests/Microsoft.Android.Build.Tasks.Tests.csproj --no-restore -v:quiet — 67 passed.
• Final read-only review found no further issues after the dehydration correction.

This remains producer-only: no managed assembly rewriting, runtime table ABI changes, product policy, or pipeline wiring. Requesting another review; the consolidated changes-requested review has no individual unresolved inline threads to resolve.

@dalexsoto Fixed the remaining UTF-16 edge-identity blocker in 66e2e5f3f827b385bf1029a23d06a3cca6d5ed2a.

The matcher now uses complete UTF-16 byte sequences for both classes and members—no shortened leading/trailing-zero patterns. The dehydration decoder restores only bytes explicitly supplied by ZeroFill, preserves short zero runs inside code units, and no longer pads unknown relocation or stream boundaries with invented zeros. Long padding remains bounded; genuinely retained merged classes still intentionally suppress ambiguous reverse entries.

The new regression reproduced both Peer/PeeŲ and ĀPeer/ĠPeer aliases in all four raw/tagged ELF32/ELF64 cases before the fix. It now asserts exactly the surviving classes and their reverse mappings, then checks that phantom classes cannot produce method/field XA4325 conflicts. Additional ELF32/ELF64 cases reject a UTF-16 code unit cut off by an unknown relocation. Existing dehydration cases now use actual Copy/ZeroFill streams rather than untagged, truncated strings.

The Xamarin.Android.Build.Tasks/test-project build passed, and all 130 focused remapping tests passed with zero skips, including actual ILLink forwarding and LLVM/llc checks. Final read-only review completed. Normal follow-up push only; PR base and stack metadata are unchanged. Please re-review the new head.

@dalexsoto Addressed the remaining class-evidence blocker in 73e244be9501b6b995b09b963f3a7985c46778ce.

Class retention no longer scans arbitrary object/dehydration buffers. It uses:

• compiler __Str_ symbols to locate length-delimited frozen UTF-16 payloads, excluding sync blocks, method tables, length headers and terminators;
• explicitly marked ELF string sections for UTF-8 payloads;
• length-delimited NativeFormat keys, selected by the actual Java typemap group relocation.

For dehydrated strings, ELF32 REL/ELF64 RELA identify the hydration destination. Sparse Copy/ZeroFill ranges preserve virtual offsets and known bytes without treating relocations as characters. Each class pattern must match the payload’s actual encoding; UTF-16 matches must also start on a code-unit boundary. Member matching and genuinely ambiguous merged-class policy remain conservative and unchanged. The existing NativeFormat parser and group/name validators are source-shared with the modern tasks rather than duplicated.

The original counterexample regression failed for both ELF32/ELF64 before the fix. The final regressions isolate the 65-character 41 00 00 00 length-header case and UTF-16 U+0141 (41 01) case, assert exactly the survivor and its reverse entry, and verify that a phantom A cannot introduce conflicting method/field targets. Additional cases cover raw UTF-8 vs UTF-16, executable/untyped bytes, Java vs CLR native typemap groups, mixed frozen/typemap rodata, incomplete frozen payloads and empty strings.

Validation passed: the classic task/test-project build; all 142 focused remapping tests (zero skips), including real ILLink and LLVM/llc checks; and all 67 modern task tests after sharing the helpers. Final read-only review completed. No device/full SDK validation or actual ILC compilation was run for this follow-up. Normal push only; PR base and stack metadata unchanged. Please re-review the new head.

@dalexsoto Addressed the frozen-symbol collision in 055458709005b6558abdf4429dac678f77c77b20.

The reader now derives each compiler string prefix from the corresponding __FrozenSegmentStart symbol. A candidate must use that exact compilation-unit prefix, belong to the same section, and lie inside the frozen region after its sync block. Its length header and payload must also fit inside the region. An arbitrary __Str_ substring no longer selects the string reader.

The new fixture models _ZTV18App_N___Str_Helper with an EEType header followed by an unknown related-type relocation. Both ELF32 and ELF64 failed with XA4325 before the fix. They now succeed and retain the expected forward/reverse/member entries. A same-prefix fixture__Str_Helper outside the frozen segment is also ignored, exercising the region check rather than just rejecting the mangled MethodTable prefix.

Source inspection of MetadataManager.PrepareForDehydration also showed that hydration targets can be file-backed zero placeholders. The reader now prefers decoded hydration ranges over those placeholders. Positive marker and negative incomplete-string regressions cover both BSS and file-backed targets on ELF32/ELF64; genuinely incomplete compiler strings still fail closed.

The task/test-project build passed and all 148 focused remapping tests passed with zero skips, including real ILLink and LLVM/llc checks. Final read-only review completed. No actual ILC compilation or device/full SDK validation was run for this follow-up. Normal push only; PR base and stack metadata unchanged. Please re-review the new head.

@dalexsoto Addressed both latest findings in 5c7624fadba721346fb79574bd41c85aec72aa6a.

1. Bare class evidence must now occupy the complete identified literal. Primitive parameter/return/array tokens inside strings such as run.(I)V are not independent class names. Object-token evidence still requires its complete Lname; encoding, so genuine LI;, [LI;, and reference.(ILI;)V retain class I; a whole bare I literal also remains valid. The regression reproduced false XA4325 member conflicts on all four raw/dehydrated ELF32/ELF64 variants before the fix. It now verifies exactly Peer forward/reverse mappings and its intended method target, with absent I/V/B/Z/J mappings excluded.

2. The shared Java-group predicate now handles the canonical numeric assembly/type suffixes emitted by NativeAotNameMangler, including Mono_Android_0_Java_Lang_Object and _Owner_TypeMap_0___TypeMapAnchor. It validates _ZTV length framing and preserves exact Java-group structure rather than accepting arbitrary suffixes. NativeFormat key-only class tests cover shared/local collision identities on ELF32/ELF64. Both the producer and modern extractor continue to reject suffixed JavaDictionary/CLR universes, nonnumeric or noncanonical suffixes, and extra anchor names. The original four suffixed-group cases failed in both consumers before the fix.

Validation passed: the task/test-project build; all 166 focused producer/remapping tests with zero skips (including actual ILLink forwarding and LLVM/llc checks); and all 78 modern task tests. Final read-only review completed. These are executed repository fixtures plus compiler-source contract verification, not an actual ILC/device/full SDK run. I am not claiming CI is green or classifying the observed Dispose_Finalized failure as flaky.

Normal follow-up push only; PR base and stack metadata are unchanged. Please re-review the new head.