[Android] Fix for TimePicker Dialog doesn't update the layout when rotating the device with dialog open

[HarishwaranVijayakumar]

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, when opening a TimePicker and then rotating the device, the picker dialog doesn’t seem to redraw itself to match the new screen dimensions.

Root Cause of the issue

• TimePicker lacks orientation change detection entirely. When the device rotates while the dialog is open, TimePicker has no mechanism to dismiss and re-show the dialog with updated layout, unlike DatePicker which detects orientation changes and refreshes the dialog display.

Description of Change

• Added ConnectHandler and related event subscriptions (ViewAttachedToWindow/ViewDetachedFromWindow) to manage display info changes and cleanup when the view is attached or detached. This helps ensure the time picker dialog responds to device orientation changes and releases resources properly.

• Implemented OnMainDisplayInfoChanged to dismiss and recreate the time picker dialog with the current time when the device orientation changes, preserving user selection progress.

Issues Fixed

Fixes #31658

Reference

• DatePickerHandler

Tested the behaviour in the following platforms

• - Windows
• - Android
• - Mac
• - iOS

Output

Before	After
Screen.Recording.2025-10-08.at.4.50.08.pm.mov	Screen.Recording.2025-10-08.at.4.47.47.pm.mov

[dotnet-policy-service]

Hey there @@HarishwaranVijayakumar! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[jsuarezruiz]

Could include a test?

[HarishwaranVijayakumar]

Could include a test?

@jsuarezruiz, The fix involves OnMainDisplayInfoChanged, which is only triggered when the device is rotated. However, SetOrientationLandscape does not actually rotate the device, so OnMainDisplayInfoChanged is not triggered, and the test still fails.

[Copilot]

Pull Request Overview

This PR fixes an issue where the TimePicker dialog on Android doesn't update its layout when the device is rotated while the dialog is open. The solution adds orientation change detection to automatically dismiss and recreate the dialog with the correct dimensions.

Key Changes

• Added orientation change detection via DeviceDisplay.MainDisplayInfoChanged event subscription
• Implemented dialog recreation when orientation changes to preserve user input
• Added proper lifecycle management for event subscriptions and dialog cleanup

Reviewed Changes

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

File	Description
TimePickerHandler.Android.cs	Added orientation change handling, dialog lifecycle management, and proper event subscription cleanup
PublicAPI.Unshipped.txt	Added new public API entry for the ConnectHandler override method

[MauiBot]

⚠️ Merge Conflict Detected — This PR has merge conflicts with its target branch. Please rebase onto the target branch and resolve the conflicts.

[kubaflo]

Could you please resolve conflicts?

[MauiBot]

⚠️ Merge Conflict Detected — This PR has merge conflicts with its target branch. Please rebase onto the target branch and resolve the conflicts.

[kubaflo]

Could you please resolve conflicts?

