[Android] Fix for Label WordWrap width issue causing HorizontalOptions misalignment

[praveenkumarkarunanithi]

Root Cause

On Android, for Label controls with LineBreakMode="WordWrap" and multiple lines, GetDesiredSize() returns the full constraint width instead of the actual rendered text width. This causes extra trailing space and incorrect horizontal alignment when HorizontalLayoutAlignment is set to Start, Center, or End. Single-line and Fill alignment cases are unaffected.

Description of Change

Updated GetDesiredSize() in LabelHandler.Android.cs to calculate the actual content width for wrapped, multi-line labels with non-Fill alignment. The implementation determines the widest rendered line using layout.GetLineWidth(i) and uses that value (plus padding) as the desired width.

Issues Fixed

Fixes #31782
Fixes #27614

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Output Video

Before Issue Fix	After Issue Fix

[Copilot]

Pull request overview

This PR fixes an Android-specific Label rendering issue where multi-line labels with LineBreakMode="WordWrap" and non-Fill horizontal alignment incorrectly report the full constraint width instead of the actual rendered text width. This causes unnecessary trailing space and incorrect alignment. The fix updates GetDesiredSize() in LabelHandler.Android.cs to calculate and return the actual maximum line width for wrapped, multi-line labels.

Key changes:

• Override GetDesiredSize() in LabelHandler.Android.cs to compute actual text width by finding the widest line
• Add public API entry for the new override method
• Add UI test to verify the fix with automated assertions

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Core/src/PublicAPI/net-android/PublicAPI.Unshipped.txt	Adds public API entry for the new GetDesiredSize override in LabelHandler
src/Core/src/Handlers/Label/LabelHandler.Android.cs	Implements GetDesiredSize override to calculate actual width for multi-line wrapped labels
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31782.cs	Adds NUnit test to verify label width is narrower than container when end-aligned
src/Controls/tests/TestCases.HostApp/Issues/Issue31782.cs	Creates test page demonstrating the issue with wrapped label in fixed-width container
src/Controls/tests/TestCases.Android.Tests/snapshots/android/WordWrapLineBreakModeNoExtraSpace.png	Adds visual verification snapshot (binary PNG file)

[PureWeen]

/rebase

[PureWeen]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[PureWeen]

PR Review: #33281 - [Android] Fix for Label WordWrap width issue causing HorizontalOptions misalignment

Date: 2026-01-05 | Issue: #31782 | PR: #33281

✅ Final Recommendation: APPROVE

Phase	Status
Pre-Flight	✅ COMPLETE
🧪 Tests	✅ COMPLETE
🚦 Gate	✅ PASSED
🔍 Analysis	✅ COMPLETE
⚖️ Compare	✅ COMPLETE
🔬 Regression	✅ PASSED - No regression from reverted fix
📋 Report	✅ COMPLETE

---

📋 Issue Summary

Problem: On Android, Label controls with LineBreakMode="WordWrap" and multiple lines incorrectly report full constraint width instead of actual rendered text width in GetDesiredSize(). This causes:

• Extra trailing space on the label
• Incorrect horizontal alignment when HorizontalLayoutAlignment is set to Start, Center, or End

Steps to Reproduce:

1. Create a Label with LineBreakMode="WordWrap" and HorizontalOptions="End"
2. Place it in a fixed-width container (e.g., 300px Grid)
3. Run on Android - label fills full width with trailing space
4. Compare to Windows - label correctly sized to content

Platforms Affected:

• iOS
• Android
• Windows
• MacCatalyst

Key Issue Comments:

• Initial report thought it was WordWrap behavior, but clarified that HorizontalOptions.End should align the label to the right edge
• Windows renders correctly, Android does not - inconsistent cross-platform behavior

📁 Files Changed

File	Type	Changes
src/Core/src/Handlers/Label/LabelHandler.Android.cs	Fix	+30 lines
src/Core/src/PublicAPI/net-android/PublicAPI.Unshipped.txt	API	+1 line
src/Controls/tests/TestCases.HostApp/Issues/Issue31782.cs	Test	+34 lines
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31782.cs	Test	+25 lines
src/Controls/tests/TestCases.Android.Tests/snapshots/...	Snapshot	binary

💬 PR Discussion Summary

Key Comments:

