We introduced the concept of “partitioned storage” for the first time in Android 10 to protect application and user data and reduce file clutter. Since then, we have received valuable suggestions from developers to help us continue to improve this feature. Thank you very much! Based on the feedback, we made some noteworthy improvements to Android 11. For example, we have enabled direct file path access to media files to improve compatibility with existing code and libraries. We understand that many applications require a thorough plan before adopting a partitioned storage solution in order to continuously support access to existing users, ensure compliance with current storage solution best practices and backward compatibility.

Based on discussions with developers and active discussions in the developer forums, we have prepared this list of frequently asked questions and answers about storage to help you better understand the various capabilities, behavioral changes, and limitations of partitioned storage. We’ve published best practices for Android storage solutions in our previous post, so you can review this best practices article.

Does partitioned storage allow applications to access files using File paths through the File API?

We are aware that some applications directly access the media file path through code or libraries. Therefore, on Android 11, applications that have access to external storage can access files through file paths in a partitioned storage environment. In 10 Android devices, unless by active statement requestLegacyExternalStorage attribute in the manifest to select disable partition storage, otherwise the above method is invalid.

To ensure continuity between Android versions, if your application is targeting Android 10 or higher, you should choose not to enable it. For more details, see the following articles on best practices for Android storage solutions.

How does file path access perform compared to media storage apis?

Performance is highly dependent on application scenarios. For sequential reads such as video playback, file path access performs as well as media storage. However, in the case of random reads and writes, the file path method can be up to twice as slow. For the fastest and most stable reading and writing, we recommend that you use the Media Store API.

My application needs extensive access to shared storage. Is a storage access framework my only option?

The Storage Access Framework (“SAF” for short) is used by users to grant access to directories and files, but it is important to note that SAF still has limitations on some directories, such as the root directory and the Android/ Data directory. While most applications can implement storage access through our best practices, such as using SAF or media storage apis, some scenarios may require more extensive access to shared storage, or best practices may not be available for efficient access. In this case, we have added MANAGE_EXTERNAL_STORAGE permission, which allows applications to access all files on external storage (except the Android/data and Android/obb directories). We released a Google Play policy update in July that mentions storage. Please check out this wechat article.

Which types of applications should apply for the MANAGE_EXTERNAL_STORAGE permission?

The MANAGE_EXTERNAL_STORAGE permission is applicable to core application scenarios that require extensive access to files on the device, but cannot be efficiently implemented using partitioned storage best practices. Of course, it would be impractical to list all possible application scenarios, but they would include use scenarios for file managers, backup and restore, anti-virus programs, or productivity file editors.

Do I need Google Play policy approval to use Storage Access Framework?

Storage Access Framework (SAF) has been around since Android 4.4. When files are accessed through SAF, the user is involved in file selection, giving the user more control over file access. There is no policy regarding this on Google Play.

Are there any other limitations to using SAF on Android 11 compared to Android 10?

Apps that target Android 11 (API level 30) and use SAF will not be granted access to certain directories, such as the root and download directories on the SD card. Neither target SDK can access the Android/ Data and Android/ OBB directories through the storage access framework on Android 11. Visit the official documentation to learn about these restrictions and methods for testing related behavior.

How can an application test for changes to partitioned storage?

With these compatibility flags, applications can test partitioned storage behavior related to direct file path access or media storage apis. There is another compatibility flag that can also be used to test the limitations of accessing certain paths using the Storage Access framework.

Are applications in partitioned storage limited to writing files to their application data directory?

In partitioned storage, applications can add media items to a media storage collection. The media store places files in well-organized folders, such as DCIM, Movies, and Download, based on the file type. For all such files, the application can continue to access them through the file API. Because the system assigns application properties to each media store file, applications do not need storage permissions to read and write to the files they originally provided to the media store.

After Data Column was deprecated, are there any suggestions for other uses of this feature?

On Android 10, applications in a partitioned storage environment cannot access files through file paths. In keeping with this design, we subsequently scrapped the DATA Column. Based on feedback that you need to use existing native code or libraries, Android 11 now supports application access to file paths in partitioned storage. Accordingly, DATA columns can actually be useful in some situations. To insert and update in the media store, applications that use partitioned storage should use DISPLAY_NAME and RELATIVE_PATH columns, which no longer require DATA columns for this function. When reading a media store instance of a file on disk, the DATA Column will have a valid file path that can be used by the file API or NDK file library. But applications should be prepared to handle any I/O errors associated with such operations, and should not assume that files are always available.

When do applications that opt out of partitioned storage have to be compatible with partitioned storage?

On devices running Android 11 or later. When the target version is set to Android 11 or higher, the application is put into partitioned storage.

What method is recommended for migrating data outside of partitioned storage?

PreserveLegacyExternalStorage tag allows the application to upgrade system keep original storage access, even to upgrade to the Android 11. Note that this tag has no effect on newly installed apps on Android 11. Before setting the target version to Android 11, modify the code to accommodate partitioned storage. For information on best practices for data migration, see the reading best Practices for Android storage solutions at the end of this article.

Are there any exceptions to the Android/ OBB directory that some package installers (such as the app Store) need to access?

Applications with the REQUEST_INSTALL_PACKAGES permission can access the Android/ OBB directories of other applications. Note that this permission has signature level protection.

We hope this FAQ will help you plan to adapt partitioned storage. Please read the original article or see the related reading article at the end of this article to learn about our best practices documentation.