[Android] Fix SwipeItem FontImageSource.Size being ignored

[Shalini-Ashokan]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Details

On Android, SwipeItem icons using FontImageSource ignore the Size property entirely. Icons always render at containerHeight / 2 (~50dp in a 100dp SwipeView), regardless of the specified FontImageSource.Size.

Root Cause

GetIconSize() in SwipeItemMenuItemHandler.Android.cs calculates icon size purely from container dimensions (Math.Min(contentHeight, contentWidth) / 2). The FontImageSource.Size property is never consulted. The drawable's intrinsic dimensions are only used for aspect ratio, not final size.

Description of Change

When the image source is IFontImageSource, the fix retrieves the font size via IFontManager.GetFontSize() and converts to pixels using TypedValue.ApplyDimension() (respecting both screen density and accessibility text scaling). The result is capped at maxIconSize (container / 2). Non-font image sources are unchanged.

Validated the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #34210

Output ScreenShot

Before	After

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34505

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34505"

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 8ac402e · committed the changes

---

🔍 Pre-Flight — Context & Validation

---

Issue: #34210 - [Android] SwipeItem ignores FontImageSource rendered size and always scales icons to container height, unlike iOS
PR: #34505 - [Android] Fix SwipeItem FontImageSource.Size being ignored
Platforms Affected: Android
Files Changed: 1 implementation, 2 test source files, 3 snapshot artifacts

Key Findings

• The linked issue is Android-only and reports that FontImageSource.Size is ignored for SwipeItem icons, producing icons sized to about half the swipe container instead of the requested size.
• The PR changes one Android handler file, adds a HostApp issue page and a shared UI test for Issue34210, and adds Android/iOS/Mac snapshot artifacts for screenshot validation.
• There are no inline review threads on the PR at this time, and the visible PR comments are bot/pipeline comments only.
• Issue comments highlight broader Android FontImageSource consistency concerns in other controls, but the PR scope here is limited to Android SwipeItem sizing.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34505	Use Android font services to derive a requested font icon size for IFontImageSource, cap it to the existing swipe-item max size, and keep non-font image sizing unchanged	⏳ PENDING (Gate)	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs, src/Controls/tests/TestCases.HostApp/Issues/Issue34210.cs, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs	Snapshot artifacts added for Android/iOS/Mac

Issue: #34210 - [Android] SwipeItem ignores FontImageSource rendered size and always scales icons to container height, unlike iOS
PR: #34505 - [Android] Fix SwipeItem FontImageSource.Size being ignored
Platforms Affected: Android
Files Changed: 1 implementation, 5 test

Key Findings

• The issue is Android-only: SwipeItem icons sourced from FontImageSource ignore the requested Size and render at roughly half the swipe container height.
• The PR updates src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs to use IFontManager.GetFontSize(...) and TypedValue.ApplyDimension(...) for font-backed icons, still capping to the existing container-derived maximum.
• The PR adds a HostApp repro page plus an Appium UI test (Issue34210) that opens the SwipeView programmatically and validates via screenshot on Android; Windows is compile-gated out because the swipe cannot be opened programmatically there.
• Snapshot baselines were added for Android, iOS, and Mac test suites even though the bug is Android-specific, which helps document visual parity after the fix.
• No prior agent review artifacts or inline review feedback were present on the PR.

Edge Cases / Notes From Discussion

• The issue discussion calls out related Android FontImageSource inconsistencies in other controls, but this PR scopes the fix to SwipeItem only.
• The fix intentionally preserves the existing max-size behavior so oversized requested font sizes should still be constrained by the swipe item container.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34505	Respect FontImageSource.Size on Android by converting the requested font size to pixels and clamping to the existing swipe-item maximum	⏳ PENDING (Gate)	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs, src/Controls/tests/TestCases.HostApp/Issues/Issue34210.cs, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs	Original PR

Issue: #34210 - [Android] SwipeItem ignores FontImageSource rendered size and always scales icons to container height, unlike iOS
PR: #34505 - [Android] Fix SwipeItem FontImageSource.Size being ignored
Platforms Affected: Android
Files Changed: 1 implementation, 2 test source files, 3 snapshot artifacts

Key Findings

• The linked issue is Android-only and reports that SwipeItem icons backed by FontImageSource ignore the requested Size and render at roughly half the swipe container height.
• The PR changes one Android handler file, adds a HostApp repro page plus a shared UI screenshot test for Issue34210, and adds Android/iOS/Mac snapshot baselines.
• The PR discussion is light; aside from bot output, the only current inline review feedback is a note about using deterministic non-null DisplayMetrics in the Android pixel conversion path.
• Issue discussion calls out similar Android FontImageSource inconsistencies in other controls, but this PR is intentionally scoped to Android SwipeItem sizing only.

