Over the last few years, few topics have been more hotly contested by Android users and developers than how SD cards are handled by the OS. Back in February, I discussed some of Google's changes during the transition from Android 2.3 to 4.0, and then how more recent policy changes ultimately led to 3rd-party applications losing most of their access to removable storage. By the time I/O came around, Google acknowledged that KitKat's newly added Storage Access Framework still didn't offer enough range for apps to get their work done. With the release of the L Developer Preview, new APIs were added to allow apps to request access to directories owned by other providers. Now that Android 5.0 Lollipop has been finalized, these APIs have been improved and even offer more capabilities than before, and they do it in a very user-friendly and secure way.
Richer access to secondary shared storage devices
In KitKat we introduced APIs that let apps read/write file in app-specific directories on secondary storage devices, such as SD cards.
We heard loud and clear that developers wanted richer access beyond these directories, so in 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.
This gives apps broad, powerful access to manage files while still involving the user in the initial selection process. Users may choose to give your app access to a narrow directory like “My Vacation Photos,” or they could pick the top-level of an entire SD card; the choice is theirs.
There aren't a lot of changes to this functionality since the announcement at Google I/O. The Storage Access Framework (SAF) already gave 3rd-party apps the ability to ask for access to a single file or whole directories (including sub-directories). The important detail is mentioned at the end, which is that this can now be used to give total SD card access to an app. Once the decision has been made, apps won't have to request access ever again, and all future operations can occur seamlessly. This finally puts users in charge of which apps can access different parts of device storage, and it's basically painless.
That wasn't the only addition regarding storage. Apps that deal heavily in photos, music, and video are prone to filling up space very quickly, and as a result, they may need to push their content to the SD card. KitKat didn't necessarily handle this very well, because the content still had to be placed inside of private folders and inserted into the MediaStore manually. A new method simplifies the process by generating a folder that is essentially open to the public, while still keeping it tied to the app that created it.
Also worth noting is the new getExternalMediaDirs() method that gives you a place for your own files on any available secondary storage, without needing to request read/write permissions: https://developer.android.com/reference/android/content/Context.html#getExternalMediaDirs()
If an app places a file into a folder returned by getExternalMediaDirs, it is essentially available to any other application to access via the MediaStore service. This will be great for something like a camera app or sound recorder, because now the files they produce will be automatically available to every other app without any hassle. This method will also resolve some complications that resulted from removing and reinserting SD cards. Additionally, since the method of access goes through the MediaStore, apps that would consume these files won't even have to be updated for the latest SAF. Of course, they probably should be, so they can also request files that are only available through that method.
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. Of course, these features are still specifically a part of Android 5.0 (and above), so it'll be a while until these benefits can truly materialize. At least we can all rest easy knowing that the future of Android does not involve dooming the SD card to obscurity – it's actually balancing usability and security.
Source: Android Developer Portal