Remove all usage of .NET MAUI internal APIs

[jfversluis]

Description of Change

.NET MAUI is removing the InternalsVisibleTo grants it currently gives this repo — dotnet/maui#34070. This PR removes every place where the Toolkit reaches into a MAUI internal API, so we no longer depend on that grant.

I verified dotnet/maui#34070 against Toolkit 15.0.0 end to end (99-page sample walk on Android + Mac Catalyst, plus a signature-accurate IL scan of the shipped 15.0.0 binaries against the MAUI assemblies produced by that PR). That produced a definitive list of 6 internal APIs we still use. This PR removes all 6.

What was still using MAUI internals

#	MAUI internal API	Call site	Affected targets
1	Microsoft.Maui.ApplicationModel.IntermediateActivity (internal type)	FileSaverImplementation.android.cs, FolderPickerImplementation.android.cs	Android
2	Microsoft.Maui.Platform.ElementExtensions.ToPlatform(IElement) (1-arg internal overload)	Snackbar.android.cs → TryGetPageActiveModalPage	Android
3	Microsoft.Maui.Platform.ViewExtensions.GetParentOfType<T>	TouchBehavior.android.cs → OnAttachedTo	Android
4	Microsoft.Maui.JavaObjectExtensions.IsAlive	TouchBehavior.android.cs → UpdateClickHandler	Android
5	Microsoft.Maui.JavaObjectExtensions.IsDisposed	Snackbar.android.cs → DismissPlatform	Android
6	Microsoft.Maui.Controls.DispatcherExtensions.DispatchIfRequiredAsync	UserStoppedTypingBehavior.shared.cs	All targets — Android, iOS, Mac Catalyst, Windows, net10.0

Good news: iOS, Mac Catalyst and Windows had no platform-specific internal usage at all. The only thing hitting them was #6.

How each one is fixed

#1 — IntermediateActivity → Toolkit-owned ActivityResultManager

New src/CommunityToolkit.Maui.Core/Essentials/ActivityResultManager.android.cs, built on AndroidX ActivityResultRegistry:

launcher = activity.ActivityResultRegistry.Register(key, new ActivityResultContracts.StartActivityForResult(), callback);
launcher.Launch(intent);

The three-argument Register overload deliberately takes no ILifecycleOwner, so unlike RegisterForActivityResult it has no "must be called before STARTED" restriction and can be used on demand — which is exactly what an on-demand picker needs. It also needs no manifest entry and no onSaveInstanceState plumbing, so it is a lot less machinery than the activity it replaces.

Result semantics are a deliberate 1:1 match with MAUI's IntermediateActivity:

• Result.Canceled → TrySetCanceled() (so callers still see TaskCanceledException)
• anything else → data ??= new Intent(), invoke onResult, TrySetResult

The launcher is unregistered and disposed as soon as the result arrives, and also if Launch throws.

#2 — ToPlatform → Handler.PlatformView

if (Application.Current?.Windows[0].Page is Page mainPage
    && mainPage.Navigation.ModalStack.Count > 0
    && mainPage.Navigation.ModalStack.Last().Handler?.PlatformView is View platformModalPage)

Slight behaviour improvement: if the modal page has no platform view yet, we now return false and GetParentView() falls back to the activity content view, instead of ToPlatform() throwing.

#3/#4/#5 — Toolkit-owned Android helpers

New src/CommunityToolkit.Maui/Extensions/PlatformViewExtensions.android.cs with FindParentOfType<T>, IsPeerAlive and IsPeerDisposed. FindParentOfType<T> keeps MAUI's semantics (returns the view itself when it already matches, then walks up the parent chain).

Important

The names deliberately differ from MAUI's. The toolkit has to compile against two different MAUI worlds: shipped .NET 10 MAUI, where the InternalsVisibleTo grants are still present and MAUI's internal extension methods are therefore bindable, and .NET 11 MAUI, where they're gone. Naming ours identically makes every call site CS0121 ambiguous in the first world — which is exactly how CI failed on the first push here. The reasoning is captured in the <remarks> on the new file so it doesn't get "tidied up" later.

#6 — DispatchIfRequiredAsync (this is the sneaky one)

We already ship CommunityToolkit.Maui.Core.Extensions.DispatcherExtensions.DispatchIfRequiredAsync(IDispatcher, Action, CancellationToken = default), and UserStoppedTypingBehavior already had using CommunityToolkit.Maui.Core.Extensions;. But MAUI's internal overload is (IDispatcher?, Action) — exactly two parameters — so C# overload resolution prefers MAUI's over ours, because ours needs an optional argument filled in.

