Slashdot Mirror
Android 5.0 Makes SD Cards Great Again
An anonymous reader writes: Over the past couple of years, Google has implemented some changes to how Android handles SD cards that aren't very beneficial to users or developers. After listening to many rounds of complaints, this seems to have changed in Android 5.0 Lollipop. Google's Jeff Sharkey wrote, "[I]n Lollipop we added the new ACTION_OPEN_DOCUMENT_TREE intent. Apps can launch this intent to pick and return a directory from any supported DocumentProvider, including any of the shared storage supported by the device. Apps can then create, update, and delete files and directories anywhere under the picked tree without any additional user interaction. Just like the other document intents, apps can persist this access across reboots." Android Police adds, "All put together, this should be enough to alleviate most of the stress related to SD cards after the release of KitKat. Power users will no longer have to deal with crippled file managers, media apps will have convenient access to everything they should regardless of storage location, and developers won't have to rely on messy hacks to work around the restrictions."
For a long time, I've been hoping for an OS where, by default, the apps cannot access anything outside of their private areas.
It's possible with chroots and cgroups and other facilities but it's always a mess of third-party after-thoughts.
There's no reason I should have to give my satnav app full read-write permission to the entire SD card just so it can save my favourite places to permanent storage. It shouldn't even be able to know where it's saving them, that's for me to choose.
As such, these are all moves towards a safer, more secure environment. The problem, as always, is what happens in the meantime for the transition or if we mess up and stop apps doing what they need to do. No photo app needs read-write access to the entire SD card, nor can it cope with just read-write access to a private app area. It needs to share the files it writes with the user. Isn't this precisely what the amalgamation of several folders into, say, "Pictures" or "Music" is on several OS? All the app needs to do is say "this is a pictures folder that the user might want to use". And when uninstalled, it stays around because it's still one of the many listed pictures folders for that user.
Gone are the days of full-write-to-everything access. We don't need it. It's not necessary. But we do need the facilities to ensure apps can do what they need to do. This very much pushes into the filesystem-as-a-database idea that we've been wanting for decades. There's nothing stopping an app opening up a separate table for its photos and having the database just join the rows from several tables when the user wants to look at all their photos. And that does not require giving the app access to every table and row in the entire database.