Edge Cases / Notes From Discussion

• Oversized requested font sizes should still be clamped by the existing swipe-item container limit.
• The added UI test is compile-gated out on Windows because SwipeView cannot be opened programmatically there.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34505	Respect FontImageSource.Size for Android SwipeItem icons by converting the requested font size to pixels and clamping to the existing max icon size	⏳ PENDING (Gate)	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs, src/Controls/tests/TestCases.HostApp/Issues/Issue34210.cs, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs	Original PR; snapshot baselines added for Android/iOS/Mac

---

Issue: #34210 - [Android] SwipeItem ignores FontImageSource rendered size and always scales icons to container height, unlike iOS
PR: #34505 - [Android] Fix SwipeItem FontImageSource.Size being ignored
Platforms Affected: Android
Files Changed: 1 implementation, 2 test source files, 3 snapshot artifacts

Key Findings

• The linked issue is Android-only: SwipeItem icons backed by FontImageSource ignore the requested Size and instead render at approximately half the swipe container size.
• The PR changes one Android handler file, adds a HostApp repro page for Issue34210, adds a shared Appium screenshot test, and updates Android/iOS/Mac snapshot baselines.
• Issue discussion notes broader Android FontImageSource consistency problems in other controls, but this PR is scoped only to Android SwipeItem sizing.
• PR discussion currently includes one unresolved inline review thread on SwipeItemMenuItemHandler.Android.cs about using Context.Resources.DisplayMetrics deterministically rather than a nullable Resources?.DisplayMetrics path.
• A prior agent review exists on the PR and previously recommended requesting changes because Gate was inconclusive and it preferred a simpler alternative; this review reruns the workflow from Pre-Flight with the latest PR state after the author reported follow-up changes.

Edge Cases / Notes From Discussion

• The intended behavior is to respect the requested FontImageSource.Size while still clamping oversized icons to the existing swipe-item maximum.
• The issue body contrasts Android with iOS behavior, where small source images are not scaled up unnecessarily.
• The shared UI test is compile-gated out on Windows because SwipeView cannot be opened programmatically there; the scenario is Android-relevant.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34505	Respect FontImageSource.Size for Android SwipeItem icons by deriving a requested font icon size, converting it to pixels, and clamping it to the existing max icon size; add HostApp/UI test coverage and snapshot baselines	⏳ PENDING (Gate)	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs, src/Controls/tests/TestCases.HostApp/Issues/Issue34210.cs, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs	Original PR

---

🚦 Gate — Test Verification

---

Gate Result: ⚠️ SKIPPED

Platform: android
Mode: Full Verification

• Tests exist: ✅
• Tests FAIL without fix: ❌
• Tests PASS with fix: ❌

Notes

• The PR adds Issue34210 UI test coverage, but the verification run without the fix did not reach the issue page successfully; the task agent reported a fixture setup timeout while waiting for the host app navigation element.
• The verification rerun with the fix did not complete because the Android deployment step hit an ADB broken-pipe/device-connection failure.
• Because neither direction produced a trustworthy fail/pass signal for the issue-specific assertion, Gate is marked skipped due to environment/test-execution blockers rather than used as evidence for or against the PR.

Gate Result: ❌ FAILED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ❌
• Tests PASS with fix: ✅

Notes

• Verification was attempted with the verify-tests-fail-without-fix workflow for FullyQualifiedName~Issue34210 on Android.
• The verification report concluded the tests passed without the fix, so the added test did not prove it catches the regression.
• Raw logs also show an Android deployment/install error during the "without fix" run (ADB0010: Unexpected install output: cmd: Failure calling service package: Broken pipe (32)), so the result is not fully trustworthy.
• Because Gate did not demonstrate the expected FAIL-without-fix / PASS-with-fix behavior, this phase is treated as failed/inconclusive and Try-Fix proceeds per workflow.

Gate Result: ✅ PASSED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ✅
• Tests PASS with fix: ✅

Notes

• Verification was run via the repository's full verify-tests-fail-without-fix workflow for Issue34210 on Android.
• The verifier reported the expected two-way result: the test failed without the fix and passed with the fix.
• A transient ADB/install error occurred on an initial attempt during the without-fix leg, but the workflow retried and completed successfully with decisive pass/fail evidence.

---

Gate Result: ✅ PASSED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ✅
• Tests PASS with fix: ✅

Notes

