[Android] Skip DisposeWindowScope on Destroying to prevent ObjectDisposedException

[praveenkumarkarunanithi]

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!

Root Cause

PR #30196 introduced unconditional disposal of the window service scope in Window.Destroying()via mauiContext?.DisposeWindowScope(). This conflicted with Android’s single-Activity architecture, where Window instances are reused across lifecycle events. When users navigated back and reopened the app, the disposed scope caused ObjectDisposedException in ContentPage.UpdateHideSoftInputOnTapped while resolving services from the disposed ServiceProviderEngineScope.

Description of Change

Added platform-specific handling in IWindow.Destroying() to align scope disposal with each platform’s window lifecycle.
On desktop platforms (Windows, macOS, iOS), windows are independently created and destroyed, so disposing the scope in Destroying() is correct.
On Android, Window instances are reused under the single-Activity model, and Destroying() represents temporary hiding rather than true destruction. Therefore, the scope must remain alive with the Application for the full app lifecycle.

Issues Fixed

Fixes #33187
Fixes #33597

Platforms Tested

• iOS
• Android
• Windows
• Mac

Note: Android-only fix via #if !ANDROID directive due to Android's single-Activity window reuse model. Other platforms' code unchanged, no testing required.

Test Coverage

Automated device test not feasible - testing Window.Destroying() requires full Android WindowHandler infrastructure (NavigationRootManager, LayoutInflater, Activity context) that cannot be mocked in unit/device tests.

Breaking PR

PR #30196

Screenshots

Before Fix	After Fix
BeforeFix.mov	AfterFix.mov

[kubaflo]

It still crashes for me when I open the host app for example, press the physical back button, and then reopen the app.

[Copilot]

Pull request overview

This PR adjusts the window-service-scope disposal behavior to avoid ObjectDisposedException crashes on Android when bringing the app back to the foreground, while preserving the leak fix for other platforms.

Changes:

• Wraps MauiContext.DisposeWindowScope() in IWindow.Destroying() with #if !ANDROID so that window scopes are still disposed on non-Android platforms.
• Leaves Android window scopes undisposed during Destroying() to account for the single-Activity model where windows are reused across lifecycle events, preventing disposal of still-needed scopes.

[praveenkumarkarunanithi]

It still crashes for me when I open the host app for example, press the physical back button, and then reopen the app.

@kubaflo I wasn’t able to reproduce the crash in the host app using the back button + reopen scenario. I tested this on multiple devices (Pixel 9, Pixel 4a, Nexus 5, all on API 36) and couldn’t observe the issue.

[kubaflo]

It still crashes for me when I open the host app for example, press the physical back button, and then reopen the app.

@kubaflo I wasn’t able to reproduce the crash in the host app using the back button + reopen scenario. I tested this on multiple devices (Pixel 9, Pixel 4a, Nexus 5, all on API 36) and couldn’t observe the issue.

Hmmm maybe try with API30?

Screen.Recording.2026-01-29.at.15.06.54.mov

[kubaflo]

@praveenkumarkarunanithi
it fails on API36 too :/

Screen.Recording.2026-01-29.at.15.37.36.mov

[PureWeen]

Description of Change

Added platform-specific handling in IWindow.Destroying() to align scope disposal with each platform’s window lifecycle. On desktop platforms (Windows, macOS, iOS), windows are independently created and destroyed, so disposing the scope in Destroying() is correct. On Android, Window instances are reused under the single-Activity model, and Destroying() represents temporary hiding rather than true destruction. Therefore, the scope must remain alive with the Application for the full app lifecycle.

I think we probably need a fix like this
#33353

@praveenkumarkarunanithi

What's the characterisitc here of "single-Activity"? is the Activity destroyed a new activity created? Why is Destroying being called it the "Activity" itself isn't being destroyed