[Essentials] Browser.OpenAsync(External): drop visibility-filtered ResolveActivity pre-check

[Kebechet]

Description of Change

Removes the PlatformUtils.IsIntentSupported(intent) pre-check from Browser.OpenAsync(uri, BrowserLaunchMode.External) on Android, and instead relies on ActivityNotFoundException from Application.Context.StartActivity as the authoritative "no handler" signal.

Why the pre-check is wrong

PlatformUtils.IsIntentSupported calls Intent.ResolveActivity(pm). On Android 11+ (API 30, package visibility), that call returns null in two distinct cases:

1. No activity exists that can handle the intent. StartActivity would also fail.
2. An activity exists but is invisible to the caller because of <queries> package visibility filtering. StartActivity would still succeed — system intent dispatch is not subject to caller-side visibility, only query* APIs are.

Today MAUI conflates the two and throws FeatureNotSupportedException even in case 2, blocking a launch Android could perform.

This breaks the common case of opening a URL whose owner is a verified App Link that the caller has not explicitly declared as visible (Instagram, Facebook, Spotify, X, TikTok, Google Maps, etc.). The standard <queries><intent VIEW + scheme=https></intent></queries> declaration recommended in the docs grants visibility to generic browsers (whose VIEW filter is host-less) but not to host-bound App Link owners — per Android's auto-visibility rules:

"If the intent filter includes a <data> element that contains a host, then your app is NOT considered to handle a web intent."

So even with the documented manifest fix, the App Link owner case stays broken.

The fix

try
{
    Application.Context.StartActivity(intent);
}
catch (ActivityNotFoundException ex)
{
    throw new FeatureNotSupportedException(
        "No activity found to handle URI: " + nativeUri, ex);
}

ActivityNotFoundException is the only authoritative signal that no activity can actually handle the intent, since only the system dispatcher knows. The public contract (FeatureNotSupportedException thrown when no activity is available) is preserved — we just wrap the real Android exception instead of guessing from a visibility-filtered query.

This matches @jfversluis's own suggestion on the related issue #27744:

"Yeah looks like we check if the intent is supported for a URL. I guess if its http(s) we should just open the browser and not do anything further."

A more conservative variant (skip the pre-check only for http/https, keep it for custom schemes) is described in the linked issue as Option B; happy to switch if reviewers prefer it.

Testing

Manually verified on a Pixel running Android 14:

• Before the change: Browser.OpenAsync("https://www.instagram.com/instagram/", External) with Instagram installed throws FeatureNotSupportedException. Confirmed AppsFilter: ... BLOCKED in logcat and confirmed Instagram is missing from the calling app's dumpsys package queries visible list despite a correct <queries> http/https block.
• After the change: same call opens the Instagram app directly via App Link routing.
• Cross-checked behavior is unchanged for: generic URL (no installed App Link owner) → opens default browser; non-web custom scheme intent with no handler → still throws FeatureNotSupportedException, now wrapping the underlying ActivityNotFoundException.

No existing Android-platform tests for Browser.OpenAsync to update (Browser_Tests.cs covers only the netstandard reference assembly and URI escaping). Happy to add device-level tests if maintainers want them as a follow-up — the test infra change is larger than this fix.

Issues Fixed

Fixes #35651

[dotnet-policy-service]

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

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

Or

• Run remotely in PowerShell:

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

[kubaflo]

/review -b feature/refactor-copilot-yml

[MauiBot]

Expert Review — 1 findings

See inline comments for details.

[MauiBot]

[major] Regression Prevention and Test Coverage - This Android behavior change fixes a concrete package-visibility/App Link regression, but the PR does not add any regression coverage. Please add an Android test (device/integration if necessary) that exercises BrowserLaunchMode.External for an ACTION_VIEW URL path and verifies the implementation relies on StartActivity/ActivityNotFoundException rather than the visibility-filtered ResolveActivity pre-check, so this does not regress back to querying PackageManager.

[MauiBot]

🤖 AI Summary

👋 @Kebechet — new AI review results are available. Please review the latest session below.

