[TrimmableTypeMap] Fix trimmable manifest generation parity

[simonrozsival]

Summary

Ports the focused manifest generator parity fix from #11617 without bringing over the broader trimmable typemap/runtime work from that branch.

The trimmable typemap manifest generator is intended to produce the same manifest semantics as the legacy ManifestDocument path. This PR fixes several small parity gaps that showed up while comparing generated manifests:

• Match legacy enum serialization for component attributes:
  • include zero/default values such as launchMode="standard", documentLaunchMode="none", uiOptions="none", and windowSoftInputMode unspecified values
  • map ScreenOrientation.SensorPortrait using the legacy target-SDK-dependent spelling behavior
• Support all plural [IntentFilter] data properties (DataSchemes, DataHosts, DataPaths, DataPathPatterns, DataPathPrefixes, DataMimeTypes, DataPorts, DataPathSuffixes, and DataPathAdvancedPatterns) by emitting one <data> element per value, in the same order legacy IntentFilterAttribute.GetData emits them. The singular and plural emitters are driven from a single ordered table so their ordering cannot drift apart.
• Preserve type-level application manifest properties that were previously missed, including NetworkSecurityConfig and DirectBootAware.
• Mark generated runtime providers android:directBootAware="true" when the application element or any direct child component is directBootAware="true" (and never emit an explicit "false"), matching legacy startup-provider behavior.
• Default android:extractNativeLibs="true" for target SDK >= 23 when the application element does not already specify a value, while still honoring explicit template values.
• Fill android:minSdkVersion from $(SupportedOSPlatformVersion) when a template already contains <uses-sdk /> without a minSdk, matching legacy ManifestDocument behavior and avoiding manifest merger failures where the app is treated as minSdk 1.
• Decode string-array custom attribute values in the scanner so plural intent-filter data properties reach the generator in the expected shape.
• Fail loudly (rather than silently emitting a wrong manifest) when targetSdkVersion cannot be resolved to an integer, matching legacy ManifestDocument.

Validation

• dotnet test tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests.csproj --no-restore -v:minimal
• dotnet test src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/Xamarin.Android.Build.Tests.csproj --no-restore --filter Name~Bug12935 -v:minimal
• git diff --check

[Copilot]

Pull request overview

Ports manifest-generation parity fixes into the trimmable typemap manifest generator so generated AndroidManifest.xml matches legacy ManifestDocument behavior.

Changes:

• Extend enum/property mapping parity (e.g., activity ScreenOrientation, default enum values like LaunchMode=0, and other enum/value conversions).
• Add support for plural IntentFilter data list properties (e.g., DataSchemes, DataHosts, DataPaths, etc.) to emit multiple <data> elements.
• Align application-level attributes (directBootAware, networkSecurityConfig, extractNativeLibs) and relax a build-test assertion to be less brittle.

Show a summary per file

File	Description
tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/Generator/ManifestGeneratorTests.cs	Adds/extends tests for new parity behaviors (screenOrientation, plural intent-filter data lists, app/provider directBootAware, extractNativeLibs, networkSecurityConfig).
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/ManifestTest.cs	Relaxes error-count assertion to tolerate varying numbers of errors.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/AssemblyIndex.cs	Ensures IntentFilter named args that are string[] decode as string lists for downstream manifest emission.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Generator/PropertyMapper.cs	Adds new mapped properties and threads targetSdkVersion into enum conversion to match legacy behavior.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Generator/ManifestGenerator.cs	Uses targetSdkVersion for parity behaviors; propagates directBootAware and conditions extractNativeLibs.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Generator/ComponentElementBuilder.cs	Emits additional <data> elements for plural IntentFilter data-list properties.
src/Microsoft.Android.Sdk.TrimmableTypeMap/Generator/AndroidEnumConverter.cs	Adjusts enum-to-string conversion to include legacy defaults/edge values and targetSdk-specific screenOrientation mapping.

Copilot's findings

• Files reviewed: 7/7 changed files
• Comments generated: 1

[simonrozsival]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

🤖 Code Review: ⚠️ Needs Changes

Thanks for porting the manifest-generator parity fix from #11617 — the bulk of this is solid, well-targeted work. I found one parity divergence worth fixing plus two minor suggestions (all posted inline).

Findings

