The Death of External Storage: But Why?
Under the fairly innocuous title of “scoped storage”, Google has announced that external storage, as Android developers have used it, effectively is dead, for Android Q and onwards.
I am going to spend some time on this over the course of the week, as this change needs some attention:
- Monday, I described what has changed and what you are supposed to use.
- Tuesday, I covered the limited options for actually getting a file on external or removable storage.
- Yesterday, I reviewed how you might still wind up with references to files… that you cannot access
- Today, I’ll offer some guesses as to why all of this is going down
Android 4.4 locked down removable storage and introduced the Storage Access
Framework. Android 7.0 added FileUriExposedException to try to steer developers
away from file:// Uri values. Now, Android Q blocks access to most portions
of external storage.
So, why?
Here are some possible reasons. Note that I have no inside information, and so these are educated guesses, nothing more… except for the first one.
The Official Reason: Clutter
Quoting the Q release notes: “To give users more control over their files and to limit file clutter, Android Q changes how apps can access files on the device’s external storage.”
Perhaps Marie Kondo visited the Googleplex. I hope that the Android statues sparked joy.
UPDATE 2019-03-29: Sebastiano Poggi pointed out that indeed Ms. Kondo did present at Google, back in 2015.
Jokes aside, I can see arguments for this reason. I have complained about developers creating
app-specific directories or files at the root of external storage for years.
That behavior is roughly analogous to Windows programs putting stuff in the
root of the C: drive, and Microsoft got developers away from that quite some time
ago, in part due to clutter. So, it is not shocking that Google would make moves
in this area.
However, locking down all of external storage seems excessive to support this reason. Locking down the root of external storage might have sufficed.
The Preferred Reason: Privacy and Security
Let’s face it: Android’s security reputation is in tatters. If you pay much attention to the infosec community, you’ll know that Android is not well-regarded.
Part of the problem has been data promiscuity. Even with the advent of runtime
permissions in Android 6.0, lots of apps still requested READ_EXTERNAL_STORAGE
and WRITE_EXTERNAL_STORAGE. Those apps have complete run of external storage,
including examining files created by other apps.
So, for example, without locking down external storage the way they did, Google
had little ability to prevent apps from scanning the user’s photos and looking
for geotags. Coupled with FileObserver, this could serve as a rough-cut way
of occasionally getting the user’s current location. And just examining the
historical photos could be illuminating. If lots of photos are taken over a long
span of time in the same geographic area, it is likely that the user lives
there and is taking pictures of local places and events.
Privacy and security experts have complained for years and years about this sort of app behavior. Most likely, the external storage lockdown is there in part to address these concerns.
The “Google Über Alles” Reason: Promote Cloud Storage
The leading API for accessing external storage now becomes the Storage Access Framework. One feature of the Storage Access Framework is that it treats local and remote storage as the same, with a consistent API for both. Your app does not really care whether the content that it works with is local or remote — your app just cares about reading and writing that content. With the Storage Access Framework, your app can focus on the content, and the user can work with documents providers to arrange to get you the desired content, no matter where it resides.
Of course, Google would like for it to reside on Google Drive.
The Storage Access Framework means that the Google Drive option is presented to the user on every storage access request, at least for those users who have set up Google Drive for their device’s Google account.
This is not a Google-exclusive thing. Compared to other things, like push
messaging, offering a cloud-based DocumentsProvider is something anyone can
do. The API is a bit arcane and suffers from limited documentation, but we can
say that about quite a bit of Android. Other cloud storage providers can appear
alongside Google Drive, if those providers choose to implement a DocumentsProvider.
However, outside of some manufacturer-specific deal, the only pre-installed
provider is Google Drive, so it gets a bit of premium placement as a result.
The James Tiberius Kirk Reason: Enterprise Support
(with my hairline, you might have thought this would be the Jean-Luc Picard Reason, but I’m honoring the classics today…)
Enterprises run on networked file servers. Windows has long had more-or-less
first-class integration of file server-based storage for a very long time.
The most flexible way for Android to support that is through a DocumentsProvider-based
API (as opposed to lower-level Linux-based options). So, it is possible that
closing off of external storage is being done in part to promote Storage Access
Framework adoption, with an eye towards enterprise storage along with cloud storage.
The Current Compatibility Reason: Chrome OS Integration
Chrome OS is locked down tight as a drum. That’s why when Android apps were
added as an option, you had a lot of visible seams in the integration. Perhaps
none were bigger than storage, where the only shared location between Chrome OS
and Android is the Downloads/ directory on external storage. The rest of
Android’s external storage has been inaccessible to Chrome OS.
Perhaps the external storage lockdown in Android Q is to make it easier for Google to more tightly integrate how Android apps and Chrome OS apps perceive local device storage.
The Future Compatibility Reason: Fuchsia
Let’s assume for the moment that Fuchsia is real and it is spectacular.
If Fuchsia represents Google’s longer-term OS, it stands to reason that some of the recent Android changes — such as the external storage lockdown — are being made to improve compatibility with Fuchsia. If Fuchsia will run Android apps, then Google once again has the integration issues that they ran into with Chrome OS.
Perhaps the external storage lockdown is being done with an eye towards how Fuchsia apps work with local device storage.
These are mostly speculation. I doubt that we will ever get much more than the official “clutter” reason for this change. But this list shows that Google has plenty of justification for this move, no matter how painful it may be for developers (and, to an extent, users) in the near term.
Tomorrow, I will wrap up this blog post series by wondering why this predictable change still seems to have caught developers by surprise.
