breautek commented on issue #599: URL: https://github.com/apache/cordova-plugin-file/issues/599#issuecomment-1695957795
I have a PR to expand on the docs. Android's external storage (all `cordova.file.external*` constants) have several limitations especially surrounding Filesystem APIs. https://github.com/apache/cordova-plugin-file/pull/593/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R181 TL;DR; you'll probably need to migrate to use a [media-storage](https://www.npmjs.com/search?q=ecosystem%3Acordova%20storage%20access%20framework) plugin, as hinted in my documentation PR. Basically on any external storage partition access is limited to: 1. Read/write to files that is owned/created by your own app 2. Reading **media** files created by other apps with the appropriate permission. Media files are limited to Audio, Video, and Images. Pre-API 33 requires `READ_EXTERNAL_STORAGE` permission, while API 33 and later requires `READ_MEDIA_AUDIO`, READ_MEDIA_VIDEO`, and `READ_MEDIA_IMAGES` permission respectively. 3. Other kinds of files such as document files are **NOT** readable using any filesystem API unless if the file is owned by your application. Additionally, file API access to external storage requires API 30+. These Scoped storage limitations however are effective on API 29, so specifically on API 29 external storage is not accessible via filesystem APIs. For these reasons, if you use external storage, you'd probably be better to migrate to using a plugin that interfaces with the media store API, which allows for temporary read/write access to specific files as needed. The `File Manager` app can see and probably even read/write to those files because it would have the `MANAGE_EXTERNAL_STORAGE` permission, which is a protected and justified permission. If you declare and try to use this permission, google will expect you to justify why you need it, which is generally reserved for file managers or anti-virus like apps. (Paraphrasing from google docs) It sounds like in your case, your app created some kind of folder structure of data files inside external storage, and after "migration" from one device to another, these files probably got created by the app responsible for the migration, and thus is no longer owned by your app, which due to scoped storage, read/write access is blocked by filesystem APIs. This is also why the issue "corrects" itself if these data files are deleted and the app redownloads and stores them, since it's the app that's doing the writing, not your migration app/process. > What directory does cordova.file.externalDataDirectory actually write to? It depends. If the device has a physical storage device attached, then this is usually `/sdcard/<app-id>/files` (Not 100% sure on the full path but the `/sdcard/` is right) If the device has no physical storage device attached, then the path is generally `/storage/emulated/0/<app-id>/files` `0` directory refers to the user id, which is usually `0`, but if you're using a corporate multi-user device, then this number might be different. -- 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]
