breautek commented on issue #866: URL: https://github.com/apache/cordova-plugin-camera/issues/866#issuecomment-1781106507
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 `file://` URLs and the only way those are readable via file APIs is via those permissions. Natively, these permissions are not required if we use the content resolver via the `content://` uris because the app already has temporary access to the user picked files, but we translate the `content://` paths to `file://` paths to remain compatible with filesystem APIs. Even if we use the photo picker, I assume the native side receives `content://` uris that needs to be translated if it wants to be compatible with file plugin, which will likely introduce the same requirement of needing `READ_MEDIA` permissions which is obviously not good... 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 `READ_MEDIA` permissions via the content/media store APIs and the returned file path to the webview will be an internal storage file path and thus won't hit the SAF restrictions with filesystem APIs. I'm not entirely convinced this is a good idea however because it means copies of files won't be in sync with the actual user gallery, and especially for larger content like videos, copying files can be heavy. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
