Open borrmann opened 4 months ago
borrmann
commented
4 months ago Looking at the source code, Permissions.android.cs line 22 might be the issue.
Instead of
var requestedPermissions = packageInfo?.RequestedPermissions;
using
var requestedPermissions = packageInfo?.Permissions;
could maybe solve the issue.
According to the XML, RequestedPermissions are all uses-permissions, while Permissions are ALL permissions that are listed in the manifest.
Redth
commented
4 months ago Interestingly, when you set the android:requiredFeature value in the manifest, the permission no longer shows up at all in the package in's RequestedPermissions (or Permissions) for that matter...
I see the following permissions in RequestedPermissions:
And in Permissions:
Redth
commented
4 months ago It seems like Google maybe has a bug here, since they aren't returning the permission in the list of requested permissions. To work around this, can you use <uses-feature android:name="android.hardware.camera" android:required="false" /> instead of setting android:required="false" on the uses-permission? This would be the easiest way to work around it.
If this is coming in from some other reference, you should be able to use manifest merge files to remove the one incoming, and add your own by creating a merge file, and adding it to the item group AndroidManifestOverlay in your project.
The Manifest Merger tool docs have more info.
eg: This would be a merge file with something like this to remove the permission which has the required="false" node:
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<uses-permission android:name="android.permission.CAMERA" tools:node="remove" />
</manifest>You would add this merge file to your csproj like this:
<ItemGroup>
<AndroidManifestOverlay Include="MyMergeFile.xml" />
</ItemGroup>Thank you, I appreciate it. I will look into this and it might be a suitable workaround. I don’t think this issue should be closed though. As far as I know uses feature and uses permission have different impacts on where and for what devices the published app is going to be available for - I am not an Android expert so I don’t know exactly but they seem to be two different things, probably for a reason. And why does Maui throw an exception here? I have declared the permission and I am asking for it, so I don’t need this manual check if the permission is in the manifest? I understand this is to warn developers and to help them implement it correctly, but then it should be a warning and not an exception, since the code would run as expected in certain (above) situations.
XamlTest
commented
3 months ago Verified this on VS 17.10.0 Preview 2.0(8.0.14). Repro on Android 14.0-API34 with Project: AndroidPermission.zip
Description
Permissions do not work on Android if they are not required. e.g. using
<uses-permission android:name="android.permission.READ_CONTACTS" android:requiredFeature="false" />PermissionStatus status = await Permissions.CheckStatusAsync<Permissions.ContactsRead>();throws an exception, even if reading contacts is supported on the device.
when using
<uses-permission android:name="android.permission.READ_CONTACTS" />it works as expected.This has the effect, that the permission is never requested, so it won't even show up in the devices app settings and the user will never be able to use the feature that requires the permission.
Steps to Reproduce
Link to public reproduction project repository
https://github.com/borrmann/AndroidPermission
Version with bug
8.0.7 SR2
Is this a regression from previous behavior?
No, this is something new
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
No response
Did you find any workaround?
No
Relevant log output
No response