breautek commented on issue #561: URL: https://github.com/apache/cordova-plugin-file/issues/561#issuecomment-1717695791
> There is something I'm missing or the plugin should be patched to take into account the Download/ folder? The rules are different depending on the API level of the device. ### API Level 24-28 `WRITE_EXTERNAL_STORAGE` is required for all external storage paths **except** for your application's external data/cache directory. The `Download/` folder is not application specific, so `WRITE_EXTERNAL_STORAGE` permission will be required. This is "pre-scoped storage" rules. ### API 29 Devices specifically Starting with API 29, Scoped Storage rules was introduced. With scoped storage, `WRITE_EXTERNAL_STORAGE` became obsolete, because with scoped storage you no longer need permission to write to external storage. So requesting the `WRITE_EXTERNAL_STORAGE` doesn't grant any additional permissions itself, **however** it does still implicitly grant `READ_EXTERNAL_STORAGE` which is why Cordova still uses for API 24-32. On API 29 specifically, direct filesystem access was disabled, this means you cannot access the external storage via File APIs, which this plugin uses. This is one of the reasons why a media store or SAF plugin becomes necessary. ### API 30-32 Android fixed the limitation of disabling filesystem access to external storage, so we can now read/write to external storage without any explicit permissions (either read or write) using the File plugin API. As a result this plugin will work again, but direct filesystem access has limitations: 1. You can only read/write to files that you (your application) has created. 2. You cannot write to any file that isn't owned by your application. 3. With the `READ_EXTERNAL_STORAGE` permission, you may read **media** files owned by other applications. Media files are limited to: audio, images, and video. 4. Not all paths inside external storage medium is writable, so if you were writing to custom folders before, they may still be inaccessible under scoped storage. If any of these limitations affects you, then a media store / SAF plugin will be required, as they contain APIs to gain temporary permission to a specific file not owned by your app, for both reading and writing. Also note that discovery of files is also limited under scoped storage (e.g. listing a directory). ### API 33+ Not much as changed in API 33, except for that `READ_EXTERNAL_STORAGE` is now an auto reject and instead they have 3 new permissions: - `READ_MEDIA_AUDIO` - `READ_MEDIA_VIDEO` - `READ_MEDIA_IMAGES` Keen eyes will observe that there are only read permissions for the types of media that was supported for reading previously. If you need to read other kinds of files owned by other apps, Media Store / SAF plugin is required. This plugin will request all 3 of those permissions on API 33+ via https://github.com/apache/cordova-plugin-file/pull/566 ### Moving forward Unless if you only support API 30+, a MediaStore/SAF plugin will be necessary for API 29 support. The native Media Store API is not "File API" friendly. It would be incredibly awkward to represent files as directories and files with a traditional File API as this plugin implements, when the underlying storage mechanism is through the MediaStore, because the MediaStore is **not** a File API. So I don't foresee the File plugin turning into a SAF plugin. The file plugin is still useful for managing files inside the internal storage (e.g. the apps private data files). Moving to my own opinions, (e.g. not sure if Apache will agree with this take)... The file plugin can be incredibly simplified by removing support for external storage and just represent file paths as Files, and if it has permission to read/write to it, then it will do it's thing. The file plugin main responsibility should be for managing the app's data files, but not necessary shared files, which is where a SAF plugin will come in to fill that gap. Some other Apache plugins still depends on external storage support via File plugin so those will have to be changed/corrected first, but this is the direction that I'm kinda pushing for. Do note that the native MediaStore concept has been around since API 1... It was always the recommended mechanism for sharing files/content in Android, it was just easier, especially at a generic level to manage files as files. Today, it's no longer easier to manage shared content as files. So generally speaking, if you're operating with the external file system, I'd highly recommend to migrate to a SAF / MediaStore plugin. It will likely provide better stability moving forward. Hope this helps clear things up. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