• Copilot reviewer approved with overview of changes
• No inline code review comments from human reviewers yet

Reviewer Feedback:

• PR correctly identifies the root cause: Android TextView reports full available width instead of actual text width for wrapped multi-line labels

Disagreements to Investigate:

File:Line	Reviewer Says	Author Says	Status
None identified

Author Uncertainty:

• None expressed

🧪 Tests

Status: ✅ COMPLETE

• PR includes UI tests
• Tests reproduce the issue
• Tests follow naming convention (Issue31782)

Test Files:

• HostApp: src/Controls/tests/TestCases.HostApp/Issues/Issue31782.cs
• NUnit: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31782.cs

Test Logic:

• Creates 300px wide container with end-aligned label
• Asserts label width is less than container width minus 10px
• Before fix: Label width ≈ container width (fails)
• After fix: Label width < container width (passes)

🚦 Gate - Test Verification

Status: ✅ PASSED

• Tests PASS with fix
• Fix files reverted to main
• Tests FAIL without fix
• Fix files restored

Result: PASSED ✅ - Tests correctly detect the issue (fail without fix, pass with fix)

🔍 Analysis

Status: ✅ COMPLETE

• Reviewed pre-flight findings
• Researched git history for root cause
• Formed independent opinion on fix approach

Root Cause: Android's TextView.Layout reports the full constraint width when measuring wrapped multi-line text via getMeasuredWidth(). The base GetDesiredSize() uses this measurement, which is incorrect for non-Fill horizontal alignments where the label should shrink-wrap to the actual text content.

Why does Android behave this way?

• When text wraps, Android's TextView measures to fill available width (for text justification/alignment purposes)
• The Layout object stores the full constraint width, not the actual content width
• This is correct for Fill alignment but wrong for Start/Center/End where the view should size to content

Alternative Approaches Considered:

Alternative	Location	Why NOT to use
Fix in MauiTextView.OnMeasure	MauiTextView.cs	Would affect all measurements, not just alignment cases; more invasive change
Fix in layout system	ViewHandler	Too broad, this is TextView-specific behavior
Use StaticLayout for measurement	LabelHandler	More complex, creates extra objects; current approach reuses existing Layout
Check LineBreakMode explicitly	LabelHandler	Not needed - truncation modes force single line anyway
Fix in PlatformArrange	LabelHandler	Wrong place - size must be correct at measure time, not arrange time

My Approach: The PR's approach is correct and minimal. Overriding GetDesiredSize() to calculate actual max line width using Layout.GetLineWidth(i) is the right place for this fix because:

1. It only affects multi-line wrapped labels with non-Fill alignment
2. It uses Android's native Layout API to get accurate line widths
3. It correctly accounts for padding
4. It preserves original behavior for single-line and Fill-aligned labels
5. The guard clauses ensure truncation modes (which force single-line) are unaffected

⚖️ Compare

Status: ✅ COMPLETE

Approach	Test Result	Lines Changed	Complexity	Recommendation
PR's fix	✅ PASS	+30	Low	✅ Recommended
Alternative (MauiTextView)	N/A	~30	Medium	Not needed

Recommendation: The PR's fix is the correct approach:

1. Minimal change - Only affects the specific scenario (multi-line, non-Fill alignment)
2. Correct location - GetDesiredSize() override in handler is the right place
3. Uses native APIs - Layout.GetLineWidth() is the proper Android API
4. Good guard clauses - Only triggers when LineCount > 1 and HorizontalLayoutAlignment != Fill
5. Accounts for padding - Includes PaddingLeft + PaddingRight in calculation

🔬 Regression

Status: ✅ COMPLETE

Edge Cases Verified:

• Single-line labels (should be unaffected) - ✅ Guard clause: layout.LineCount > 1 ensures single-line labels skip this logic
• Labels with HorizontalLayoutAlignment.Fill (should be unaffected) - ✅ Guard clause: HorizontalLayoutAlignment != Fill ensures Fill-aligned labels skip this logic
• Labels with padding - ✅ Code adds PaddingLeft + PaddingRight to maxLineWidth before converting to device-independent pixels
• Labels with different font sizes - ✅ Layout.GetLineWidth(i) returns actual rendered width at current font size
• RTL text direction - ✅ GetLineWidth() returns absolute width, not affected by text direction; padding is symmetrically applied
• Labels in ScrollView or other containers - ✅ Fix operates at handler level, container type doesn't affect measurement logic