• Verification was run through the isolated fail-without-fix workflow for Issue34210, and the generated verification-report.md concluded VERIFICATION PASSED for Android.
• The verifier established a broken baseline, observed the issue-specific test failing without the fix, then restored the PR state and observed the test passing with the fix.
• The captured report also contains an intermediate Android deployment/install retry failure (ADB0010: ... Broken pipe (32)), but the workflow continued and ended with a passing verification result and a final status of ✅ PASSED.
• Gate evidence is recorded under CustomAgentLogsTmp/PRState/34505/PRAgent/gate/verify-tests-fail/.

---

🔧 Fix — Analysis & Comparison

---

Gate Result: ⚠️ SKIPPED

Platform: android
Mode: Full Verification

• Tests exist: ✅
• Tests FAIL without fix: ❌
• Tests PASS with fix: ❌

Notes

• The PR adds Issue34210 UI test coverage, but the verification run without the fix did not reach the issue page successfully; the task agent reported a fixture setup timeout while waiting for the host app navigation element.
• The verification rerun with the fix did not complete because the Android deployment step hit an ADB broken-pipe/device-connection failure.
• Because neither direction produced a trustworthy fail/pass signal for the issue-specific assertion, Gate is marked skipped due to environment/test-execution blockers rather than used as evidence for or against the PR.

Gate Result: ❌ FAILED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ❌
• Tests PASS with fix: ✅

Notes

• Verification was attempted with the verify-tests-fail-without-fix workflow for FullyQualifiedName~Issue34210 on Android.
• The verification report concluded the tests passed without the fix, so the added test did not prove it catches the regression.
• Raw logs also show an Android deployment/install error during the "without fix" run (ADB0010: Unexpected install output: cmd: Failure calling service package: Broken pipe (32)), so the result is not fully trustworthy.
• Because Gate did not demonstrate the expected FAIL-without-fix / PASS-with-fix behavior, this phase is treated as failed/inconclusive and Try-Fix proceeds per workflow.

Gate Result: ✅ PASSED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ✅
• Tests PASS with fix: ✅

Notes

• Verification was run via the repository's full verify-tests-fail-without-fix workflow for Issue34210 on Android.
• The verifier reported the expected two-way result: the test failed without the fix and passed with the fix.
• A transient ADB/install error occurred on an initial attempt during the without-fix leg, but the workflow retried and completed successfully with decisive pass/fail evidence.

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Use FontImageSource.Font.Size directly and convert with Context.ToPixels() instead of IFontManager + TypedValue.ApplyDimension	✅ PASS	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Simplest passing alternative and avoids the nullable DisplayMetrics concern entirely, but it diverges from MAUI's existing Android FontImageSource sizing path
2	try-fix (claude-sonnet-4.6)	Treat the requested font size as Android sp and convert with TypedValue.ApplyDimension(Sp, ...), then clamp	✅ PASS	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Font-oriented and accessibility-aware, but it hard-codes sp semantics instead of following MAUI's existing font-size resolution path
3	try-fix (gpt-5.3-codex)	Use the generated drawable intrinsic bounds for FontImageSource and only downscale when exceeding the swipe-item max size	❌ FAIL	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Screenshot regression proved intrinsic drawable sizing alone does not match expected behavior
4	try-fix (gemini-3-pro-preview)	Keep explicit size conversion for FontImageSource, but clamp it against the full swipe-item container size instead of the historical half-size limit	✅ PASS	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Passes the current test, but relaxes the prior max-size policy more than the PR does
5	try-fix (claude-sonnet-4.6, cross-pollinated)	Measure actual glyph bounds with Android Paint/Typeface using resolved font size, then clamp the measured size to the existing half-size max	✅ PASS	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Rendering-based and robust, but much more complex than necessary
6	try-fix (claude-sonnet-4.6, cross-pollinated)	Generate the font drawable at the target icon size up front, then keep aspect-ratio clamping when applying bounds	✅ PASS	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Works, but touches much more code and still needs downstream bounds logic
PR	PR #34505	Respect FontImageSource.Size for Android SwipeItem icons by deriving a requested font size through IFontManager.GetFontSize(...), converting to pixels with TypedValue.ApplyDimension(...), and clamping to the existing max icon size	✅ PASSED (Gate)	src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs, src/Controls/tests/TestCases.HostApp/Issues/Issue34210.cs, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs	Original PR; matches FontImageSourceService.Android sizing behavior

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	1	No	NO NEW IDEAS
claude-sonnet-4.6	1	Yes	NEW IDEA: Measure glyph pixel bounds with Android Paint/Typeface instead of relying on direct size-unit conversion
gpt-5.3-codex	1	No	NO NEW IDEAS
gemini-3-pro-preview	1	No	NO NEW IDEAS
claude-sonnet-4.6	1.5	Executed	Extra attempt #5 ran the Paint/glyph-bounds idea and passed
claude-opus-4.6	2	No	NO NEW IDEAS
claude-sonnet-4.6	2	Yes	NEW IDEA: Pass the resolved pixel size into drawable creation instead of resizing only after generation
gpt-5.3-codex	2	No	NO NEW IDEAS
gemini-3-pro-preview	2	No	NO NEW IDEAS
claude-sonnet-4.6	2.5	Executed	Extra attempt #6 ran the size-aware drawable-generation idea and passed
claude-opus-4.6	3	No	NO NEW IDEAS
claude-sonnet-4.6	3	No	NO NEW IDEAS
gpt-5.3-codex	3	No	NO NEW IDEAS
gemini-3-pro-preview	3	No	NO NEW IDEAS