📊 Review Session — 37d2d45 · [Essentials] Browser.OpenAsync(External): drop visibility-filtered pre-check · 2026-05-29 08:44 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

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

---

🧪 UI Tests — Essentials

Detected UI test categories: Essentials

⏭️ Deep UI tests — 0 passed, 0 failed across 1 category on platform-pool agent (replaces in-process counts above). 1 category reported 0 tests.

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
Essentials	0 tests	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

🔍 Pre-Flight — Context & Validation

Issue: #35651 - Browser.OpenAsync External throws FeatureNotSupportedException for Android verified App Link owners hidden by package visibility
PR: #35652 - Remove Android Browser external intent visibility pre-check
Platforms Affected: Android
Files Changed: 1 implementation, 0 test

Key Findings

• BrowserLaunchMode.External on Android currently pre-checks ACTION_VIEW support with PlatformUtils.IsIntentSupported, which uses visibility-filtered package-manager resolution on Android 11+.
• Verified App Link owners with host-bound filters can be invisible to the caller even though Android's system resolver can still launch them via StartActivity.
• The PR's fix removes the pre-check and preserves the public unsupported-feature contract by wrapping ActivityNotFoundException in FeatureNotSupportedException.
• Gate was already skipped because no tests were detected in this PR; no gate/content.md was created or overwritten.

Code Review Summary

Verdict: LGTM
Confidence: medium
Errors: 0 | Warnings: 1 | Suggestions: 0

Key code review findings:

• ⚠️ src/Essentials/src/Browser/Browser.android.cs: removing the pre-check for all schemes is broader than the web/App Link failure; a narrower web-scheme bypass is an alternative candidate.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35652	Remove PlatformUtils.IsIntentSupported(intent) for Android external browser launches and wrap ActivityNotFoundException.	⚠️ SKIPPED (Gate: no tests detected)	src/Essentials/src/Browser/Browser.android.cs	Original PR

---

🔬 Code Review — Deep Analysis

Code Review — PR #35652

Independent Assessment

What this changes: Android BrowserLaunchMode.External no longer pre-queries whether an ACTION_VIEW intent is supported before launching. It lets Android's activity resolver perform the launch and maps ActivityNotFoundException back to MAUI's public FeatureNotSupportedException contract.
Inferred motivation: ResolveActivity/package-manager queries can be filtered by Android 11+ package visibility, so the pre-check can falsely report that verified App Link targets are unavailable even when StartActivity can launch them.

Reconciliation with PR Narrative

Author claims: PR fixes Browser.OpenAsync(..., BrowserLaunchMode.External) for Android verified App Link owners such as Instagram/Facebook/Spotify by removing the visibility-filtered PlatformUtils.IsIntentSupported(intent) pre-check and relying on ActivityNotFoundException.
Agreement/disagreement: The code matches the stated root cause and preserves the no-handler exception behavior by wrapping ActivityNotFoundException. The approach is broad because it removes the pre-check for all schemes, not only http/https.

Findings

⚠️ Warning — Broader behavior change than necessary for non-web schemes

src/Essentials/src/Browser/Browser.android.cs: the PR removes PlatformUtils.IsIntentSupported(intent) for every URI scheme. This is probably safe because StartActivity remains authoritative and ActivityNotFoundException is wrapped, but the reported Android package-visibility failure is specific to web/App Link resolution. A narrower fix could preserve the pre-check for custom schemes while bypassing it for http/https.

Devil's Advocate

The warning may not be a blocker: querying custom-scheme handlers is also subject to Android package visibility, so keeping the pre-check for non-web schemes could preserve existing behavior but may also preserve false negatives for apps that did not declare matching <queries>. The PR's simpler all-schemes approach aligns with Android's recommended launch-then-catch pattern.

Verdict: LGTM

Confidence: medium
Summary: The PR fix is technically sound for the reported Android App Link failure and maintains the public exception contract. The main tradeoff is scope: removing the pre-check for all schemes is simpler and arguably more correct, while a web-only bypass is a narrower alternative worth comparing.

---

