Do you really need the `READ_EXTERNAL_STORAGE` or `WRITE_EXTERNAL_STORAGE` permission?

Android Apps are one of the most common source of data breaches and scams, and if your app is still requesting for READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permission in 2025, you need to seriously re-think your approach.

Introduction : Understanding the interaction between Apps and User memory

90% of the apps on play store are doing some kind of read/write/view operation using user’s files:

Case 1 : Food Delivery Apps:

• A food delivery app wants to let user pick an image from their memory and render it on screen . This is a case of “Picking”(i.e Reading) Images From Memory.

Case 2 : Social Media Apps :

• A famous Job Platform lets users pick image/PDFs etc from user memory and share them as posts to community. This is a case of “Picking” Images/PDFs/Other Files From Memory.
• It also allows Downloading other people’s images/PDFs to user memory . This becomes a case of Writing Images/PDFs/Other Files to user’s permanent location.
• Sometimes they also allow immediate viewing(“downloaded abc_resume.pdf open”), which would come under Opening Media Files using User’s Apps.
• Another most common use case is allowing user to share some media file to other apps . This would come under Sharing Media Files to other Apps

Case 3 : Insurance Apps

• Like other apps, an insurance app would allow its user to pick image from system and set it as profile picture : Case of “Picking”(i.e Reading) Images From Memory.
• When a user policy PDF is generated, it is rendered inside the app, but if user wants to quickly access it in their file manager, the insurance apps lets user save this file in memory : Case of Saving File to User Memory
• During Claim filing, user should be allowed to preview their submitted documents : Case of Opening Media Files using User’s Apps.
• On Claim completion, user should be allowed to share their settlement documents directly : Case of Sharing Media Files to other Apps

 

Various use-cases of how different apps interact with user memory

 

The Problem : Requesting Broad memory access and risking vulnerabilities

Traditionally, Implementing use cases like these would require storage access runtime permission:

1. User will click on CTA to download/share file
2. The code will trigger a system popup for users to grant READ_EXTERNAL_STORAGE &/or WRITE_EXTERNAL_STORAGE permission
3. on receiving permission , your app is now a Security nightmare , as it now has full access to read/write all the files on user memory:

• Overexposed Data : Even if the app wanted just a single image, it got access to all storage, thereby allowing access to user’s private files that had nothing to do with their functionality.
• Security Risks : Malicious apps could steal private files, such as personal documents or private photos.
• User Trust Issues : When users see a vague prompt like “Allow this app to access your photos, media, and files?”, many would blindly declined (blocking functionality), thereby creating a poor user experience and distrust toward apps in general.
• System Considerations : Starting Android R (SDK version 30), requesting for these permissions have no effect. User will also see a different popup . Moreover, Google discourages the use of these permissions and have begun heavily restricting apps on play store that raise this permission without a valid reason

If your app shows this popup, your user base is likely to decrease soon

 

The Solution : Storage Access Framework and Media APIs

Storage Access Framework (SAF) and media APIs is the Google’s response for tackling all the above issues. This framework provides a privacy-first approach to file access, ensuring that apps can work with user files without requiring broad, intrusive permissions:

• Granular Access Control: Users explicitly choose which files or folders your app can access through the SAF document picker. This can include files from the device’s storage, other apps (via File Providers), or even cloud storage providers like Google Drive.
• Privacy by Design: Your app receives access only to the files the user selects, rather than unrestricted access to the entire device storage.
• Flexible Saving Options: When saving media files, your app can let the user choose the exact location — whether that’s internal storage, an SD card, or a cloud-backed directory — instead of writing files silently in the background.

https://developer.android.com/guide/topics/providers/document-provider

 

Working

Lets dive directly into the code to understand how our apps can utilise the Storage Access Framework and Media Apis to provide a seamless and privacy focused experience

1. Reading Files from User memory without Requesting Permissions

Reading a file from user’s memory is very simple. User taps on a button, sees a file picker and selects a file. The app receives the file and does its operations on it: render to screen, save to database, etc.
In terms of code, the operation that has to be performed after the file is picked needs to be defined before hand.

Press enter or click to view image in full sizeSAF Document Picker in Action

1. Define the filePick launcher and what happens after the file is received:

2. On user action, request for file from SAF:

Some Notes

1. Since the file picker returns a temporary content uri, we cant store it directly in our db as a string. instead we should either consume its bytes directly or save it in a local file in our app’s specific memory, so that it can be accessed by app in the long term.

2.Since The file will loose any associated metadata once converted from Content uri to local file uri, you can extract out the information beforehand and store it

3. It is advisable to use different launchers for different kind of file selection. but you can have a single file picker as well. Checkout this repo for a demo

2. Writing Files to User memory without Requesting Permissions (SAF and Direct)

Writing files again requires a System result launcher (ActivityResultContract.CreateDocument) for storing files. However we can even improve on this behaviour in certain android versions!

1. User presses the CTA .
2. The result launcher opens a System picker for user to choose a file location and name.
3. On pressing save, the system picker returns a Uri to our code. We need to now write our local document to this location
4. For android Q and above, there is no SAF Path Selector required if your app intends to save a file to certain common directories like Downloads , Pictures etc. So if your usecase allows this, you can directly save the file to user’s location without needing an intermediate screen!

Saving a user file in action

Code

1. Define a Create Document Launcher

2. On user button press, launch the system path selector. Note that The actual file is not passed to path selector during this step, but you need to store it somewhere for accessing the file later.

The only thing that you can pass to selector at this step is a suggested name

3. if user’s android version is greater than or equal to Android Q, we can skip the launcher completely and directly store it in user’s download directory

Some Notes

1. While doing a write operation, always use threads or IO dispatchers as these operations can block main thread for a long period of time
2. Getting a bitmap from image-view (android view):

3. File to bitmap :

4. Save image bitmap/file to user selected path :

5. Save image bitmap / file to public directories :

3. Opening Content Uris without any permission

If you have a content Uri that you want some other app to open (like zip file or a video file), you don’t need to define anything in your code, a simple launcher intent will work.

However, this only applies for Content Uris (i.e the original uri received from SAF

4. Sharing Local Files without any permission

If you want to share your local file to other apps for viewing/editing etc , you need to declare your app as a file provider. Other apps can not read the file present in your file path unless your app declares this.

1. In Manifest, add a file provider.
2. In res/raw/ folder, create a file listing all your internal file paths from where your local file could be accessed.
3. Finally on user cta press, share the file.

Closing Remarks

If you have read the article till here, I appreciate your attention . You will find all the resources and code snippets in the above repo attached (for both jetpack compose based screens and XML based screens)

Storage is one of the most sensitive parts of a user’s device, and how your apps interacts with it speaks volumes about your respect for privacy.

By adopting SAF and Media APIs, you not only keep your app future-proof and compliant but also show your users that their trust matters to you.

It’s a small change in code, but a huge step toward a safer Android ecosystem. I keep sharing

Let’s Connect

If you’re working on Android storage, privacy, or App Modernisation — or if you know of opportunities where my skills could be a fit — I’d love to chat. You can reach me at my Email or LinkedIn.

This article was previously published on proandroiddev.com.