Hi Team,
I want to discuss a proposal of rather significant change to the file
plugin. This is something
I've already discussed over the last couple of months privately with a
couple of others, but
with the announced that the newer READ_MEDIA_* permissions now will
require justification,
I think it's time to get a formal community opinion.
In short, I want to start saying that the file plugin no longer supports
external storage paths. Here is why.
1. API 29 doesn't support the external filesystem whatsoever when scoped
storage is enabled. API 29 only supports interacting with the external
filesystem when interfacing with the MediaStore APIs. Direct File access
via File APIs is completely blocked. Supporting for File APIs was only
added in API 30 via FUSE[1].
2. Even with FUSE on API 30 and later, Direct File access via Flie APIs
are limited to reading images, audio and video files. Documents or other
kinds of files are restricted. Additionally writing to files is also
restricted. The only exception to this rule is if your app owns the file.
3. Currently the file plugin will use READ_MEDIA_* if declared, but it
doesn't do any permission declaration itself. So it can be said this is
a opt in. It however attempts to request all 3 permissions[3] which will
be problematic. If the app only details with audio, it doesn't need
IMAGES or VIDEO permission and definitely won't have the justification.
We do have these restrictions documented on the File plugin README[2].
For API 24-28 devices, we also do not need `READ/WRITE_EXTERNAL_STORAGE`
permissions to write to the app's external data directory, which was a
change that as introduced back in API 19. These permissions were only
necessary to read/write in other external filesystem directories.
Introducing MediaStore interface into the file plugin is likely not
feasible either. The android docs acknowledges the challenges in
rewriting File APIs to a MediaStore API and that is the whole reason why
they introduced the FUSE concept for API 30+ devices.[1]
> This restriction impacted app developers' ability to adapt as it
required substantial code changes to rewrite File API access to the
MediaProvider API.
So what does it mean to say the external filesystem is not supported?
1. Usage of internal filesystem remains unchanged.
2. File plugin will no longer use or attempt to request permissions for
external storage.
3. It will be theoretically possible to still use external filesystem
url and read/write to it, if the app has the permission declared &
granted by that permission grant would be an external factor.
4. It will also be theoretically possible to still use the external file
system on API 30+ devices without any permission, provided they are not
attempting to write or overwrite an existing file owned by another
application.
At the end of the day, due to the API 29 caveat, using the external
storage via Filesystem API should be completely discouraged unless if
the app only supports API 30+ devices.
Lastly, because READ_MEDIA_* permissions will require justification
starting August 2024, we also need to stop using the `READ_MEDIA`
permissions by default in other plugins, including camera and
media/media-capture. Which means our other plugins that depends on the
file plugin shouldn't be affected by this proposal, once they have been
updated in a way that they won't depend on these permissions.
If the user requires external storage compatiblity, there are
third-party community plugins available that interfaces with the
MediaStore APIs and this should be the preferred approach:
https://www.npmjs.com/search?q=ecosystem%3Acordova%20storage%20access%20framework
Applying this proposal will allow us to greatly simplify the android
plugin code as well as the documentation by removing all the caveats
related to using external storage and we can make it clear that the file
plugin should only be used for internal data storage.
If we do decide to move forward with this proposal, I'd also recommend
adding in deprecation notices and creating a blog post with the intent
of removing external storage support. This should give developers ample
time to migrate to a media store plugin if they haven't already done so.
Please let me know what are your thoughts and whether if you support
this direction for the file plugin.
Cheers,
Norman
Breautek
[1]
https://source.android.com/docs/core/storage/scoped#using-scoped-storage-with-fuse
[2]
https://github.com/apache/cordova-plugin-file#androids-external-storage-quirks
[3]
https://github.com/apache/cordova-plugin-file/blob/265a932f3b5d11739fd08c0437477f441f6212c7/src/android/FileUtils.java#L539
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