🔧 Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix-1	Skip PlatformUtils.IsIntentSupported only for http/https; keep the pre-check for non-web schemes and wrap ActivityNotFoundException.	❌ FAIL (local Android build validation blocked by NETSDK1005 assets target)	1 file	Narrower than PR and logically viable, but not validated locally; may preserve false negatives for non-web deep links.
2	try-fix-2	Keep pre-check; when it fails for web URLs, fall back to existing Custom Tabs/SystemPreferred path.	❌ FAIL (same local Android build blocker)	1 file	Avoids exception but changes External semantics on the affected path; not better than PR.
3	try-fix-3	Keep pre-check; add CATEGORY_BROWSABLE and retry support detection for web URLs.	❌ FAIL (expert self-review + same local Android build blocker)	1 file	Rejected because it still makes package-manager query results authoritative, preserving the root cause.
4	try-fix-4	Keep pre-check; if it fails for web URLs, launch a chooser intent and wrap ActivityNotFoundException.	❌ FAIL (semantic self-review + same local Android build blocker)	1 file	Chooser fallback can alter Android external-link UX; not better than direct system resolution.
PR	PR #35652	Remove the support pre-check for Android external launches and rely on StartActivity; wrap ActivityNotFoundException.	⚠️ SKIPPED (Gate: no tests detected)	1 file	Original PR; remains the best approach from analysis.

Expert Review / Learn Loop

Round	Input/Lesson	Resulting Candidate
Pre-flight	Root cause is Android 11+ package-visibility filtering of ResolveActivity/package-manager queries for verified App Link owners.	Candidate 1 tested a narrower web-only bypass.
After try-fix-1	Local validation failed before code compilation because project.assets.json lacked net10.0-android; the candidate itself remained logically plausible but narrower than PR.	Candidate 2 used restore/build and explored fallback to an existing MAUI Browser path.
After try-fix-2	Custom Tabs fallback avoids the throw but changes BrowserLaunchMode.External behavior.	Candidate 3 tried preserving external path with query retry.
After try-fix-3	Query retry preserves the package-visibility root cause.	Candidate 4 tried system-mediated chooser fallback.
After try-fix-4	Chooser fallback changes external-link UX and is not superior to Android's normal resolver.	Stop: no meaningfully different better approach remains.

Exhausted: Yes
Selected Fix: PR #35652 — It is the simplest and most faithful fix: let Android's system resolver launch the external intent and use ActivityNotFoundException as the authoritative no-handler signal. Candidate 1 is the closest alternative, but it is narrower and may retain package-visibility false negatives for non-web deep links; candidates 2-4 are semantically weaker or preserve the root cause.

Validation Blocker

All candidate build validations hit the same local Android target issue:

NETSDK1005: Assets file 'artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project.

This occurred even when running dotnet build src/Essentials/src/Essentials.csproj -f net10.0-android with restore enabled. The gate result supplied by the caller was already SKIPPED — no tests detected, and gate/content.md was not modified.

---

---

try-fix-1 — Web-scheme-only pre-check bypass

Approach

Skip PlatformUtils.IsIntentSupported(intent) only for http and https URIs, retain it for custom schemes, and wrap ActivityNotFoundException from StartActivity.

Diff

diff --git a/src/Essentials/src/Browser/Browser.android.cs b/src/Essentials/src/Browser/Browser.android.cs
index e16799c286..2efe1c5855 100755
--- a/src/Essentials/src/Browser/Browser.android.cs
+++ b/src/Essentials/src/Browser/Browser.android.cs
@@ -86,28 +86,18 @@ namespace Microsoft.Maui.ApplicationModel
 #endif
 			intent.SetFlags(flags);
 