Exhausted: Yes
Selected Fix: PR #34505 — it passed Gate, preserves the existing swipe-item max-size policy, and matches the established Android FontImageSourceService pattern (IFontManager.GetFontSize + TypedValue.ApplyDimension) instead of introducing a divergent or more complex sizing path.

---

📋 Report — Final Recommendation

---

Gate Result: ⚠️ SKIPPED

Platform: android
Mode: Full Verification

• Tests exist: ✅
• Tests FAIL without fix: ❌
• Tests PASS with fix: ❌

Notes

• The PR adds Issue34210 UI test coverage, but the verification run without the fix did not reach the issue page successfully; the task agent reported a fixture setup timeout while waiting for the host app navigation element.
• The verification rerun with the fix did not complete because the Android deployment step hit an ADB broken-pipe/device-connection failure.
• Because neither direction produced a trustworthy fail/pass signal for the issue-specific assertion, Gate is marked skipped due to environment/test-execution blockers rather than used as evidence for or against the PR.

Gate Result: ❌ FAILED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ❌
• Tests PASS with fix: ✅

Notes

• Verification was attempted with the verify-tests-fail-without-fix workflow for FullyQualifiedName~Issue34210 on Android.
• The verification report concluded the tests passed without the fix, so the added test did not prove it catches the regression.
• Raw logs also show an Android deployment/install error during the "without fix" run (ADB0010: Unexpected install output: cmd: Failure calling service package: Broken pipe (32)), so the result is not fully trustworthy.
• Because Gate did not demonstrate the expected FAIL-without-fix / PASS-with-fix behavior, this phase is treated as failed/inconclusive and Try-Fix proceeds per workflow.

Gate Result: ✅ PASSED

Platform: android
Mode: Full Verification

• Tests FAIL without fix: ✅
• Tests PASS with fix: ✅

Notes

• Verification was run via the repository's full verify-tests-fail-without-fix workflow for Issue34210 on Android.
• The verifier reported the expected two-way result: the test failed without the fix and passed with the fix.
• A transient ADB/install error occurred on an initial attempt during the without-fix leg, but the workflow retried and completed successfully with decisive pass/fail evidence.

---

✅ Final Recommendation: APPROVE

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Android-only SwipeItem sizing bug; PR adds one Android handler change, one HostApp repro page, one shared UI test, and snapshot baselines
Gate	✅ PASSED	Android full verification reported FAIL without fix and PASS with fix for Issue34210
Try-Fix	✅ COMPLETE	6 attempts total, 5 passing; PR fix selected as best overall
Report	✅ COMPLETE

Summary

This PR fixes the right bug in the right place and now has a verified regression test path on Android. The mandatory try-fix exploration found several passing alternatives, but none beat the PR overall: the PR preserves the existing swipe-item sizing policy, stays close to the current Android font-image implementation pattern, and avoids the extra complexity of paint-based or drawable-generation alternatives.

Root Cause

SwipeItemMenuItemHandler.Android.GetIconSize() previously sized all icons from the swipe container dimensions alone, so FontImageSource.Size was ignored and Android font icons rendered much larger than requested.

Fix Quality

The implementation is targeted and consistent with existing Android FontImageSource code in the repository. In particular, using IFontManager.GetFontSize(...) and TypedValue.ApplyDimension(...) matches FontImageSourceService.Android, which is a better fit than the simpler but more divergent direct Context.ToPixels() alternative. The new HostApp/UI test coverage also gives the fix a concrete regression check.

Notes