The result is that this one is invisible in a source build: recompiling just silently rebinds to our own method and everything looks fine. But shipped 15.0.0 binaries carry a memberref to MAUI's internal method, so they throw MethodAccessException at JIT time once the IVT grant is gone. It is now called explicitly through our own class so the binding can't drift again:

await ToolkitDispatcherExtensions.DispatchIfRequiredAsync(Dispatcher, view.Unfocus);

Verification

Everything below was run against a private MAUI build produced by dotnet/maui#34070 — i.e. with the InternalsVisibleTo grants actually removed.

Compile — clean on every target that can be built on macOS:

TFM	Result
net11.0-android	✅ Build succeeded
net11.0-ios	✅ Build succeeded
net11.0-maccatalyst	✅ Build succeeded
net11.0	✅ Build succeeded

Also re-run with this repo's real .editorconfig and WarningsAsErrors restored (my harness had them relaxed): zero diagnostics from any of the changed files.

IL scan — I wrote a Mono.Cecil-based analyzer that resolves every memberref/typeref/fieldref by full signature (name-only matching is exactly why the 1-arg ToPlatform overload is easy to miss) and reports unresolved references separately so a missing reference assembly can't be mistaken for a clean result. Scanned the rebuilt assemblies against MAUI reference assemblies for all five platforms:

Platform	Before	After
Android	6 findings	✅ 0 findings, 0 unresolved
iOS	1 finding	✅ 0 findings, 0 unresolved
Mac Catalyst	1 finding	✅ 0 findings, 0 unresolved
Windows	1 finding	✅ 0 findings, 0 unresolved
net10.0 (shared)	1 finding	✅ 0 findings, 0 unresolved

Windows can't be compiled on macOS, so it is covered by the IL scan only — but its single finding was #6, which lives in shared code, and the shared assembly now scans clean. The scan also covers CommunityToolkit.Maui.Camera, .Maps and .MediaElement: all clean.

Runtime — sample app, automated walk over all 99 pages:

Platform	Result
Android (Pixel 9 Pro emulator, API 36)	97 OK, 0 MethodAccess/FieldAccess/TypeAccess failures
Mac Catalyst	94 OK, 5 pre-existing failures, 0 MethodAccess/FieldAccess/TypeAccess failures

Both match the pre-PR baseline exactly. The 5 Mac Catalyst failures are pre-existing and unrelated (StatusBarBehaviorPage NotSupportedException by design, IsInRangeConverterPage invalid getter, StateContainerPage invalid cast, and two MediaElement media-load timeouts).

Because a page walk only navigates, I also drove the affected features directly — this matters most for ActivityResultManager, which the walk would never have exercised:

Scenario	Result
FolderPicker — cancel (Back out of SAF)	✅ TaskCanceledException, matching IntermediateActivity
FolderPicker — pick a folder	✅ success=True path=/storage/emulated/0/Documents
FileSaver — save a file	✅ success=True, file present on disk with correct contents
Snackbar show + dismiss	✅ Android + Mac Catalyst
Snackbar over a pushed modal page (the ToPlatform path)	✅ Android + Mac Catalyst
TouchBehavior attach (FindParentOfType + IsPeerAlive)	✅ TouchBehaviorPage, TouchBehaviorCollectionViewMultipleSelectionPage
UserStoppedTypingBehavior (DispatchIfRequiredAsync)	✅ command fired, Android + Mac Catalyst
FolderPicker — caller's CancellationToken fires while the picker is on screen	✅ completes as TaskCanceledException at the cancel instant, launcher unregistered

CI

Build Library passes on both macOS and Windows, as does Build Sample App (macos-26).

Build Sample App (windows-latest) fails with PRI175/PRI277 (Conflicting values for resource 'Files/Microsoft.Maui/Platform/Windows/Styles/Resources.xbf') — a WinAppSDK duplicate-resource problem in the sample app, not the library. It reproduces byte-identically on main (run 30027765216). Pre-existing, not caused by this PR.

Unrelated heads-up

Building against the .NET 11 SDK surfaces pre-existing CA2016 errors in FadeAnimation.shared.cs and GestureManager.shared.cs (CancellationToken not forwarded). Untouched by this PR and nothing to do with internal APIs, but they'll need fixing before this repo moves to .NET 11.

CommunityToolkit.Maui.Markup

