The Storage Access Framework: Counterpoints

Last Friday, XDA Developers ran an article entitled “The Storage Access Framework is the only way for apps to work with all your files in Android Q. And it’s terrible.”. As you might expect from that title, the author rails against the Storage Access Framework. The commenters do as well, by and large.

I agree that the Storage Access Framework API has issues, and I agree with some of the arguments posed in that article. Other arguments, though, seem to reflect the fact that the author develops a file manager, and therefore takes a particular view of Android app development that does not reflect app development in general.

So, let me offer some counterpoints.

With Q, Google is introducing (and requiring) “Scoped Storage,” which makes Android work more like an iPhone, where storage is isolated to each app. An app can only access its own files, and if it’s uninstalled, all its files are deleted.

Note the comparison to the iPhone. We’ll come back to that.

SAF has been available since Android 5.0 Lollipop, but developers tend to not use it unless required, as it has a difficult and poorly documented API, a poor user experience, poor performance, and poor reliability (largely in the form of device vendor-specific implementation issues).

The API for getting a Uri from the Storage Access Framework is fairly trivial. The API for using the Uri is disjointed, with a mish-mash of ContentResolver and DocumentFile being needed if you want something reasonable. And the documentation is limited, but that is fairly common. But once you find the right methods on those two classes, the API is not especially difficult and resembles that of traditional file I/O.

(hey, Yiğit, if you’re reading this: how about a sexy new StorageX library in the Architecture Components? 😃)

The SAF API has gaps, to be certain, such as:

• There is no ACTION_CREATE_DOCUMENT_TREE analog for ACTION_CREATE_DOCUMENT and ACTION_OPEN_DOCUMENT_TREE, leading to some developers to try hacks that prove to be unreliable

• There is no way to specify that we need a read-write document in ACTION_OPEN_DOCUMENT, leading to users getting screwed by Google’s “Audio” documents provider

Performance will be worse than with the filesystem API, but whether it matters for the app will vary — more on this later.

And, ideally, Google would have been doing more from a testing standpoint, such as:

• Writing a conformance test suite, so DocumentsProvider implementations can be easily tested to determine if they comply with expectations; and

• Applying that conformance test suite to any pre-installed DocumentsProvider implementations as part of the Compatibility Test Suite

The most obvious user-facing change with SAF is the experience of granting an app access to storage. For an app to get access, it makes a request to the OS, which then displays a directory chooser screen. On this screen the user selects the root of a folder hierarchy in which that app will be able to read and write files.

Few apps need access to the complete contents of an arbitrary directory on external or removable storage. Many apps do not need access to external or removable storage at all. Many of those that do can get by with just getExternalFilesDir(). And even those that need access to arbitrary content often need just a single file. For this, the resulting UI is not significantly different than the “file open” and “file save-as” dialogs that people have been using in desktop operating systems for decades. Even the dialog that the author decries here is the same as the “choose directory” dialog that desktop users encounter from time to time.

File I/O performance takes somewhat of a hit under SAF, but the most outstanding problem lies in file directory operations, where it’s ~25 to 50 times slower than the conventional file access possible in Pie.

I have not run the benchmarks, but that result does not shock me. There are two rounds of IPC for every SAF API call (your app to the SAF, then the SAF to the DocumentsProvider). That is going to add overhead, compared to doing the same thing with the filesystem.

Few apps will need to do this, though. File managers do, as they are not only working with arbitrary directories on external/removable storage, but arbitrary directories with arbitrary contents. Few apps are file managers or have the storage-access characteristics of a file manager. Plus, this is the sort of thing that the SAF could improve upon over time, such as via more aggressive caching.

An even greater performance issue is that some apps will have to copy files to their local “scoped storage” area before they are able to work with them.

I agree. I have been begging library authors to support streams for years.

Many Android apps take advantage of the amazing number of open-source Java libraries in the developer community, and these libraries commonly require direct filesystem access to work.

The real problem comes from libraries that need random access to the contents of files. Those are basically SAF-resistant and will require data copying. However, some libraries take a File as a parameter, then turn right around, open a FileInputStream, and work with that. Such libraries should be able to accept an InputStream as an alternative to a File, and if they don’t, that could get fixed. For open source libraries, code contributions may be welcome.

Of course, more of these libraries would already have been adapted had more developers asked them to adapt rather than using script-kiddie workarounds to try to avoid using a Uri correctly. Just sayin’.

Google touts the security and privacy benefits of this change, but technically speaking, there is no improvement.

Recall that the author compared scoped storage to the iPhone. Well, in the eyes of the privacy and security experts that I follow, the iPhone is the gold standard, and Android is a trash fire. People hold fundraisers to get iPhones in the hands of at-risk people who otherwise would only be able to afford an Android device. I hope that privacy and security experts will appreciate Android’s move towards being more iPhone-like in this area.

Being able to control storage access on a more granular basis is a fairly massive win. Just because App X needs access to one particular file on external storage does not mean that App X should be granted access to all of external storage. Yet that is what the classic READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions offer.

When you grant an app access to the root directory of your storage via SAF, it can read, write, and send any file it wants to its nefarious developer in the exact same fashion it could when you granted an app access to storage in Pie.

Few apps need access to the complete contents of an arbitrary directory on external or removable storage. Hopefully, users will think through whether they want to grant that right when an app asks for directory access.

There is more work that could be done to improve privacy and security here. For example, Android needs a Settings screen where users can review what durable storage access grants are outstanding and be able to revoke them. Users ought to be able to control whether access is durable or not at the point of choosing the directory (or even how long the permission grant should be, with values between “session only” and “forever”). A warning dialog might be warranted if the user grants durable access to a root directory, to help ensure the user understands the ramifications of that choice.

Ideally, in the long term, most users will get the “gimme access to everything forever” dialog once or twice a year. Hopefully everything else will get handled with things that are more tightly scoped in terms of breadth (e.g., individual files) or time (e.g., access for less time than “forever”).

Some power users are going to get irritated, though. I am not going to deny that.

The only “security improvement” comes about because it’s now a more arduous process for a user to do this.

Users have used file dialogs in desktop programs for decades. It is possible that those dialogs are a cause of global warming or tooth decay or something, but I doubt it.

The official stated reason in the Android Q beta documentation is to “give users more control over their files and to limit file clutter.”

That part of the documentation needs to get fixed. The revisions in Q Beta 3 basically eliminated that rationale.

If Google is truly concerned about giving users more control over files and clutter, they should architect a solution that directly addresses that, rather than falsely branding the current Android Q design as such an improvement.

It is an improvement. It may not be the best possible improvement; there will be collateral damage stemming from this particular approach. And, as I have written about extensively, I think the rollout had loads of issues. But, it is an improvement. And while it may sound hyperbolic, I can honestly say that lives might be saved in the long run by this change.