⚠️ DEEPER ANALYSIS - Potential Concerns Investigated:

1. LineBreakMode.TailTruncation with ellipsis - SAFE ✅

   • Looking at TextViewExtensions.SetLineBreakMode(), HeadTruncation, MiddleTruncation, and TailTruncation all force maxLines = 1 on Android
   • Since the fix only triggers when LineCount > 1, truncation modes are NOT affected
   • The fix only applies to WordWrap and CharacterWrap which allow multiple lines

2. What if Layout is null after text change? - SAFE ✅

   • The fix uses pattern matching: PlatformView?.Layout is Layout layout
   • If Layout is null (during rapid updates), the fix is safely skipped and original size returned

3. Performance concern - iterating all lines - MINOR ⚠️

   • For labels with many lines (e.g., 100+), this loop runs on every measure
   • However: GetLineWidth() is O(1) in Android's StaticLayout/DynamicLayout
   • Real impact: negligible for typical use cases

4. FormattedText with spans of different widths - SAFE ✅

   • Layout.GetLineWidth() accounts for spans with different fonts/sizes
   • It returns the actual rendered pixel width including all formatting

Code Safety Analysis:

1. Null safety: PlatformView?.Layout and is Layout layout pattern provide null safety
2. Zero width guard: if (maxLineWidth > 0) prevents division issues or invalid sizes
3. Only reduces width: if (actualWidth < size.Width) ensures we never increase size, only reduce when needed
4. Height preserved: Returns new Size(actualWidth, size.Height) keeping original height intact

Disagreements Investigated:

• None - no reviewer disagreements in PR discussion

Potential Regressions: ⚠️ HISTORICAL RISK IDENTIFIED - BUT TEST COVERAGE EXISTS

🚨 CRITICAL FINDING - Previous Similar Fix Was Reverted:

A very similar fix was attempted before and REVERTED:

• Issue Label not sized correctly on Android #27614: Same problem - "Label not sized correctly on Android"
• PR Fixed the Label not sized correctly on Android #28215: Fixed by overriding MauiTextView.OnMeasure() to use GetMaxLineWidth(Layout)
• PR Revert - Fixed the Label not sized correctly on Android  #30023: REVERTED because it caused Issue I1_Vertical_list_for_Multiple_Rows - Rotating the emulator would cause clipping on the description text. #29542 - text clipping in CollectionView when rotating device

Comparison of Reverted Fix vs Current PR:

Aspect	Reverted Fix (MauiTextView.OnMeasure)	PR #33281 (LabelHandler.GetDesiredSize)
Location	MauiTextView.OnMeasure	LabelHandler.GetDesiredSize
Scope	ALL MauiTextView measurements	Only Label handler
Guard	Only MeasureSpecMode.AtMost	LineCount > 1 AND HorizontalLayoutAlignment != Fill
Risk Level	Higher - affects all TextView	Lower - specific scenario only

Why This Fix MAY Be Safer:

1. Handler-level override instead of platform view level
2. Additional guard: HorizontalLayoutAlignment != Fill - BUT Issue29542 uses Start so it WILL be affected!
3. Guard: LineCount > 1 - Issue29542 uses MaxLines=3 so it WILL be affected!

✅ GOOD NEWS: Test Coverage Exists for the Regression Scenario!

Issue29542 test (src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue29542.cs) would be triggered by PR #33281:

• Uses LineBreakMode.TailTruncation with MaxLines = 3 (can have LineCount > 1)
• Uses HorizontalOptions.Start (HorizontalLayoutAlignment != Fill)
• Tests rotation + CollectionView scenario that caused the revert

This test SHOULD catch if PR #33281 causes the same regression.

Recommended Action:

• Run Issue29542 test on Android with PR [Android] Fix for Label WordWrap width issue causing HorizontalOptions misalignment  #33281 to verify no regression - ✅ PASSED!

Regression Test Result (2026-01-05):

Issue29542 (CollectionView + rotation): ✅ PASSED
- Labels maintain consistent width after device rotation
- No clipping observed
- PR #33281's fix does NOT cause the same regression as the reverted PR #28215

• Uses well-established Android Layout API (GetLineWidth)

