Where App Data Stored in Android: Complete Storage Locations

Wondering where app data is stored in Android—and which locations actually matter? This guide delivers a clear map of the complete storage locations for Android app data, from internal app storage and cache to databases, files, and external storage. You’ll get the practical verdict on where data lives, what persists across app uninstall, and what’s safe to rely on for each storage type.

Introduction

Android offers multiple storage locations depending on who should access the data (only your app vs. other apps/users), what the data represents (cache vs. persistent files vs. media), and how modern Android storage rules apply (scoped storage, MediaStore, app-specific external directories).

The key to managing app state safely is understanding the exact place each data type lands, how it’s protected, and what risks exist when developers try to “just save to external storage.” Below is a complete, practical map of the main locations and how to choose the right one for files, databases, cache, preferences, and media on Android.

🗂️ DATA MAP

Recommended Android Storage Locations by Data Type (2025)

#	Data Type	Primary Location	Typical API/Mechanism	Security Fit
1	Session tokens & secrets	`/data/data/<package>/` (files/DB)	Encrypted storage + internal files/SQLite	★ ★ ★ ★ ★
2	User settings (preferences)	`/data/data/<package>/shared_prefs/`	SharedPreferences (XML)	★ ★ ★ ★ ★
3	App persistent documents	`/data/data/<package>/files/`	`openFileOutput()` / internal file I/O	★ ★ ★ ★ ☆
4	Download cache (recreatable)	`/data/data/<package>/cache/`	`getCacheDir()` / app cache directory	★ ★ ★ ★ ☆
5	Offline structured data	`/data/data/<package>/databases/`	SQLite / Room database	★ ★ ★ ★ ★
6	App-specific external files	`/storage/emulated/0/Android/data/<package>/files/`	`getExternalFilesDir()`	★ ★ ★ ☆ ☆
7	User media (shared photos/audio)	Media collections via MediaStore	MediaStore + scoped access	★ ★ ☆ ☆ ☆

App Private Internal Storage

Internal storage is the default “safe harbor” for app data. When you write to internal storage—whether via file APIs, databases, or preferences—Android places it under your app’s private directory:

Stored per app under `/data/data//`
Access is restricted to your app unless you deliberately expose content through exported components, shared URIs, or other mechanisms
Includes files created via `openFileOutput()`, databases, and cache (varies by type)

What you can store internally

From an implementation perspective, internal storage commonly breaks down into subdirectories that map to the APIs you use:

`files/`: persistent app files written with `openFileOutput()` or `File` under the internal files directory (`context.filesDir`)
`cache/`: data you can re-download or reconstruct (created with `context.cacheDir` or cache APIs)
`databases/`: SQLite databases (including Room)
`shared_prefs/`: SharedPreferences data (XML)

Why it matters for business applications

For business apps—especially those handling user identity, entitlements, analytics events, or document workflows—internal storage reduces the blast radius of security problems. If your app stores authentication tokens, user profile metadata, or licensing information internally, you avoid the common failure mode of exposing sensitive artifacts through overly broad external sharing.

Actionable guidance

Use internal storage by default for anything that should not be accessible by other apps.
Treat internal files as “safe but not invulnerable”: consider encrypting sensitive content at rest if threat models require it.
Use app-specific external directories only when you truly need external semantics (e.g., user-facing exports or re-access across certain app lifecycle events).

Cache vs Files (Internal Storage)

A frequent source of confusion is mixing cache data with persistent files. Android gives you two powerful internal tools—cache and files—and they behave differently under system pressure.

Cache data is safe to clear and can be removed by the system
Persistent app files remain until you delete them (or the app is uninstalled)
Helps you decide what to store permanently vs. temporarily

Cache: designed to be expendable

Cache is intended for:

HTTP responses you can refresh
Thumbnails you can regenerate
Intermediate parsing results
Temporary downloads that can be re-fetched

When storage is low or the system reclaims space, cached content is more likely to be removed. Your app must therefore be resilient: check cache availability, handle cache misses, and re-download or re-generate safely.

Actionable guidance

If you can recompute or re-download it, prefer `/data/data//cache/`.
Cache should never be the single source of truth for user data.
For performance, cache aggressively—but for correctness, validate and recover.

Files: persistent state you control

Persistent internal files should hold:

Locally generated documents the user expects to keep
Exported assets that must remain until the user deletes them
Offline configuration that you don’t want rebuilt frequently
App state that is not merely performance optimization

Because persistent files are not automatically cleared, they should be:

Versioned (or migrated)
Explicitly cleaned up when no longer needed
Considered during uninstall/migration scenarios

Actionable guidance

Track file lifecycles (creation time, last access, size) so you can prune old persistent content.
Separate “downloaded but replaceable” from “user-owned” to avoid data loss.

Databases and Shared Preferences

Internal storage isn’t just about raw files. Most Android apps rely on structured state:

Databases (e.g., SQLite) are stored inside the app’s internal directory
SharedPreferences typically live as XML files in app storage
Useful for understanding where app state and settings are maintained

Databases: where relational and offline data lives

SQLite databases generally reside under:

`/data/data//databases/`

If you use Room, the underlying database file is still stored in that internal area. For sensitive structured data (e.g., offline transactions, profile information), internal DB storage is typically the right default.

Actionable guidance

Use internal databases for offline data that should not be accessible by other apps.
Implement schema migrations carefully—storage location is stable, but schema changes can break users if migrations aren’t robust.
For regulated environments, encrypt sensitive columns (and consider SQLCipher-style approaches where appropriate).

SharedPreferences: where settings become durable

SharedPreferences are usually stored as XML files in:

`/data/data//shared_prefs/`

This includes values such as feature flags, UI preferences, last sync time, and small amounts of state.

Actionable guidance

Keep SharedPreferences for small, non-sensitive settings.
For secrets (tokens, API keys), don’t rely on plain SharedPreferences; instead use a secure approach like Android Keystore-backed encryption.
Use “commit vs apply” appropriately to avoid UI-thread stalls and data inconsistency.

External Storage (Shared/Media/Downloads)

External storage is where Android becomes more nuanced. External storage includes multiple categories:

App-specific external files under app folders on external storage
Shared media (images/video/audio) typically managed via MediaStore
Requires runtime permissions depending on Android version and the storage approach

App-specific external storage: a safer compromise

If you call `getExternalFilesDir()` (or similar), Android places files under app-specific paths like:

`/storage/emulated/0/Android/data//files/`

This is *external* storage, but it’s still scoped to your app’s directory, meaning you have a clearer boundary than writing into broad public directories.

Key trade-off: external storage is more likely to be impacted by user actions (e.g., “clear site data” equivalents don’t apply the same way, but users can manage storage, backup/restore behavior varies, and platform changes can affect access patterns).

Shared media via MediaStore: the modern default

If your app is creating or importing user-visible media (photos, audio, video), MediaStore is the recommended approach. Instead of manually choosing raw file paths everywhere, you insert media into Android’s media collections and receive URIs that represent those assets.

Actionable guidance

For images/audio/video intended for galleries and other apps, use MediaStore.
Avoid direct writes to arbitrary “Downloads” paths unless your Android version strategy and permission model are fully understood.
Always handle cases where URIs become invalid (scoped access and revocation can occur).

File Providers, Permissions, and Security

A common security anti-pattern is treating internal files as though they can be safely accessed by other apps via file paths. Android restricts direct access, so attempts to share internal storage often fail—and when they “work,” they may introduce serious security risks.

You should avoid sharing private app data directly from internal storage
Use `FileProvider` to grant secure access to files
Use scoped storage to limit access and improve compatibility/security

Why `FileProvider` exists

Internal storage is private. If another app needs to open a file (e.g., user shares a report PDF with email), you should:

Keep the file stored internally or in an appropriate app-controlled directory.
Share access using a content URI provided by `FileProvider`.
Grant temporary, scoped permissions through the share intent mechanism.

This avoids “world-readable” files and keeps your app’s storage boundaries intact.

Scoped storage: reducing accidental overreach

Scoped storage is Android’s model for limiting direct filesystem access. In practice:

You don’t assume you can write to everything on `/storage/emulated/0/`
You use safer APIs and URIs for shared content
You rely on system-managed collections (MediaStore) rather than brittle path-based access

Actionable guidance (security and compatibility)

Use internal storage for sensitive documents; export via `FileProvider` when the user requests sharing.
For shared media, use MediaStore and persist permissions only if your use case requires it.
Minimize broad permissions. If you only need to save images users choose, request the smallest storage capability aligned with the workflow (and Android version).

Conclusion

Android app data is primarily stored in private internal storage under `/data/data//`, including files, cache, SQLite databases, and SharedPreferences (XML under `shared_prefs/`). For app-specific content that must live outside the internal sandbox, you can use external app directories such as `/storage/emulated/0/Android/data//files/`; for truly shared user media, rely on MediaStore and scoped storage rather than raw filesystem paths.

To choose the correct location, classify your data as cache vs. persistent files, structured vs. key-value, and private vs. user-visible/shared, then pair that classification with the right permissions and sharing mechanism (often `FileProvider`).

Frequently Asked Questions

Where is app data stored on Android device internally?

On Android, app data is typically stored in the app’s private internal storage under /data/data// for non-root devices. This includes databases, shared preferences, and files your app saves for its own use. Some apps also use Android’s credential-protected or device-encrypted directories so that data is protected when the device is locked.

How can I find where a specific app stores its data on Android?

You can usually locate app data through Android’s Settings by going to Settings > Apps > (App name) > Storage to see what’s stored and how much space it uses. For deeper inspection, you can use a file explorer only if the app’s storage is user-accessible (like “files” in internal storage) or use ADB on a computer to access app directories. Without root, you can’t freely browse another app’s private folder, because Android enforces per-app sandboxing.

Why is my app data not found after I clear cache or clear storage?

Clearing cache removes temporary files only, while clearing storage (sometimes called “Clear data”) deletes the app’s private app data such as databases and shared preferences. If you uninstall or clear storage, the app may also lose locally saved settings and offline content unless it’s synced to a server or saved to external storage. This is why some users see the app “reset” after clearing storage.

Which folders contain app files like downloads, documents, and images on Android?

Android stores user-accessible media and documents under shared external storage locations like /storage/emulated/0/ (commonly exposed as “Internal storage”) and app-specific external directories when used. However, modern Android versions often require scoped storage, so apps can only access their own media unless the user grants permissions. Many apps save images and downloads to app-specific folders in shared storage, but other file types may stay in private internal storage.

What is the best way to back up app data stored on Android?

The best method depends on whether the app stores data locally or syncs to the cloud. For local-only data, use Android backup options (like Google One/Android backup) if the app supports it, or export data inside the app (e.g., “export chats” or “save backup”). If you manage devices, ADB-based backups and app data transfer tools can help, but they typically require specific setup and may not capture all app data on newer Android versions.