-			// Do not pre-check via Intent.ResolveActivity / PackageManager.QueryIntent*.
-			// Those calls are filtered by the caller's <queries> package visibility
-			// (Android 11+, API 30+), so they return null whenever the only handler
-			// of the URL is a package that is invisible to us — typically a verified
-			// App Link owner like Instagram, Facebook, Spotify, etc., whose VIEW
-			// filter is host-bound and therefore not covered by the automatic
-			// web-handler visibility exception (see Android docs:
-			// https://developer.android.com/training/package-visibility/automatic#web-intents).
-			//
-			// Application.Context.StartActivity itself is dispatched by the system
-			// intent resolver and is NOT subject to caller-side visibility — it can
-			// launch invisible activities; the caller just cannot query about them
-			// ahead of time. ActivityNotFoundException is the only authoritative
-			// signal that no activity can actually handle the intent.
+			var isWebUri = nativeUri?.Scheme is "http" or "https";
+
+			if (!isWebUri && !PlatformUtils.IsIntentSupported(intent))
+				throw new FeatureNotSupportedException();
+
 			try
 			{
 				Application.Context.StartActivity(intent);
 			}
 			catch (ActivityNotFoundException ex)
 			{
-				throw new FeatureNotSupportedException(
-					"No activity found to handle URI: " + nativeUri, ex);
+				throw new FeatureNotSupportedException($"No activity found to handle URI: {nativeUri}", ex);
 			}
 		}
 	}

Test Results

Result: Fail

/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]

Build FAILED.

/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.67

Failure Analysis

The available Android build validation failed; see test output. The approach remains logically viable only if the failure is environmental rather than caused by this diff.

---

try-fix-2 — Web fallback to Custom Tabs

Approach

Keep the pre-check, but when it fails for http/https, call LaunchChromeTabs(options, nativeUri) instead of throwing.

Diff

diff --git a/src/Essentials/src/Browser/Browser.android.cs b/src/Essentials/src/Browser/Browser.android.cs
index e16799c286..28d4930d40 100755
--- a/src/Essentials/src/Browser/Browser.android.cs
+++ b/src/Essentials/src/Browser/Browser.android.cs
@@ -86,29 +86,18 @@ namespace Microsoft.Maui.ApplicationModel
 #endif
 			intent.SetFlags(flags);
 
-			// Do not pre-check via Intent.ResolveActivity / PackageManager.QueryIntent*.
-			// Those calls are filtered by the caller's <queries> package visibility
-			// (Android 11+, API 30+), so they return null whenever the only handler
-			// of the URL is a package that is invisible to us — typically a verified
-			// App Link owner like Instagram, Facebook, Spotify, etc., whose VIEW
-			// filter is host-bound and therefore not covered by the automatic
-			// web-handler visibility exception (see Android docs:
-			// https://developer.android.com/training/package-visibility/automatic#web-intents).
-			//
-			// Application.Context.StartActivity itself is dispatched by the system
-			// intent resolver and is NOT subject to caller-side visibility — it can
-			// launch invisible activities; the caller just cannot query about them
-			// ahead of time. ActivityNotFoundException is the only authoritative
-			// signal that no activity can actually handle the intent.
-			try
+			if (!PlatformUtils.IsIntentSupported(intent))
 			{
-				Application.Context.StartActivity(intent);
-			}
-			catch (ActivityNotFoundException ex)
-			{
-				throw new FeatureNotSupportedException(
-					"No activity found to handle URI: " + nativeUri, ex);
+				if (nativeUri?.Scheme is "http" or "https")
+				{
+					LaunchChromeTabs(options, nativeUri);
+					return;
+				}
+
+				throw new FeatureNotSupportedException();
 			}
+
+			Application.Context.StartActivity(intent);
 		}
 	}
 }

Test Results

Result: Fail

  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 559 ms).
  Restored /home/vsts/work/1/s/src/Essentials/src/Essentials.csproj (in 3.61 sec).
/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]

Build FAILED.

/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.34

Failure Analysis

Validation failed; see test output. Independent of build status, this approach is semantically weaker because it can avoid opening the verified App Link owner externally.

---

try-fix-3 — Browser-category retry

Approach

When IsIntentSupported fails for web URLs, add CATEGORY_BROWSABLE and retry support detection before launching.

Diff

