yasirkula / UnityNativeGallery

A native Unity plugin to interact with Gallery/Photos on Android & iOS (save and/or load images/videos)
MIT License
1.42k stars 199 forks source link

Remove android permissions #286

Open timbo-tj opened 1 year ago

timbo-tj commented 1 year ago

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 commented 1 year ago

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

timbo-tj commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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