Essentials
Essentials copied to clipboard
[Bug] Launcher.CanOpenAsync() returns wrong value
Description
On Android, Launcher.CanOpenAsync() returns wrong value for Google Maps URLs when targeting API level 30 (Android 11). This works fine when targeting API level 29.
Steps to Reproduce
- Set Android target framework version to API level 30.
- Execute code below
string url = "https://maps.google.com/maps?q=123+Main+Street+Atlanta+GA+30303";
var uri = new Uri(url);
bool canOpen = await Launcher.CanOpenAsync(uri);
Console.WriteLine($"await Launcher.CanOpenAsync(uri) = {canOpen}");
Expected Behavior
Output should be
await Launcher.CanOpenAsync(uri) = True
Actual Behavior
await Launcher.CanOpenAsync(uri) = False
Basic Information
- Version with issue: Xamarin Essentials 1.7.0
- Xamarin.Forms 5.0.0.2291
- IDE: Visual Studio for Mac 2019
This happens when an app attempts to launch my app as well. Was working previously but seems to have stopped after my tablet (Galaxy Tab A SM-T510 Android 11) was updated to the latest One UI version - 3.1 or I updated to Visual Studio 2022 17.0.5.
I can also reproduce it on a Google Pixel 4a running Android 12
Is that more related to the new "query" attribute required for app targeting api 30 ?
https://medium.com/androiddevelopers/package-visibility-in-android-11-cc857f221cd9
Duplicate of #1958
I can confirm this is still an issue in VS Version 17.5.0 Preview 1.0 using Android API 30 emulator.
await Launcher.CanOpenAsync("https://google.com"); returns false. but await Launcher.OpenAsync("https://google.com") opens a browser and goes to google.com.
I think this is due to the android os. You will need the query things as mentioned by @softlion
This is definitely still a problem:
- we try to open a specific url.
- CanOpenAsync returns true and the browser opens the url.
- then we install an app that also wants to open the url.
- CanOpenAsync now returns false, rendering the feature useless.
on
- essentials 1.7.4
- xamarin forms 5.0.0.2578
- multiple android devices at different api levels
A workaround seems to be wrapping the Launcher.OpenAsync(uri) method in a try/catch instead of checking "CanOpenAsync".