Storage Access Framework in Android 13

Storage Access Framework is first introduced in Android 4.4, but has come a long way, and has hugely improved in Android 13. Users can easily browse and open documents, photos, and other files from any of their favorite document storage providers thanks to the SAF. Users may browse files and access recent consistently across apps and providers thanks to a common, user-friendly UI. In this article, we will know how to use the SAF to traverse through databases in your user’s device in a breeze and pull up the relevant information quickly.

How does the Storage Access Framework Work?

By putting in place a DocumentsProvider that wraps their services, cloud or local storage services can take part in this ecosystem. With just a few lines of code, client apps that require access to a provider’s documents can interact with the SAF.

Components Baked in the Framework API

The following components are part of the Storage Access Framework, we will look at each of them in detail, and discuss them in detail.

1. Document supplier: A content provider who makes the files that control access to storage services (like Google Drive). A subclass of the DocumentsProvider class is used to implement document providers.
   Although the physical storage of your document provider’s data is left to you, the document-provider structure is based on a conventional file hierarchy. 
2. Event Handler: The Android operating system comes with a number of integrated document providers, including Downloads, Images, and Videos. ACTION_CREATE_DOCUMENT, ACTION_OPEN_DOCUMENT, and ACTION_OPEN_DOCUMENT_TREE intent actions are invoked by a client app, which is a customized app that also receives the files that document providers return in the response.
3. Picker—A system user interface that enables users to access documents from all document providers that meet the search criteria of the client app.

Advantages of using the Storage Framework

Although the framework is of versatile usage, we will look at the key places where it can help us to yield better results. We will then discuss each of them in a brief manner.

1. Enables your app to have persistent, long-term access to documents that belong to a document provider. Users can add, edit, save, and delete files on the provider using this access.
2. Allows users to explore material from multiple apps, not just one.
3. Supports a number of user accounts as well as temporary roots, such as USB storage providers, which only appear when the drive is plugged in.

Understanding the architecture of the framework

We will look at how things work in the SAF, also we will be looking at the structural diagram after discussion to better understand the architecture.

• Each storage backend exposes certain files and directories by using a different COLUMN_DOCUMENT_ID to identify them. Since they are utilized for persistent URI grants across device reboots, document IDs must be distinct and remain constant once issued.
• The MIME type of a document can either be an openable file with a certain MIME type or a directory with further documents (MIME TYPE DIR).
• The capabilities of each document can vary, as indicated by COLUMN FLAGS. FLAG_SUPPORTS_WRITE, FLAG_ SUPPORTS_DELETE, and FLAG_SUPPORTS_THUMBNAIL are a few examples. It is possible for COLUMN_DOCUMENT_ID to appear in numerous directories.
• Every document provider reports one or more “roots,” which serve as entry points for perusing a document tree. A document (a directory) that represents the contents beneath each root is identified by a unique COLUMN_ROOT_ID. To accommodate use cases like numerous accounts, temporary USB storage devices, or user login and logout, roots are dynamic by design.
• A single document is found under each root. Each document that this document points to has the potential to point to one to ‘n’ more papers.

GeekTip #1: If you want your app to have continuous access to documents owned by a document provider, use the ACTION_OPEN_DOCUMENT method

The document provider data model is founded on a conventional file structure, as was already mentioned. Anyway, as long as you can retrieve your data using the DocumentsProvider API, you can store your data however you wish physically. Here is the block diagram which explains in brief how the document is actually structured when you use the Storage Access Framework:

Image #1: Understanding the Architecture of File Storage in SAF

Precautions to take while using the SAF

1. Providers and clients do not speak to one another directly in the SAF. A client requests authorization to access files (that is, to read, edit, create, or delete files).
2. When an application (in this case, a photo app) triggers the ACTION_OPEN_DOCUMENT or ACTION_CREATE_DOCUMENT intent, the interaction begins. Filters can be used in the intent to further narrow the requirements, such as “give me all openable files that contain the MIME type “image”.”
3. The system picker visits each registered provider after the intent triggers and displays to the user the appropriate content roots.

GeekTip #2: If you want your app to merely read or import data, use the ACTION_GET_CONTENT method. The software imports a copy of the data using this method, such as an image file.

Conclusion

File and transfer access have come a long way, and have always been a vital part of the overall android system and any operating system out there, however time-to-time certain improvements always find their way in newer Android Versions. The Storage Access Framework (SAF) is such a new addition, which will make the work of developers easier over the coast, hope this Geeks for Geeks article helped you learn how to structure and store your files in a user’s device and how to access it accordingly.