diff --git a/src/Essentials/src/Browser/Browser.android.cs b/src/Essentials/src/Browser/Browser.android.cs
index e16799c286..2d86a49f29 100755
--- a/src/Essentials/src/Browser/Browser.android.cs
+++ b/src/Essentials/src/Browser/Browser.android.cs
@@ -86,29 +86,21 @@ namespace Microsoft.Maui.ApplicationModel
 #endif
 			intent.SetFlags(flags);
 
-			// Do not pre-check via Intent.ResolveActivity / PackageManager.QueryIntent*.
-			// Those calls are filtered by the caller's <queries> package visibility
-			// (Android 11+, API 30+), so they return null whenever the only handler
-			// of the URL is a package that is invisible to us — typically a verified
-			// App Link owner like Instagram, Facebook, Spotify, etc., whose VIEW
-			// filter is host-bound and therefore not covered by the automatic
-			// web-handler visibility exception (see Android docs:
-			// https://developer.android.com/training/package-visibility/automatic#web-intents).
-			//
-			// Application.Context.StartActivity itself is dispatched by the system
-			// intent resolver and is NOT subject to caller-side visibility — it can
-			// launch invisible activities; the caller just cannot query about them
-			// ahead of time. ActivityNotFoundException is the only authoritative
-			// signal that no activity can actually handle the intent.
-			try
+			if (!PlatformUtils.IsIntentSupported(intent))
 			{
-				Application.Context.StartActivity(intent);
-			}
-			catch (ActivityNotFoundException ex)
-			{
-				throw new FeatureNotSupportedException(
-					"No activity found to handle URI: " + nativeUri, ex);
+				if (nativeUri?.Scheme is "http" or "https")
+				{
+					intent.AddCategory(Intent.CategoryBrowsable);
+					if (!PlatformUtils.IsIntentSupported(intent))
+						throw new FeatureNotSupportedException();
+				}
+				else
+				{
+					throw new FeatureNotSupportedException();
+				}
 			}
+
+			Application.Context.StartActivity(intent);
 		}
 	}
 }

Test Results

Result: Fail

  Determining projects to restore...
  All projects are up-to-date for restore.
/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]

Build FAILED.

/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.23

Failure Analysis

The approach fails expert self-review because it keeps a package-manager query as the gate. Package visibility filtering is the root cause, so retrying a different query shape is not a robust fix.

---

try-fix-4 — Web chooser fallback

Approach

If the existing support query fails for web URLs, start Intent.CreateChooser(intent, null) and wrap ActivityNotFoundException.

Diff

diff --git a/src/Essentials/src/Browser/Browser.android.cs b/src/Essentials/src/Browser/Browser.android.cs
index e16799c286..476fd2438d 100755
--- a/src/Essentials/src/Browser/Browser.android.cs
+++ b/src/Essentials/src/Browser/Browser.android.cs
@@ -86,28 +86,22 @@ namespace Microsoft.Maui.ApplicationModel
 #endif
 			intent.SetFlags(flags);
 
-			// Do not pre-check via Intent.ResolveActivity / PackageManager.QueryIntent*.
-			// Those calls are filtered by the caller's <queries> package visibility
-			// (Android 11+, API 30+), so they return null whenever the only handler
-			// of the URL is a package that is invisible to us — typically a verified
-			// App Link owner like Instagram, Facebook, Spotify, etc., whose VIEW
-			// filter is host-bound and therefore not covered by the automatic
-			// web-handler visibility exception (see Android docs:
-			// https://developer.android.com/training/package-visibility/automatic#web-intents).
-			//
-			// Application.Context.StartActivity itself is dispatched by the system
-			// intent resolver and is NOT subject to caller-side visibility — it can
-			// launch invisible activities; the caller just cannot query about them
-			// ahead of time. ActivityNotFoundException is the only authoritative
-			// signal that no activity can actually handle the intent.
+			if (!PlatformUtils.IsIntentSupported(intent))
+			{
+				if (nativeUri?.Scheme is not ("http" or "https"))
+					throw new FeatureNotSupportedException();
+
+				intent = Intent.CreateChooser(intent, null);
+				intent.SetFlags(flags);
+			}
+
 			try
 			{
 				Application.Context.StartActivity(intent);
 			}
 			catch (ActivityNotFoundException ex)
 			{
-				throw new FeatureNotSupportedException(
-					"No activity found to handle URI: " + nativeUri, ex);
+				throw new FeatureNotSupportedException($"No activity found to handle URI: {nativeUri}", ex);
 			}
 		}
 	}