• There is still an open inline comment questioning the nullable Resources?.DisplayMetrics argument, but this PR matches the same nullable pattern already used in FontImageSourceService.Android, so I do not consider that a blocking issue in this codebase.
• I observed one unrelated dirty worktree file during the review (src/Core/src/Handlers/HybridWebView/HybridWebView.js) and intentionally left it untouched.

---

📋 Expand PR Finalization Review

PR #34505 Finalization Review

✅ Title: Keep current title

Current: [Android] Fix SwipeItem FontImageSource.Size being ignored

The title is specific, searchable, platform-scoped, and accurately reflects the implementation.

🟡 Description: Keep the existing structure, but correct two metadata details

What works well:

• The Android-specific root cause is clearly explained.
• The Description of Change matches the code change in SwipeItemMenuItemHandler.Android.cs.
• The NOTE block content and Fixes #34210 link are already present.
• The description explains the capping behavior for non-font image sources remaining unchanged.

Recommended edits:

1. Add the required template comment line above the NOTE block:
   <!-- Please let the below note in for people that find this PR -->
2. Correct the validation section. The PR currently marks Windows as validated, but the new UI test is excluded on Windows via #if TEST_FAILS_ON_WINDOWS, and the PR only adds Android/iOS/Mac screenshot baselines.

Suggested wording for validation section:

• Keep Android checked.
• Keep iOS and Mac checked only if those screenshots were intentionally regenerated and reviewed.
• Uncheck Windows, or explicitly say Windows CI/build passed but this UI scenario was not validated there.

🟡 Commit messages: Minor quality note

Current commit headlines are generic:

• committed the test case
• fixed the font image size issue
• Modified the test case
• Added snapshots

This is not blocking because the PR title is already suitable for a squash-merge commit headline.

Code Review Findings

✅ Looks good

The Android implementation is targeted and consistent with existing font-sizing patterns:

• IFontManager.GetFontSize(...) is used instead of reading raw Font.Size directly.
• The Android unit from FontManager (sp vs dip) is preserved.
• TypedValue.ApplyDimension(...) matches the existing FontImageSourceService.Android.cs conversion pattern.
• The final icon size is still capped to the existing swipe-item maximum.
• Non-font image sources keep the prior behavior.

The regression coverage also lines up with the change:

• Adds a HostApp repro page for issue #34210.
• Adds a shared UI screenshot test.
• Adds screenshot baselines for Android, iOS, and Mac.

🟡 Review finding: Windows validation claim does not match the evidence

• Files involved: PR description, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs
• Problem: The PR body says the behavior was validated on Windows, but the test is compiled out on Windows and there is no Windows snapshot added in this PR.
• Recommendation: Update the PR description to remove or clarify the Windows validation claim.

Overall Assessment

✅ Ready from a code-quality standpoint, with one recommended PR description correction and one template-formatting addition.

I did not find a blocking implementation issue in the Android handler change. The main follow-up is to align the PR description with the actual validation evidence.

Additional Context

• Issue: #34210 is Android-specific.
• Status checks: maui-pr and related checks are green.
• Review recommendation: REVIEW_REQUIRED only because the PR metadata should be corrected before merge documentation is finalized.

[Shalini-Ashokan]

I addressed all the AI review concerns.

[Copilot]

Pull request overview

This PR fixes an Android-specific SwipeView rendering inconsistency where SwipeItem icons backed by FontImageSource ignored the configured size and were always scaled to half the swipe item container size.

Changes:

• Update Android SwipeItemMenuItemHandler icon sizing to respect FontImageSource’s configured font size (capped to the existing max icon size behavior).
• Add a HostApp repro page and a cross-platform UI test with screenshot baselines to prevent regressions.

Reviewed changes

Copilot reviewed 3 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Core/src/Handlers/SwipeItemMenuItem/SwipeItemMenuItemHandler.Android.cs	Uses IFontManager.GetFontSize + TypedValue.ApplyDimension for IFontImageSource to compute icon size instead of container-only sizing.
src/Controls/tests/TestCases.HostApp/Issues/Issue34210.cs	Adds a minimal repro page that programmatically opens a SwipeView with a FontImageSource icon.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34210.cs	Adds a screenshot-based UI test that opens the SwipeView and verifies rendering.
src/Controls/tests/TestCases.Android.Tests/snapshots/android/SwipeItemFontImageSourceSizeIsRespected.png	Android screenshot baseline for the new UI test.
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/SwipeItemFontImageSourceSizeIsRespected.png	iOS screenshot baseline for the new UI test.
src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/SwipeItemFontImageSourceSizeIsRespected.png	Mac screenshot baseline for the new UI test.