Alternative Approaches Considered:

Alternative	Why NOT to use
Override in MauiTextView.OnMeasure()	Would affect ALL measurements, not just alignment cases; more invasive
Use StaticLayout for separate measurement	More complex, creates extra objects, already have Layout from TextView
Check LineBreakMode explicitly	Not needed - truncation modes force single line, guard clause handles it
Fix in PlatformArrange instead	Wrong place - size is already calculated by measure time

---

Final Recommendation: ✅ APPROVE

---

📚 Technical Background & Sources

Why This Fix Is Necessary (Android TextView Measurement Behavior)

The Core Problem: Android's TextView.getMeasuredWidth() returns the constraint width (the maximum available width passed to measure()), not the actual content width of the rendered text. This is by design in Android's measurement system.

Official Android Documentation

1. Layout.getLineWidth(int)

   "Gets the unsigned horizontal extent of the specified line, including leading margin indent, but excluding trailing whitespace."

   This is the official API for getting actual rendered line width - exactly what the PR uses.

2. View.getMeasuredWidth()

   "Return the raw measured width of this view. This is the result of the most recent call to measure(int, int)."

   For MeasureSpecMode.AT_MOST, this returns the constraint width, not content width.

How Native Android Developers Solve This

Native Android developers face the same issue. The standard solution is to override onMeasure() and use Layout.getLineWidth():

// Standard native Android pattern for content-width measurement
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    super.onMeasure(widthMeasureSpec, heightMeasureSpec);
    
    Layout layout = getLayout();
    if (layout != null && layout.getLineCount() > 1) {
        float maxWidth = 0;
        for (int i = 0; i < layout.getLineCount(); i++) {
            maxWidth = Math.max(maxWidth, layout.getLineWidth(i));
        }
        int width = (int) Math.ceil(maxWidth) + getPaddingLeft() + getPaddingRight();
        setMeasuredDimension(width, getMeasuredHeight());
    }
}

MAUI Codebase Precedent

The same technique is already used in MAUI's Graphics library:

GraphicsExtensions.cs:381-401

public static SizeF GetTextSizeAsSizeF(this StaticLayout target, bool hasBoundedWidth)
{
    // We need to know if the static layout was created with a bounded width, 
    // as this is what StaticLayout.Width returns.
    if (hasBoundedWidth)
        return new SizeF(target.Width, target.Height);

    float maxWidth = 0;
    int lineCount = target.LineCount;
    for (int i = 0; i < lineCount; i++)
    {
        float lineWidth = target.GetLineWidth(i);
        if (lineWidth > maxWidth)
            maxWidth = lineWidth;
    }
    return new SizeF(maxWidth, target.Height);
}

The comment explicitly states: "We need to know if the static layout was created with a bounded width, as this is what StaticLayout.Width returns."

Common Developer Resources

• Stack Overflow: "Android Paint.measureText() vs getTextBounds()"
• Stack Overflow: "How to get the width and height of an Android.widget.TextView"

Both discussions recommend using Layout.getLineWidth() for actual content width.

Android Source Code (AOSP)

TextView.java in AOSP shows that when MeasureSpec.AT_MOST is used, TextView measures using the constraint as the layout width, then reports that as measuredWidth.

---

Justification:

1. Tests validate the fix - Gate verification passed: tests fail without fix, pass with fix
2. Correct root cause identified - Android TextView reports full constraint width for wrapped multi-line text, causing misalignment
3. Minimal and targeted fix - Only 30 lines added, affects only the specific failing scenario
4. Good guard clauses - Fix only activates for multi-line labels with non-Fill alignment
5. Uses proper Android APIs - Layout.GetLineWidth() is the correct API for measuring actual line width
6. Accounts for edge cases - Handles padding, null checks, and only reduces width (never increases)
7. Historical risk MITIGATED - A previous similar fix (PR Fixed the Label not sized correctly on Android #28215) was reverted due to regression (Issue I1_Vertical_list_for_Multiple_Rows - Rotating the emulator would cause clipping on the description text. #29542), but Issue29542 test PASSES with PR [Android] Fix for Label WordWrap width issue causing HorizontalOptions misalignment  #33281 proving this approach is safer
8. Handler-level vs View-level - This fix operates at GetDesiredSize in the handler, not OnMeasure in the view, which avoids the regression