Test Results

Result: Fail

  Determining projects to restore...
  All projects are up-to-date for restore.
/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]

Build FAILED.

/home/vsts/work/1/s/.dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/vsts/work/1/s/artifacts/obj/Essentials/project.assets.json' doesn't have a target for 'net10.0-android'. Ensure that restore has run and that you have included 'net10.0-android' in the TargetFrameworks for your project. [/home/vsts/work/1/s/src/Essentials/src/Essentials.csproj::TargetFramework=net10.0-android]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.24

Failure Analysis

The approach is not better than the PR because it can surface an Android chooser on a path where direct external resolution should open the verified App Link owner/default handler.

---

📋 Report — Final Recommendation

Comparative Fix Report - PR #35652

Candidate Ranking

Rank	Candidate	Validation status	Assessment
1	pr-plus-reviewer	Gate skipped; no tests detected	Same implementation as the PR, plus the expert reviewer's actionable requirement to add Android regression coverage. Best overall candidate because it keeps the correct root-cause fix and captures the only expert-review gap.
2	pr	Gate skipped; no tests detected	Correct and simplest implementation: remove the visibility-filtered support pre-check and rely on Android's resolver via StartActivity, preserving unsupported behavior through ActivityNotFoundException wrapping. Ranked below pr-plus-reviewer only because it lacks regression coverage.
3	try-fix-1	Failed local Android build validation (NETSDK1005)	Logically closest alternative: bypasses the pre-check only for http/https and keeps it for custom schemes. It is narrower than the PR but may retain package-visibility false negatives for non-web deep links, and failed validation candidates must rank below non-failing candidates.
4	try-fix-4	Failed local Android build validation (NETSDK1005)	Chooser fallback still avoids the immediate false negative for some web URLs, but it can change external-link UX by showing a chooser where Android's normal resolver/default or verified owner should handle the launch directly.
5	try-fix-2	Failed local Android build validation (NETSDK1005)	Falling back to Custom Tabs changes BrowserLaunchMode.External semantics and can avoid opening the verified App Link owner, so it is weaker than the PR approach.
6	try-fix-3	Failed local Android build validation (NETSDK1005)	Keeps package-manager support detection as the gate after adding CATEGORY_BROWSABLE, so it preserves the root cause: visibility-filtered query results remain authoritative.

Analysis

The root cause is Android package visibility: pre-launch queries such as ResolveActivity/PackageManager.QueryIntent* can fail for verified App Link owners hidden from the caller, while StartActivity can still dispatch through the system resolver. The PR fix addresses this directly by removing the query gate for external browser launches and treating ActivityNotFoundException as the authoritative no-handler signal.

The expert reviewer found no product-code correctness issue in the PR implementation. The one actionable finding is missing Android regression coverage. That makes pr-plus-reviewer the best candidate: it preserves the PR's correct implementation and adds the reviewer requirement that tests be added before merge.

All STEP 5a try-fix candidates failed Android build validation with the same local NETSDK1005 assets-target blocker. Per the ranking rule, those failed candidates are ranked lower than the PR-family candidates. Independently of that blocker, none of the try-fix alternatives is better than the PR: try-fix-1 is narrower and may retain false negatives, try-fix-2 changes External semantics, try-fix-3 preserves the problematic query gate, and try-fix-4 changes UX through a chooser fallback.

Winner

Winner: pr-plus-reviewer.

Rationale: the PR implementation is the only candidate that directly removes the visibility-filtered pre-check without changing BrowserLaunchMode.External semantics, and the expert reviewer's feedback adds the necessary regression-test requirement without requiring a different product-code fix.

---

[kubaflo]

Could you check the ai's recommendations?