breautek commented on issue #568: URL: https://github.com/apache/cordova-plugin-file/issues/568#issuecomment-1635875461
I'm going to shed some more light now that I've understand more about the Android scoped filesystem since the last post in May. Short answer is unfortunately I don't think the issue is resolvable by the plugin, and you'll likely need to use another plugin that interfaces MediaStore API rather than the File API. Long answer with history... #### History In API 29, Android introduces a system called Scoped Storage, however on API 29 devices for apps already published to the app store had the ability to opt out to the legacy system via `requestLegacyExternalStorage` flag. The legacy system gave apps free reign over external storage for as long as `WRITE_EXTERNAL_STORAGE` was granted. #### Scoped Storage (API 29-32) Scoped Storage makes the `WRITE_EXTERNAL_STORAGE` permission obsolete as apps have the ability to write to external storage without permission now, but they cannot write to a file that already exists if the file is owned by another app. Apps can also read from external storage without permission but visibility is limited to files only owned by your own app. `READ_EXTERNAL_STORAGE` will grant you to read media files, but not documents. #### Special Notes for API 29 On API 29 **specifically**, android **does not** have a File API bridge to Scoped Storage framework. This means if `requestLegacyExternalStorage` is not enabled, or if you have a brand new app that isn't published to the app store, **all** file APIs will fail to access external storage. In API 30 and onwards, Scoped Storage framework is forcefully enabled. Only in [API 30 and onward](https://developer.android.com/about/versions/11/privacy/storage#media-direct-file-native), Android has implemented a File Bridge to allow File APIs to access content in external storage, allowing File APIs (and this file plugin) to somewhat work again. It also means this plugin **will** not work at all on API 29. It's important to note that even with these file based APIs enabled once again, they only have access to media files. > To help your app work more smoothly with third-party **media** libraries, Android 11 allows you to use APIs other than the [MediaStore](https://developer.android.com/reference/android/provider/MediaStore) API to access media files from shared storage using [direct file paths](https://developer.android.com/training/data-storage/shared/media#direct-file-paths). Paths like Documents or Downloads are not readable except for media files (images, videos and/or audio). In order to read non-media files, MediaStore API must be used. #### What is the MediaStore vs File APIs To the non-android devs that might be reading this, I'll write a quick explanation on the MediaStore API vs File API. The File API, is kinda what it sounds. It's a pretty standard filesystem oriented API where you operate on directories and files and you're able to stream data in and out of it. The API offers full programmatic control over the filesystem. MediaStore API is **not** a filesystem-oriented API. it's more like a database with a query system. The filesystem details is abstracted and you don't have programmatic control over the filesystem structure, and in some cases you have limited discoverability of files. It's a privacy-focused API so it comes with many restrictions. For example, you generally cannot programmatically read the list of files that may be present on the device. Rather you'll need to open an `Intent` (e.g. a file picker) where the user selects the file then, and only then your app can become aware that file exists. Attempting to use the MediaStore in a "file-like" API fashion as this plugin implements I don't think is feasible. Which is why I think a different plugin is required to properly handle accessing external storage on Android. #### Notes on API 33+ `READ_EXTERNAL_STORAGE` is now obsolete. It's still required to support API 32 and earlier, but on API 33, we have 3 new permissions: - `READ_MEDIA_AUDIO` - `READ_MEDIA_IMAGES` - `READ_MEDIA_VIDEO` You'll notice we still don't have a permission for docs, so we cannot "discover" documentation. We can only open docs via a system file picker intent, like in previous android versions and only if the app that owns the document has a content provider implemented to grant third-party apps access to their document files. #### Notes on MANAGE_EXTERNAL_STORAGE Permission With the introduction of scoped storage, Android introduced `MANAGE_EXTERNAL_STORAGE` that I believe effectively gives you free reign over external storage similar to the legacy system. However this permission is protected and requires justification. Google will not allow any app with this permission be published to the app store unless if they have a very good reason to use it. An example of that the primary focus of your app is a file manager app, or an anti virus app. Therefore majority of users cannot take advantage of this permission. So with all that being said, I kinda foresee external storage support being stripped out in favour for a media store oriented plugin, however that is yet to been discussed at the Apache development level... [https://www.npmjs.com/package/cordova-plugin-saf-mediastore](cordova-plugin-saf-mediastore) is one plugin I've heard people had success with, but this isn't an endorsement and I'm not familiar with the NOPL license. So do your own research. -- 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
