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
Allow using Android photo picker instead of READ_MEDIA_IMAGES and READ_MEDIA_VIDEO #866
Comments
It's on our radar, we just not sure how we should deal with it yet... The photo picker is obviously one path, but given that this plugin utilises the Camera intent I'm not sure if it's a good fit here. If I recall correctly through the camera intent the user can already choose from a gallery implemented by the camera app... but I could be wrong on this detail, I'm not entirely familiar with the camera code base. Currently the ultimate reason for the READ_MEDIA permissions is because camera returns external storage Even if we use the photo picker, I assume the native side receives What would solve this problem is if we copy the granted file into the app's internal cache so the app has it's own version of the picked file. The native side can do this without requiring |
I think the developer need to think the approach of using photo picker and move away from READ_MEDIA. The reason I think this way is because Google now enforcing app that provide personal finance app cannot have that permission. Since my organization work on such app, we can no longer use this plugin as it is because it need that permission to work. Appealing to Google doesn't work at all. However, I am still looking forward on this plugin to move away from the permission. Maybe in distant future it will. Cheers. |
I too have a commercial app that depends on occasional photo access - it is unlikely be allowed under the new (future) google restrictions. The suggested photo picker direction would be the best solution for my use case. |
Aren't media access permissions also needed when using |
If we only use |
I think I was inaccurate on my detail earlier... It seems like the camera plugin when capturing an image from the camera hardware, the native side will use the content uri and copy the image to internal storage partition, and the file URI returned is a path to internal storage. In this case, the READ_MEDIA permission isn't necessary. However I believe you're right, if the image is sourced from the photo album, it returns the external storage file uri to that resource which does require READ_MEDIA permission. It does appear that the file plugin has some support with content uri paths via ContentFilesystem. I'm thinking the best path forward is to see if that class actually works as expected and to maybe start experimenting with In general, if working with content urls more closely does work, it will probably make the file plugin a bit more powerful since content urls can represent data not necessary on the user's disk, but from a remote source (e.g. Google Drive).
READ_MEDIA permissions is necessary when trying to use the Filesystem API (via file plugin) or the native On the other note, |
@breautek Thanks for your reply. I tried modifying the source code and removed the code that requests permissions, and it seemed to be no problem amazingly. |
Feature Request
Motivation Behind Feature
On August 31 2024, a new Google policy will take effect to restrict the usage of READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions. These permissions are used by the Camera plugin.
Google recommends using the Android photo picker in apps where it's not frequent to access these files. It would be great if this plugin allows using this photo picker instead of the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions.
Feature Description
If Android's photo picker works fine for all use cases of the plugin, then it would probably be better to remove all usage of READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions and use the photo picker instead.
If the permissions are still needed for some cases then we should probably need a parameter or preference to pick how do we want to get the media files: either using the permissions or using the picker.
The text was updated successfully, but these errors were encountered: