Back to Blog
Engineering
1 min read

Android Scoped Storage (2026): A Better Guide Than the Official Docs

A
AdminAuthor
May 24, 2026Published
Android Scoped Storage (2026): A Better Guide Than the Official Docs

If you have spent hours staring at the Android scoped storage official documentation and left feeling more confused than when you started, you are not alone.

Since Google introduced Scoped Storage in Android 10, the file handling ecosystem has been a moving target. With the enforcement of granular media permissions in Android 13 and Android 14, older methods like READ_EXTERNAL_STORAGE are completely dead.

This guide strips away the academic jargon. Here is the plain-English, actionable guide to handling files, media, and app-specific storage in modern Android development for 2026.

The Elephant in the Room: READ_EXTERNAL_STORAGE is Deprecated

If you are trying to update a legacy app, your first major roadblock is the read_external_storage deprecated Android 13 official warning.

Before Scoped Storage, asking for READ_EXTERNAL_STORAGE gave your app a backstage pass to the entire device file system. For obvious privacy reasons, Google killed this.

What You Must Use Instead (Android 13+)

Instead of a single blanket permission, you now must request granular access based on the exact type of media you need:

  • READ_MEDIA_IMAGES (For photos)
  • READ_MEDIA_VIDEO (For videos)
  • READ_MEDIA_AUDIO (For audio files)
Pro Tip: If your app only needs users to select a profile picture or a single file, do not request any permissions. Use the PhotoPicker or the Storage Access Framework (SAF). The system grants temporary read access to the specific file the user selects, bypassing the need for manifest permissions entirely.

Scoped Storage Explained in Plain English

Think of the Android file system as an office building.

Before Android 10, any app with storage permissions could walk into any room in the building. With Scoped Storage, your app is given its own locked office. You can do whatever you want inside your office, but if you want to look at files in the hallway (Shared Storage), you have to ask a security guard (the Android OS) for specific permission.

Here is how you should categorize your file handling:

1. App-Specific Files (Your Office)

These are files meant only for your app. They are hidden from the user and deleted automatically when the app is uninstalled.

  • Do you need permissions? No.
  • Where do they go? Context.getExternalFilesDir()
  • Best for: Caching data, temporary files, internal app configurations.

2. Shared Media (The Public Gallery)

These are photos, videos, and audio files that should be accessible to other apps (like the Gallery or Music Player).

  • Do you need permissions? Yes (to read others' files). No (to write your own).
  • Where do they go? The MediaStore API.
  • Best for: Camera apps saving photos, audio recorders saving MP3s.

3. Other Shared Documents (The Filing Cabinet)

PDFs, ZIP files, and other non-media documents.

  • Do you need permissions? No.
  • Where do they go? Storage Access Framework (SAF) via the System File Picker.
  • Best for: "Export as PDF" features, opening downloaded reports.

Fixing Environment.getExternalStorageDirectory()

Another massive headache for developers migrating legacy code is dealing with the Environment.getExternalStorageDirectory deprecated Android 10 scoped storage issue.

If you try to use this old method to create a folder at the root of the file system (e.g., file:///internal storage/MyAppFolder), your app will crash with a SecurityException on modern devices.

The Modern Solution

You have two choices depending on your intent:

Your Intent

The 2026 Solution

Store a file the user should see in their Downloads.

Use the MediaStore.Downloads collection.

Store a file hidden from the user.

Use Context.getExternalFilesDir(null).

Let the user choose exactly where to save it.

Fire an ACTION_CREATE_DOCUMENT intent (SAF).

Android Scoped Storage Best Practices 2026

To future-proof your app and ensure you aren't scrambling every time a new Android API level drops, follow these architecture rules:

  1. Adopt a "Zero Permission" Architecture First: Always try to build your feature without asking for manifest permissions. Rely heavily on ActivityResultContracts.PickVisualMedia (the modern Photo Picker) and ACTION_OPEN_DOCUMENT.
  2. Use the MediaStore for Media Only: Never try to stuff non-media files (like JSON or text files) into the MediaStore. Google's indexer will eventually flag or corrupt them.
  3. Handle Partial Access Gracefully: In Android 14 (API 34), Google introduced READ_MEDIA_VISUAL_USER_SELECTED. Users can now grant your app access to some photos but not all of them. Your UI must account for this partial access state without crashing or looping permission requests.
  4. Migrate Legacy Data Promptly: If you have an old app that saved user data to the root directory, use preserveLegacyExternalStorage="true" in your manifest as a temporary band-aid, but write a migration script to move those files into app-specific storage or the MediaStore immediately.

Summary

The transition to Scoped Storage is painful for legacy codebases, but it ultimately results in cleaner architecture and better user trust. Stop fighting the OS by trying to request broad storage permissions. Embrace the MediaStore for shared media, app-specific directories for internal data, and the system file pickers for everything else.