Permissions (BT & WiFi): don't add AccessFineLocation to required permissions if NeverForLocation flag is present #20874
Conversation
ghost
added
the
|
Hey there @janusw! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
|
/azp run MAUI-UITests-public |
|
Azure Pipelines successfully started running 1 pipeline(s). |
jfversluis
added
the
area-essentials
|
Someone, please approve this PR. It's hurting the development and new features. |
|
Someone, please approve the PR. This should be the part of MAUI. please make it happen it would help the developers. |
|
please get Bluetooth and Wifi independent from LOCATION permission. |
…missions if NeverForLocation flag is present * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
janusw
force-pushed
the
permissions_fix_neverforlocation
branch
from
b315053 to
2159c41
Compare
|
I have rebased this on the current main branch. @jfversluis @rmarinho @PureWeen Can we please get this into MAUI v10? It's a relatively simple fix without any API changes ... |
There was a problem hiding this comment.
Pull Request Overview
This PR ensures that AccessFineLocation is not added to the required permissions for Bluetooth and WiFi when the NeverForLocation flag is declared, resolving issue #20871.
- Added
HasFlagInManifestto detectNeverForLocationflags in the manifest. - Updated the
RequiredPermissionslogic for Bluetooth and NearbyWifiDevices to skipAccessFineLocationif the flag is present. - Removed redundant manifest checks for older Android SDK versions (<= R and < Tiramisu).
Comments suppressed due to low confidence (3)
src/Essentials/src/Permissions/Permissions.android.cs:239
- New behavior around skipping
AccessFineLocationwhen theNeverForLocationflag is set needs automated tests. Please add cases inTestCases.Shared.TestsandTestCases.HostAppto cover both Bluetooth and WiFi scenarios.
if (IsDeclaredInManifest(Manifest.Permission.AccessFineLocation) && !HasFlagInManifest(Manifest.Permission.BluetoothScan, RequestedPermission.NeverForLocation))
src/Essentials/src/Permissions/Permissions.android.cs:7
- [nitpick] The docs in
/docs/should be updated to describe the newNeverForLocationflag behavior for Bluetooth and NearbyWifiDevices permissions so that public documentation matches the implementation.
using Android.Content.PM;
src/Essentials/src/Permissions/Permissions.android.cs:36
- Using
requestedPermissions.Counton an array is invalid and may throw. Switch torequestedPermissions.Length(and similarly forrequestedPermissionsFlags) and guard againstrequestedPermissionsorrequestedPermissionsFlagsbeing null before the loop.
for (int i=0; i<requestedPermissions.Count; i++)
|
Hey everyone, sorry this fell between the cracks. While I absolutely agree we should take this and lets make it happen, I just wanted to note that for a lot of this stuff, especially permissions, you shouldn't be blocked on it since it is very extensible: https://learn.microsoft.com/dotnet/maui/platform-integration/appmodel/permissions?view=net-maui-9.0&tabs=android#extending-permissions sure, if we do it its easier for you, but you shouldn't be blocked on this. Just wanted to let you know! :) Now with that, lets see if we can get this in, thanks for all the hard work @janusw! Also if anyone here would be able to grab the artifacts from this build and test it out and let us know if it doesn't have any unexpected side-effects, that would be amazing! See instructions for that here: https://github.com/dotnet/maui/wiki/Testing-PR-Builds |
|
/azp run MAUI-public |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
…missions if NeverForLocation flag is present (#20874) * otherwise the permission-status will be 'denied' if AccessFineLocation is in the manifest, but denied at runtime (even if it is not strictly required)
6 participants
Description of Change
This fixes #20871, by making sure that
AccessFineLocationis not added to the required permissions forPermissions.BluetoothorPermissions.NearbyWifiDevicesif they are declared with theNeverForLocationflag.Otherwise the permission status will be
PermissionStatus.Denied, ifAccessFineLocationis in the manifest but denied at runtime (even if it is not strictly required).Issues Fixed
Fixes #20871