Worth flagging separately: Markup 7.0.1 has 45 references to MAUI internals and hard-crashes on startup once the grant is removed. 8.0.0 is already clean — no action needed here, but anyone on 7.0.1 must upgrade.

Linked Issues

• Remove InternalsVisibleTo attributes for .NET MAUI Community Toolkit dotnet/maui#34070

PR Checklist

• Has tests (if omitted, state reason in description) — no new public API, so no new unit tests; verified by full-sample runtime walks on Android and Mac Catalyst plus targeted feature probes, as above
• Has samples (if omitted, state reason in description) — existing sample pages cover every changed feature
• Rebased on top of main at time of PR
• Changes adhere to coding standard
• Consolidate commits as makes sense

cc @TheCodeTraveler @PureWeen @kubaflo

[Copilot]

Pull request overview

This PR removes remaining dependencies on .NET MAUI internal APIs in the CommunityToolkit, ensuring the Toolkit continues to function once MAUI removes its InternalsVisibleTo grants.

Changes:

• Introduces a Toolkit-owned Android ActivityResultManager based on AndroidX ActivityResultRegistry, replacing MAUI’s internal IntermediateActivity for FolderPicker/FileSaver.
• Replaces internal MAUI Android helpers (GetParentOfType, IsAlive, IsDisposed) with Toolkit-owned equivalents in PlatformViewExtensions.android.cs, and updates Android call sites.
• Prevents accidental binding to MAUI’s internal DispatcherExtensions.DispatchIfRequiredAsync by calling the Toolkit dispatcher extension explicitly from UserStoppedTypingBehavior.

Show a summary per file

File	Description
src/CommunityToolkit.Maui/Extensions/PlatformViewExtensions.android.cs	Adds Toolkit-owned Android helper extensions replacing prior MAUI internal helpers.
src/CommunityToolkit.Maui/Behaviors/UserStoppedTypingBehavior.shared.cs	Forces binding to Toolkit dispatcher extensions to avoid MAUI internal overload resolution.
src/CommunityToolkit.Maui/Behaviors/PlatformBehaviors/Touch/TouchBehavior.android.cs	Switches TouchBehavior to use Toolkit-owned Android helper extensions.
src/CommunityToolkit.Maui/Alerts/Snackbar/Snackbar.android.cs	Replaces internal ToPlatform(IElement) path with Handler.PlatformView for modal-page retrieval.
src/CommunityToolkit.Maui.Core/Essentials/FolderPicker/FolderPickerImplementation.android.cs	Routes folder picking through ActivityResultManager instead of MAUI IntermediateActivity.
src/CommunityToolkit.Maui.Core/Essentials/FileSaver/FileSaverImplementation.android.cs	Routes file saving through ActivityResultManager instead of MAUI IntermediateActivity.
src/CommunityToolkit.Maui.Core/Essentials/ActivityResultManager.android.cs	Adds new AndroidX-based activity-result implementation to replace MAUI internal infrastructure.

Review details

• Files reviewed: 7/7 changed files
• Comments generated: 1
• Review effort level: Low

[jfversluis]

CI is green (except one pre-existing failure) + full re-verification after 55cc80c5

What broke, and why my local verification missed it

The first CI run failed all four build jobs with the same three errors:

CS0121: The call is ambiguous between 'CommunityToolkit.Maui.Extensions.PlatformViewExtensions.GetParentOfType<T>(View)'
        and 'Microsoft.Maui.Platform.ViewExtensions.GetParentOfType<T>(View)'

…and the same for IsAlive and IsDisposed.

Root cause: the toolkit has to compile against two different MAUI worlds at once.

	MAUI internals visible?	Consequence
