dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
22.28k stars 1.76k forks source link

Requesting Bluetooth permissions on Android 12+ at runtime #12264

Closed janusw closed 1 year ago

janusw commented 1 year ago

Description

Microsoft.Maui.ApplicationModel.Permissions contains support for all kind of runtime permissions, but it is currently missing support for Android 12 Bluetooth permissions, see https://developer.android.com/guide/topics/connectivity/bluetooth/permissions.

Previous to Android 12, a runtime request was not necessary for the Bluetooth permissions (only the location permission needed to be requested at runtime). With Android 12, the Bluetooth permission scheme was changed, and now there are three kinds of Bluetooth permissions that can be requested at runtime: BLUETOOTH_ADVERTISE, BLUETOOTH_CONNECT and BLUETOOTH_SCAN.

This was already requested for Xamarin.Essentials, see https://github.com/xamarin/Essentials/issues/1943, but never implemented, apparently.

Public API Changes

The following kinds of requests should be possible:

PermissionStatus s1 = await Permissions.RequestAsync<Permissions.BluetoothAdvertise>();
PermissionStatus s2 = await Permissions.RequestAsync<Permissions.BluetoothConnect>();
PermissionStatus s3 = await Permissions.RequestAsync<Permissions.BluetoothScan>();

Potentially also a way to bundle them would be useful (requesting two or more of them with a single call).

Intended Use-Case

This is relevant for any app that uses Bluetooth functionality (e.g. via https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le) and targets Android 12 or later.

The sample app in dotnet-bluetooth-le currently works around this, see https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le/pull/582.

jfversluis commented 1 year ago

We definitely need to add the missing ones, to unblock you and be able to use this right now, the current permissions are pretty extensible, have a look here: https://learn.microsoft.com/dotnet/maui/platform-integration/appmodel/permissions?view=net-maui-7.0&tabs=android#extending-permissions

janusw commented 1 year ago

to unblock you and be able to use this right now, the current permissions are pretty extensible, have a look here: https://learn.microsoft.com/dotnet/maui/platform-integration/appmodel/permissions?view=net-maui-7.0&tabs=android#extending-permissions

Well, yeah, this is basically what we're doing with dotnet-bluetooth-le already.

For some people it might be another option to simply stick to targeting Android 11. Note that the Maui migration guide recommends targeting Android 12, though (but I'm not sure if there is a particular reason for that).

janusw commented 1 year ago

For some people it might be another option to simply stick to targeting Android 11. Note that the Maui migration guide recommends targeting Android 12, though (but I'm not sure if there is a particular reason for that).

Actually this does not seem work. When targeting net7.0-android30.0, I get the following error:

error NETSDK1181: Error getting pack version: Pack 'Microsoft.Android.Ref.30' was not present in workload manifests.

In fact the same kind of error occurs also with v31 and v32, and only targeting v33 really seems to work (which obviously must be a tooling bug). This is with .NET SDK 7.0.101 on MacOS.

janusw commented 1 year ago

In contrast to my original proposal in this issue, in #12413 I'm only adding a single permission class for Bluetooth, which covers all those Bluetooth permissions that are declared in the manifest, so a permission request will look like this:

PermissionStatus s = await Permissions.RequestAsync<Permissions.Bluetooth>();
ghost commented 1 year ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.