Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove android permissions #286

Open
timbo-tj opened this issue Apr 12, 2023 · 6 comments
Open

Remove android permissions #286

timbo-tj opened this issue Apr 12, 2023 · 6 comments

Comments

@timbo-tj
Copy link

Hey there, we are using native gallery to write screenshots to disk, but we dont need the read permissions.

How can I strip these permissions out without forking the package and modifying the manifest? Or is that the only way?

@timbo-tj
Copy link
Author

We received this feedback from the Google Play featuring team who require us to remove permissions we dont utilise.

@timbo-tj
Copy link
Author

Temporarily modified the manfiest with the follownig:

           internal void ModifyFileAccessPermissions()
{
    // NativeGallery plugin requires these permissions, but we dont
    // perform read operations so remove them from the manifest
    RemovePermission("android.permission.READ_EXTERNAL_STORAGE");
    RemovePermission("android.permission.READ_MEDIA_IMAGES");
    RemovePermission("android.permission.READ_MEDIA_AUDIO");
    RemovePermission("android.permission.READ_MEDIA_VIDEO");
    
    // NativeGallery plugin requires this permission, but its not
    // required for Android 10 and above
    AddOrRemoveTag(
        "/manifest",
        "uses-permission",
        "android.permission.WRITE_EXTERNAL_STORAGE",
        true, true,
        KeyValuePair.Create("maxSdkVersion", "28")
    );
}

internal void RemovePermission(string permissionName)
{
    AddOrRemoveTag(
        "/manifest",
        "uses-permission",
        permissionName,
        true, true,
        KeyValuePair.Create("maxSdkVersion", "1")
    );
}

where I 'remove' permissions by setting the max sdk version to 1. I tried to actually remove the permissions here (remove the XML node) but it gets re-appended for some reason.

@yasirkula
Copy link
Owner

I've seen some screenshots of what I presume the same warning in the past and it wasn't a requirement in those screenshots, only a suggestion. Don't know if they've changed anything but I'd doubt it because these permissions don't take effect until the permission dialog is presented to the user.

Regardless, you can open NativeGallery.aar file with 7-zip or WinRAR (don't unzip, just open it), remove the permission from AndroidManifest.xml inside it and then return to 7-zip/WinRAR. Program'll ask you whether or not the contents of the archive should be updated.

@timbo-tj
Copy link
Author

Hey thanks for the reply! These are 'must resolve' issues reported to us by the Google Review team for app featuring. The permissions they have issues with are

• READ_EXTERNAL_STORAGE
• WRITE_EXTERNAL_STORAGE

and we are required to remove it unless we can show and explain to them why we need them.

We don't want to modify and maintain our own version of this package. I will move forward with the hack where I set the maxSDK version to 1 - this seems to remove the permission from the list of permissions in the App Info page, so hopefully this will satisfy the requirement.

I think if the permissions were added via IPostGenerateGradleAndroidProject callback we could execute our own callback after yours and strip them out ourselves. But (I think) because the permissions are defined in your own manifest they get 'merged in' at a later point and it is too late for me to strip them by then. (Well after IPostGenerateGradleAndroidProject)

Though I am not sure which version of Unity 'IPostGenerateGradleAndroidProject' was introduced in, so it might not be that simple of a change.

@yasirkula
Copy link
Owner

Without declaring the permissions myself, I've seen cases where even setting Write Permission in Player Settings to External (SD Card) wouldn't add WRITE_EXTERNAL_STORAGE permission to the plugin, possibly because another plugin was force deleting that permission. After having to deal with numerous missing permission cases, I've decided to add the permission to the manifest myself. All was well so far since the permissions aren't granted automatically but rather via user consent. In the future, I may need to think of something else as you've suggested.

I'd like to remind you that this plugin seldomly gets updates so if your current hack fails at some point, maintaining your own version of the plugin may still be viable.

@timbo-tj
Copy link
Author

ok, noted! Thanks :) I'll report back with how it goes with the review team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants