Reference

Emulated External Storage

Emulated external storage is a FUSE/sdcardfs-backed view that exposes a slice of a device's internal flash through the legacy "external storage" API at /storage/emulated/0. There is no physical SD card; it emulates one so apps written for removable media still work.

Android developmentAndroid

Emulated External Storage

Also known as: emulated storage android, sdcard emulated, android emulated storage, /storage/emulated/0

Emulated external storage is a FUSE/sdcardfs-backed view that exposes a slice of a device's internal flash through the legacy "external storage" API at /storage/emulated/0. There is no physical SD card; it emulates one so apps written for removable media still work.

  • Emulated external storage lives on the same physical flash as the OS — there is usually no removable card behind /storage/emulated/0.
  • The trailing number is the Android user ID: 0 for the primary profile, 10+ for secondary users and work profiles.
  • Android has implemented the layer as FUSE, then in-kernel sdcardfs, then FUSE again to support scoped storage and MediaStore enforcement.

Why internal storage shows up as an "SD card"

Early Android phones had a real, removable SD card mounted at /sdcard, and the public storage APIs (getExternalStorageDirectory(), getExternalFilesDir()) were named around that hardware. When manufacturers moved to large built-in flash and dropped the physical card slot, Google kept the API contract by *emulating* external storage on top of the internal partition. That emulated volume is exposed at /storage/emulated/0 (the `0` is the user ID; secondary profiles get `/storage/emulated/10`, etc.), with /sdcard kept as a legacy symlink.

So when a file manager reports your "SD card" is nearly full but you have no card inserted, it is reading the emulated volume that lives on the same flash chip as the OS and apps. "Internal storage" and this "external storage" are physically the same medium; the distinction is an API/permission boundary, not a hardware one.

How the emulation layer works

Historically Android used a FUSE daemon to project the underlying ext4/f2fs directory as the emulated volume, enforcing permissions and case-insensitive paths. Android then switched to an in-kernel sdcardfs shim for performance. With scoped storage (Android 10+) and again in Android 11+, Google moved back to a tuned FUSE implementation that lets MediaStore intercept file operations and apply per-app, per-collection access rules.

Practically, the emulation layer is what makes a single physical partition behave like a shared, multi-user, permission-checked drive. App-private folders such as getExternalFilesDir() point into `/storage/emulated/0/Android/data/<package>` and are auto-deleted on uninstall, while shared collections (DCIM, Download, Pictures) live at the volume root and are governed by MediaStore and runtime permissions.

What this means for a storage cleaner

Because emulated storage and internal storage share one flash chip, freeing space in either place increases the same usable pool. Cleanor scans the emulated volume root and the Android/data tree to find duplicate photos, leftover .thumbnails caches, large videos, and stale OBB/download files, then reclaims them through MediaStore and scoped storage APIs rather than raw paths, so deletions are permission-safe across Android 10+.

Related terms

Keep reading the reference.

Act on it

Guides and tools for this topic.