Intent to Ship: File System Access on Android and WebView
Joel Hockey
Spec
https://wicg.github.io/file-system-access/
Summary
This feature has been supported on the 4 other platforms since M86 and will now be supported on the remaining 2 platforms.
Android platform and its use of Intents rather than file choosers, and content-URIs rather than posix-style paths and semantics provides some challenges, but the intention is that existing code such as the demo link will work unchaged for users to read and / or edit files.
There is one area where I am considering proposing a change to the spec that showOpenFilePicker() could take a boolean hint to indicate the intention of whether files are intended for read-only vs writable which would allow Android to choose between Intent GET_CONTENT (read-only, but supported by more providers) vs OPEN_DOCUMENT (allows for writing to files, but not supported by as many providers).
Original Chrome Status:
https://chromestatus.com/feature/6284708426022912
Original Intent-to-Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/9Fcpl2KVfbk
Link to “Intent to Prototype” blink-dev discussion
See Original Intent-to-Ship
Link to Origin Trial feedback summary
See Original Intent-to-Ship
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
It is now.
Demo link
https://file-system-access-demo.glitch.me/
Debuggability
See Original Intent-to-Ship. Devtools is a little more challenging on android, so I would expect most devs would debug their code on one of the other 4 platforms, but devtools can still be used.
Measurement
Risks
Interoperability and Compatibility
This spec is already proven. Support for the remaining 2 platforms only improves interoperability and compatibility.
Ergonomics
Android uses Intents where other platforms use a file-chooser. The common intents to open a file are GET_CONTENT (read-only, but supported by more providers) vs OPEN_DOCUMENT (writable files, but not as many providers). As stated above, I am considering proposing a change to the API to give JS code control over this.
Android files (content-URIs) do not support atomic writes, or atomic renames. As such, not all operations will be supported, or some operations like move will be implemented as copy. I am in discussion with the Android storage team about what can be possible in the future, but any changes will take time (years).
Activation
Developers already have code using this.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes, but chromium project does not currently run WPT for android.
https://wpt.fyi/results/file-system-access
Entry on the feature dashboard
https://chromestatus.com/feature/6284708426022912
Thomas Steiner
There is one area where I am considering proposing a change to the spec that showOpenFilePicker() could take a boolean hint to indicate the intention of whether files are intended for read-only vs writable which would allow Android to choose between Intent GET_CONTENT (read-only, but supported by more providers) vs OPEN_DOCUMENT (allows for writing to files, but not supported by as many providers).