[TrimmableTypeMap] Add coverage for XML custom-view precision roots
- Dominant language
- C#
- Stars
- 2.1k
- Forks
- 579
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 257
Description
Part of #10788.
## Problem
The trimmable TypeMap path currently has pieces of XML custom-view support, but we do not have targeted coverage for the future precision model where unused user ACWs can be trimmed while XML-referenced custom views remain rooted.
This is easy to mis-frame as "XML custom-view scanning is missing", but that is not accurate:
- #2129 added `ConvertCustomView` for second-pass layout custom-view fixup.
- #8954 wired `$(_CustomViewMapFile)` into the legacy `MarkJavaObjects` trimmer step so XML-only custom views are preserved.
- #10959 added trimmable `AcwMapWriter` support.
- #11015 wired `AcwMapWriter` into `GenerateTrimmableTypeMap` so trimmable builds populate `acw-map.txt`.
- #11036 kept `acw-map.txt` in the final trimmable build pipeline.
The remaining gap is test coverage and future precision: the production trimmable generator does not currently accept `CustomViewMapFile` or use layout-derived roots directly when deciding TypeMap entry unconditional vs conditional shape. This is not currently a correctness bug because `ModelBuilder.IsUnconditionalEntry()` treats all user-defined ACW classes as unconditional, and `ForceUnconditionalEntries = true` is broader still.
If we later narrow unconditional user-ACW rooting to recover more trimming wins, we must preserve the #8954 behavior by feeding layout custom-view roots into the trimmable TypeMap generator.
## Existing coverage
- `ConvertResourcesCasesTests` covers `ConvertResourcesCases` + `ConvertCustomView` at task level with layout XML custom view tags/fragments and `acwmap.txt`.
- `IncrementalBuildTest.ConvertCustomView(...)` covers the product build pipeline and incremental behavior for custom-view fixup.
- `AcwMapWriterTests` covers trimmable `acw-map.txt` format and scanned fixture output.
- Legacy `MarkJavaObjects` coverage exists for `$(_CustomViewMapFile)`-based preservation from #8954.
## Missing coverage
1. End-to-end trimmable build coverage for a custom view referenced only from XML.
2. A future precision-rooting test with:
- one custom view referenced only from layout XML;
- one unused user ACW not referenced anywhere;
- expected future behavior: XML custom view survives, unrelated unused user ACW can trim.
3. A generator/task-level test proving `customview-map.txt` affects trimmable TypeMap entry classification once broad user-ACW roots are narrowed.
4. R8/ProGuard evidence that Java wrappers remain consistent with managed trimming: no missing XML custom-view class and no unnecessary stale wrapper for an unused trimmed peer.
## Suggested test locations
- End-to-end trimmable build test: `src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/TrimmableTypeMapBuildTests.cs`
- Task-level `CustomViewMapFile` wiring: `src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/Tasks/GenerateTrimmableTypeMapTests.cs`
- Pure generator classification: `tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/Generator/TrimmableTypeMapGeneratorTests.cs` or a new focused generator test file
- Runtime/device inflation smoke test: only add later in `tests/MSBuildDeviceIntegration` or `tests/Mono.Android-Tests` if artifact-level coverage proves insufficient
## Acceptance criteria
- Add coverage proving the current trimmable path supports XML custom-view fixup with generated `acw-map.txt`.
- Add or stage coverage for the future precision model before relaxing broad user-ACW unconditional rooting.
- Document the distinction between implemented XML scanner/fixup support and the missing precision-root input to the trimmable generator.
- If implementing precision rooting, add `CustomViewMapFile` input to `GenerateTrimmableTypeMap` and mark layout-referenced peers unconditional while allowing unrelated user ACWs to become conditional.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.