• ⚠️ 1 warning — Plural <data> element ordering in ComponentElementBuilder.AddIntentFilterDataElements diverges from the legacy IntentFilterAttribute.GetData order (and from this PR's own singular method), undercutting the byte-for-byte parity goal. The new Activity_IntentFilterPluralDataProperties test currently locks in the divergent order.
• 💡 2 suggestions — GetTargetSdkVersionValue doesn't resolve codename SDK ids the way legacy ManifestDocument does (and silently returns 0 instead of failing loudly); and a Bug12935 assertion was relaxed from an exact error count.

Verified correct (nice work)

• ✅ The sensorPortait spelling for targetSdkVersion < 16 is intentional legacy parity (bugzilla #12935), not a typo.
• ✅ The ScreenOrientation int→string remap now matches the real Android.Content.PM.ScreenOrientation values (SensorPortrait = 7, etc.) — the previous mapping was wrong, so this is a genuine fix.
• ✅ WindowSoftInputMode now always emits state|adjust (including the *Unspecified defaults), matching ManifestDocumentElement.
• ✅ extractNativeLibs (>= 23) and DirectBootAware (app attribute + direct child elements) match ManifestDocument exactly; computing DirectBootAware once and threading it through the providers is a clean improvement.
• ✅ Singular AddIntentFilterDataElement now correctly emits one <data> element per attribute.

CI

At review time the Azure DevOps build (38 checks) is still in progress with no failures; mergeable_state is blocked pending those checks. Worth confirming a green run after the ordering fix.

The only real blocker is the plural <data> ordering. Once that (and its test) is aligned with the legacy order, this should be good to go.

Generated by Android PR Reviewer for issue #11752 · 1.8K AIC · ⌖ 48.6 AIC · ⊞ 40K
_{Comment /review to run again}

[simonrozsival]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

Addressed

[github-actions]

🤖 Android PR Reviewer — re-review

No blocking issues found. (CI still running — not a formal LGTM until the pipeline is green.)

This is a re-review after the previous /review. I read the full changed files and verified the generated output against the legacy ManifestDocument / ManifestDocumentElement / IntentFilterAttribute.GetData implementations before reading the PR description.

Previously-raised items — all resolved ✅

• directBootAware propagation (526e6e8): DirectBootAware(app) now scans the <application> element and its direct children, and the provider only ever emits directBootAware="true" — matches ManifestDocument.DirectBootAware() / CreateMonoRuntimeProvider exactly, including attribute order. ✔
• Plural <data> ordering (4465b56): driving both the singular and plural emitters from one ordered (singular, plural, attribute) table restores legacy order (host, mimeType, path, pathPattern, pathPrefix, port, scheme, pathSuffix, pathAdvancedPattern), singular block before plural — matches IntentFilterAttribute.GetData. Good call collapsing the two methods to prevent drift. ✔
• Unresolvable targetSdkVersion (3a23cbb): now throws InvalidOperationException instead of silently using 0 and emitting a wrong manifest, matching legacy. The netstandard2.0 codename caveat is documented and, in practice, unobservable. ✔
• Bug12935 assertion: relaxed-with-comment is reasonable; the specific aapt2 codes (APT2259, APT2067) are still asserted, so a real regression is still caught. ✔

Parity spot-checks (all match legacy)

• ScreenOrientation 2–14 remap + the sensorPortait (sic) < 16 quirk — matches ManifestDocumentElement.cs:308. The old sensor=3 mapping was wrong; the new table is correct.
• Zero/default enum values (launchMode=standard, documentLaunchMode=none, uiOptions=none, stateUnspecified|adjustUnspecified) — match.
• extractNativeLibs gated on targetSdk >= 23 && (force || attr == null) — matches ManifestDocument.cs:451.
• TryGetStringArray → List<string> flows correctly into the IReadOnlyList<string> plural cast; ScreenOrientationToString binds to the new 2-arg PropertyMapping ctor while 1-arg converters keep the wrapper lambda — overload resolution is sound.

New suggestion (inline, non-blocking)

• 💡 Testing — the targetSdkVersion < 16 → "sensorPortait" branch (the whole point of the new targetSdkVersion plumbing) has no unit coverage. See the inline comment on ManifestGeneratorTests.cs.

CI

Azure DevOps builds (dotnet-android Linux/Mac/Windows) are in progress; license/cla passed; mergeable_state is blocked (pending CI + required review). Nothing here should block merge once the pipeline goes green.

Solid, well-scoped parity work with good regression tests. 👍

Generated by Android PR Reviewer for issue #11752 · 1.4K AIC · ⌖ 47.4 AIC · ⊞ 37.9K
_{Comment /review to run again}