[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 -- 31910

Or

• Run remotely in PowerShell:

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

[HarishwaranVijayakumar]

Could you please resolve conflicts?

Resolved the conflicts

[sheiksyedm]

/azp run maui-pr-uitests , maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[MauiBot]

🚦 Gate - Test Before and After Fix

📊 Expand Full Gate — 71cec95 · Address AI concern

---

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent:

@copilot write tests for this PR

The agent will analyze the issue, determine the appropriate test type (UI test, device test, unit test, or XAML test), and create tests that verify the fix.

---

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 71cec95 · Address AI concern

---

🔍 Pre-Flight — Context & Validation

---

Issue: #31658 - [Android] TimePicker Dialog doesn't update the layout when rotating the device with dialog open
PR: #31910 - [Android] Fix for TimePicker Dialog doesn't update the layout when rotating the device with dialog open
Author: HarishwaranVijayakumar (community, partner/syncfusion)
Platforms Affected: Android only
Files Changed: 1 implementation, 0 test

Prior Agent Review

A prior complete AI review exists (commit 6dd3810, April 2, 2026). Author updated PR on April 6, 2026 (commit 71cec95) with "Addressed the AI summary".

Changes since prior review:

• ✅ Removed redundant _currentHour/_currentMinute fields → now uses VirtualView?.Time directly
• ❌ Stale comment on ShowPickerDialog(TimeSpan? time) still NOT updated (line 146-148 still reads "Not useful until we have orientation changed events")
• ❌ No tests added

Key Findings

• TimePicker lacked orientation change detection on Android; dialog didn't redraw after device rotation when open
• PR mirrors DatePickerHandler.Android.cs: subscribes DeviceDisplay.MainDisplayInfoChanged via ViewAttachedToWindow/ViewDetachedFromWindow lifecycle events
• PR adds base.DisconnectHandler(platformView) which was previously missing — a genuine secondary bugfix
• PR defensively unsubscribes DismissEvent before programmatic Dismiss() on rotation, preventing spurious VirtualView.IsOpen = false during recreation (DatePickerHandler does not do this)
• The DisconnectHandler nulls ShowPicker/HidePicker AFTER calling OnViewDetachedFromWindow(), whereas DatePickerHandler nulls them BEFORE — minor ordering difference, not a bug
• Comment above void ShowPickerDialog(TimeSpan? time) still says "Not useful until we have orientation changed events" which is now stale
• PR reviewer @jsuarezruiz requested a test; author responded that SetOrientationLandscape doesn't physically trigger MainDisplayInfoChanged, making direct UI test difficult
• All prior inline review threads are resolved/outdated
• Gate: ⚠️ SKIPPED — no tests in this PR

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31910	Subscribe DeviceDisplay.MainDisplayInfoChanged via ViewAttachedToWindow/ViewDetachedFromWindow; unsubscribe DismissEvent before dismiss; use VirtualView?.Time; add base.DisconnectHandler	⏳ PENDING (Gate skipped)	TimePickerHandler.Android.cs	Mirrors DatePickerHandler; stale comment still present

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Mirror DatePickerHandler with ResetDialog() helper; let DismissEvent fire naturally (no defensive unsubscription)	⚠️ Blocked (build OK, no device for rotation test)	TimePickerHandler.Android.cs	Cleaner DRY structure; same pattern as DatePickerHandler
2	try-fix (claude-sonnet-4.6)	Lazy orientation check at ShowPickerDialog time using _dialogOrientation field; no event subscriptions	⚠️ Blocked (build OK, no device for rotation test)	TimePickerHandler.Android.cs	Pull-based; requires ShowPickerDialog call after rotation to trigger
3	try-fix (gpt-5.3-codex)	PR's fix + stale comment update only	⚠️ Blocked (build asset issue on --no-restore; logic sound)	TimePickerHandler.Android.cs	Minimal change; comment fix only
4	try-fix (gpt-5.4)	PR's fix + dedup guard in OnViewAttachedToWindow + stale comment update	⚠️ Blocked (build OK on net10.0-android36.0, no device for rotation test)	TimePickerHandler.Android.cs	Hardens against duplicate subscription if view re-attaches
PR	PR #31910	Subscribe DeviceDisplay.MainDisplayInfoChanged via ViewAttachedToWindow/ViewDetachedFromWindow; defensive DismissEvent unsubscription; use VirtualView?.Time; add base.DisconnectHandler	⏳ Pending (Gate skipped — no tests)	TimePickerHandler.Android.cs	Functionally correct; stale comment remains

Cross-Pollination

Model	Round	New Ideas?	Details
explore agent (all models)	2	Yes	DialogFragment approach: wrap TimePickerDialog in Android DialogFragment subclass to leverage native lifecycle management and automatic configuration-change handling. Out of scope for this targeted bugfix.
explore agent (all models)	2	No new actionable ideas	DialogFragment idea noted but is a major architectural change, not appropriate for this bug fix

Exhausted: Yes (4 models, cross-pollination complete)

Selected Fix: PR's current fix is functionally correct. Improvements from Attempt 4:

1. Add dedup guard in OnViewAttachedToWindow (unsubscribe before subscribe)
2. Fix stale comment on ShowPickerDialog(TimeSpan? time) — remove "Not useful until we have orientation changed events"

All try-fix attempts were Blocked due to lack of physical device for rotation testing. Build succeeds for all approaches.

---

📋 Report — Final Recommendation

---

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	1 file changed, Android-only, no tests; prior AI review found
Gate	⚠️ SKIPPED	No tests detected in PR
Try-Fix	✅ COMPLETE	4 attempts: all Blocked (build OK, no device for rotation test); 2 improvements identified
Report	✅ COMPLETE

Summary

PR #31910 fixes a genuine Android bug: TimePickerHandler had no orientation change detection. When the device rotated with the TimePicker dialog open, the dialog stayed at the prior orientation's dimensions. The PR's fix mirrors the identical pattern already in DatePickerHandler.Android.cs — subscribing to DeviceDisplay.MainDisplayInfoChanged via ViewAttachedToWindow/ViewDetachedFromWindow, then dismissing and recreating the dialog on orientation change.

The author has already addressed the major feedback from the prior AI review (removed redundant _currentHour/_currentMinute fields, now uses VirtualView?.Time directly). Two minor issues remain unaddressed. Try-Fix explored 4 independent alternatives; all blocked due to no physical device for rotation testing. Two improvements from Try-Fix were identified (dedup guard + stale comment).

Root Cause

TimePickerHandler.Android.cs did not listen for display/orientation changes. Unlike DatePickerHandler, which already handles this, TimePickerHandler had no mechanism to dismiss and recreate its dialog on rotation. The pre-existing comment in the code even acknowledged this gap: "Not useful until we have orientation changed events."

Fix Quality

Strengths:

• ✅ Correct approach — directly mirrors DatePickerHandler.Android.cs which has the identical pattern
• ✅ Adds base.DisconnectHandler(platformView) which was missing — fixes a secondary cleanup bug
• ✅ Properly manages event subscription lifecycle (attach/detach + disconnect)
• ✅ Defensive: unsubscribes DismissEvent before programmatic dismiss to prevent spurious VirtualView.IsOpen = false side-effects during recreation
• ✅ Author already addressed prior review feedback: removed redundant _currentHour/_currentMinute fields, uses VirtualView?.Time directly

Issues to Address:

1. Stale comment not updated — Lines 146–148 of TimePickerHandler.Android.cs still say:

   // This overload is here so we can pass in the current values from the dialog 
   // on an orientation change (so that orientation changes don't cause the user's date selection progress
   // to be lost). Not useful until we have orientation changed events.

   The phrase "Not useful until we have orientation changed events" is now false — this PR adds exactly those events. Update to remove the stale sentence, for example:

   // This overload is here so we can pass in the current values from the dialog
   // on an orientation change, so the user's time selection progress is preserved.

2. Potential duplicate event subscription — OnViewAttachedToWindow does DeviceDisplay.MainDisplayInfoChanged += OnMainDisplayInfoChanged without first unsubscribing. If the Android view is attached more than once without a balanced detach (e.g., view re-parenting), this creates duplicate subscriptions and OnMainDisplayInfoChanged fires multiple times per orientation change. DatePickerHandler has the same issue, but as an improvement, guard against it:

   void OnViewAttachedToWindow(object? sender = null, View.ViewAttachedToWindowEventArgs? e = null)
   {
       DeviceDisplay.MainDisplayInfoChanged -= OnMainDisplayInfoChanged;
       DeviceDisplay.MainDisplayInfoChanged += OnMainDisplayInfoChanged;
   }

3. No tests — Gate was skipped because no tests were added. The author explained that SetOrientationLandscape doesn't physically trigger MainDisplayInfoChanged, making a direct UI test difficult. Consider adding at least a unit/device test that manually invokes OnMainDisplayInfoChanged via reflection (or makes the method internal and calls it directly) to verify the dialog is dismissed and recreated when showing. This would give confidence the handler wiring works correctly.

Selected Fix: PR's fix with the 2 minor improvements above

• Fix stale comment (1 line change)
• Add dedup guard in OnViewAttachedToWindow (1 line addition)
• All other PR changes are correct as-is

---

[kubaflo]

Could you please check the AI's suggestions?

[HarishwaranVijayakumar]

Could you please check the AI's suggestions?

@kubaflo, Addressed the AI summary

[kubaflo]

Code Review — PR #31910

Independent Assessment

What this changes: Adds device orientation change handling to TimePickerHandler.Android.cs. When the device rotates while the TimePicker dialog is open, the dialog is dismissed and recreated with the current time values. Uses DeviceDisplay.MainDisplayInfoChanged subscribed via ViewAttachedToWindow/ViewDetachedFromWindow lifecycle. Also adds the missing base.DisconnectHandler() call.

Inferred motivation: The TimePicker dialog on Android doesn't resize when the device rotates while the dialog is showing, leaving a portrait-sized dialog in landscape mode (or vice versa). DatePicker already has this exact pattern.

Reconciliation with PR Narrative

Author claims: TimePicker lacks orientation change detection; fix mirrors DatePickerHandler's approach.

Agreement: The code change exactly mirrors the DatePickerHandler.Android.cs pattern. The root cause and fix approach are correct.

Findings

⚠️ Warning — DatePickerHandler.OnMainDisplayInfoChanged doesn't unsubscribe DismissEvent before Dismiss(); this PR does

The two handlers handle the dismiss-and-recreate slightly differently:

DatePickerHandler (line 237-246):

currentDialog.Dismiss();
ShowPickerDialog(currentDialog.DatePicker.DateTime);

This PR's TimePickerHandler:

_dialog.DismissEvent -= OnDialogDismiss;
_dialog.Dismiss();
_dialog = null;
ShowPickerDialog(VirtualView?.Time);

The PR's approach is actually better than DatePickerHandler's — it correctly unsubscribes DismissEvent before Dismiss() to prevent the dismiss event from triggering HidePickerDialog() which would set VirtualView.IsOpen = false and null out _dialog prematurely. The DatePickerHandler has this same latent issue but gets away with it because ShowPickerDialog has a guard against _dialog != null.

However, there's a subtle difference in how the current time is captured:

• DatePicker reads from the dialog itself (currentDialog.DatePicker.DateTime) — preserving user's in-progress selection
• TimePicker reads from VirtualView?.Time — which is the committed value, not the user's in-progress spinner selection

This means if a user spins the hour to "3" but hasn't confirmed, rotates the device, the dialog will reopen at the original time, losing their progress. The original ShowPickerDialog(TimeSpan?) comment on line 120-122 even mentions this: "so that orientation changes don't cause the user's date selection progress to be lost".

Unfortunately, Android's TimePickerDialog doesn't expose the current spinner values the way DatePickerDialog.DatePicker does, so there may not be an easy fix. Worth noting for awareness.

⚠️ Warning — Missing test

jsuarezruiz (maintainer) requested a test. The author responded that SetOrientationLandscape doesn't trigger OnMainDisplayInfoChanged in the test environment, making it untestable via standard UI tests. This is a legitimate limitation, but a device test verifying that the dialog subscription/unsubscription lifecycle works correctly (without rotation) would still add value.

✅ Correct — Adds missing base.DisconnectHandler(platformView)

The original code was missing the base.DisconnectHandler() call. This is a correctness fix — the base class needs to run its cleanup. This was noted in the review rules (§1: "Base class calls ordering — DisconnectHandler should clean up before calling base.DisconnectHandler()"). The PR correctly places it at the end after custom cleanup.

✅ Correct — ConnectHandler/DisconnectHandler symmetry

Registration and unregistration are symmetric:

• ConnectHandler: subscribes ViewAttachedToWindow + ViewDetachedFromWindow
• DisconnectHandler: unsubscribes both + calls OnViewDetachedFromWindow() to clean up MainDisplayInfoChanged

This follows the pattern in DatePickerHandler exactly and matches review rule §1 (ConnectHandler/DisconnectHandler symmetry).

✅ Correct — Attaches/detaches static event via view lifecycle

Using ViewAttachedToWindow/ViewDetachedFromWindow to manage the DeviceDisplay.MainDisplayInfoChanged subscription (a static event) prevents the handler from keeping the view alive via the static event delegate. This follows review rules §2 (memory management) and §6 (Android: register layout listeners in AttachedToWindow/DetachedFromWindow).

✅ Correct — Handles already-attached view in ConnectHandler

The if (platformView.IsAttachedToWindow) { OnViewAttachedToWindow(); } check ensures the subscription fires even if the view is already attached when ConnectHandler runs. Mirrors DatePickerHandler.

CI Status

• maui-pr: ❌ Failed — needs investigation (4h run time). The PR was last rebased a while ago and may have stale failures.
• Builds, integration tests: ✅ All pass
• Merge state: MERGEABLE but BLOCKED (likely due to CI failure + pending review)

Devil's Advocate

1. Could the MainDisplayInfoChanged event fire for non-rotation changes? Yes — display scale, resolution, or refresh rate changes would also trigger it. But the guard _dialog is not null && _dialog.IsShowing means it only acts when the dialog is visible. A DPI change with dialog open would still dismiss and recreate, which is arguably correct behavior (dialog may need relayout for new DPI).

2. Could double-subscription happen? If ViewAttachedToWindow fires twice without ViewDetachedFromWindow, we'd double-subscribe. However, OnViewDetachedFromWindow() uses -= which is a no-op if not subscribed, so the unsub in DisconnectHandler provides a safety net. The pattern matches DatePickerHandler which has been stable.

3. Thread safety of _dialog access? OnMainDisplayInfoChanged fires on the main thread (Android OrientationEventListener posts to main looper). ShowPickerDialog and _dialog access are also main-thread. No threading concern.

Verdict: LGTM with minor caveat

Confidence: high

Summary: Clean, well-structured Android fix that mirrors the existing DatePickerHandler pattern exactly. ConnectHandler/DisconnectHandler symmetry is correct, static event lifecycle is properly managed via view attach/detach, and the missing base.DisconnectHandler() is a bonus correctness fix. The one caveat is that user's in-progress time selection is lost on rotation (reads from VirtualView instead of dialog's current spinner state), but this is a platform limitation of Android's TimePickerDialog API. The maintainer-requested test is hard to write due to rotation not being triggerable in test environments. PR needs a rebase to resolve CI staleness.