.NET 10 MAUI (shipped — what CI builds against)	Yes, the InternalsVisibleTo grants are still there	MAUI's internal extension methods are bindable, so anything I name identically is ambiguous
.NET 11 MAUI (dotnet/maui#34070)	No, grants removed	Only the toolkit's own helpers are visible

I'd verified against the IVT-removed build only, so the collision was invisible to me. Fixed by giving the toolkit-owned helpers names that can't collide in either world:

Was	Now
GetParentOfType<T>	FindParentOfType<T>
IsAlive	IsPeerAlive
IsDisposed	IsPeerDisposed

The reason for the deliberate naming is documented in the <remarks> on PlatformViewExtensions.android.cs so it doesn't get "tidied up" later. I now build both worlds as a gate on every change.

Review feedback

Copilot's comment about StartAsync leaking the launcher on caller cancellation was valid and is fixed — details in the thread. StartAsync now takes a CancellationToken, releases the launcher exactly once (Interlocked.Exchange, marshalled via RunOnUiThread), and both call sites pass their token through instead of .WaitAsync(...).

CI

Job	Result
Build Library (macos-26)	✅ pass
Build Library (windows-latest)	✅ pass
Build Sample App (macos-26)	✅ pass
Build Sample App (windows-latest)	❌ pre-existing

The Windows sample-app failure is PRI175 / PRI277 (Conflicting values for resource 'Files/Microsoft.Maui/Platform/Windows/Styles/Resources.xbf') — a WinAppSDK duplicate-resource issue in the sample, not the library. It reproduces byte-identically on main (run 30027765216), where Build Library (windows-latest) also passes. Not caused by this PR.

Re-verification after the fix

Everything below was re-run from scratch on commit 55cc80c5.

Static — IL scan (Mono.Cecil, resolves every memberref by full signature) against MAUI with the IVT grants actually removed:

Target	Findings
Android (android-arm64)	0
Mac Catalyst	0
iOS	0
Windows	0
net11.0 shared	0
Android built with IVT present (the shipping config)	0

Runtime — automated walk over all 99 sample pages:

Platform	Result
Android (API 36 emulator)	97 OK, 0 MethodAccess/FieldAccess/TypeAccess
Mac Catalyst	99 visited, 94 OK, 0 MethodAccess/FieldAccess/TypeAccess

Non-OK pages are identical to the pre-change baseline and unrelated to this PR: StatusBarBehaviorPage (NotSupportedException, by design on Catalyst), IsInRangeConverterPage (Invalid getter), StateContainerPage (InvalidCastException), and two MediaElement pages timing out on media load.

Runtime — targeted probes (the page walk only navigates, so these exercise the actual changed code paths):

Scenario	Result
FolderPicker — user cancels	TaskCanceledException
FolderPicker — user picks	success=True path=/storage/emulated/0/Documents
FolderPicker — token cancelled while picker on screen	completed as TaskCanceledException at 6.0s, i.e. immediately on cancel rather than waiting for dismissal
FileSaver — save	success=True, file on disk with the expected contents
Snackbar + snackbar over a modal page	shown & dismissed (Android + Catalyst)
UserStoppedTypingBehavior	command fired (Android + Catalyst)
TouchBehavior attach	no exception

cc @TheCodeTraveler @bijington @PureWeen @kubaflo

[bijington]

Looks good to me! I think we need to chase up this pipeline build issue but that isn't caused by this PR.

[jfversluis]

Final internal-API audit — commit 6a1a1a79

A second adversarial audit found two areas the earlier validation had missed:

• The optional Tizen Snackbar still called MAUI's internal one-argument ElementExtensions.ToPlatform(IElement) overload.
• Unit tests still relied on MAUI friendship for internal Essentials setters, gesture dispatch, routing/collection helpers, and construction of inaccessible base types.

The latest commit replaces those references with public MAUI APIs or Toolkit-owned test hooks. The Tizen anchor now uses Anchor.Handler?.PlatformView, and the unit suite no longer requires MAUI InternalsVisibleTo access.

Final validation

• Exact SDK 11.0.100-preview.7.26381.103 + MAUI 11.0.0-preview.7.26403.4: 11,661/11,661 tests passed.
• Baseline MAUI 10.0.60: 11,661/11,661 tests passed.
• Exact Preview 7 and baseline Toolkit builds passed for shared, Android, iOS, and Mac Catalyst targets; the PR's Windows and macOS library/sample builds are also green.
• Hardened Mono.Cecil scan, resolving the exact platform-specific MAUI reference assemblies: 0 inaccessible references and 0 unresolved references for every scanned net10/net11 shared, Android, iOS, and Mac Catalyst output.
• The replacement Tizen anchor expression compiles with 0 warnings/errors against Samsung's supported .NET 10 Tizen workload and scans with 0 inaccessible/unresolved MAUI references. The full optional Tizen project currently stops earlier on an unrelated existing SkiaSharp 3 SKFilterQuality incompatibility.
• Source audit found no remaining internal Essentials setters, SendTapped, Routing.Clear, MAUI internal namespaces, TryRemove, or element ToPlatform() calls. Remaining parameterless ToPlatform() calls are public color/platform conversions and are clean in the metadata scan.
• Independent final review with Claude Opus reported no actionable findings.
• Fresh PR CI: both library builds, both sample builds, benchmarks, WIP, and CLA all pass. No new review comments were posted.

At this point the only PR gate is renewed human approval after the new commit.