Skip to content
AndroidForensics

MediaLocation

DCIM, EXIF and MediaStore external.db on Android

Android photos and videos as evidence: DCIM naming, EXIF time and GPS, the MediaStore external.db index, owner package, trash and thumbnail caches.

Location
/sdcard/DCIM/Camera/ (media), external.db in the MediaProvider sandbox (com.android.providers.media, or com.google.android.providers.media.module on 11+)
Android
Proves
Which photos and videos exist, when and where they were taken (EXIF), which app created each file, when files were added, modified or moved to trash, and which images existed before deletion
Timestamps
EXIF DateTimeOriginal in local time without zone unless OffsetTimeOriginal is present; GPSDateStamp and GPSTimeStamp in UTC; MediaStore date_added and date_modified in Unix seconds, datetaken in Unix milliseconds
Access
Logical: shared storage (DCIM, Pictures, Download) is readable over ADB without root. MediaStore database: full file system (root, exploit or agent), AFU only. Not in ADB backup unless -shared (files only).
Retention
Until the user deletes the file; Android 11+ trash keeps deleted items about 30 days; gallery apps keep their own trash and caches; MediaStore rows are removed with the file
Collection
adb pull /sdcard/DCIM /sdcard/Pictures /sdcard/Download, Full file system extraction

Tools

Compare all tools

What it is

Photos and videos are among the most common exhibits from a phone, and Android gives three layers of evidence about them:

  1. The files in shared storage: DCIM/Camera for the camera, Pictures/Screenshots, Download, and per-app folders such as WhatsApp's media directory.
  2. Embedded metadata: EXIF in JPEG and HEIC (capture time, time zone offset, GPS, make and model, orientation), and QuickTime or MP4 atoms in videos.
  3. The MediaStore index, external.db, maintained by the MediaProvider: one row per media file with its path, times, size, dimensions, the package that created it, and trash state.

The index is where Android forensics differs from simply copying a folder: it can show which app wrote a file, when it was added, and that a file existed after it was removed from the camera roll.

Where it lives

ItemPathNotes
Camera/sdcard/DCIM/Camera/Names such as IMG_20260914_174312.jpg, PXL_20260914_154312345.jpg (Pixel), 20260914_174312.jpg (Samsung)
Screenshots/sdcard/Pictures/Screenshots/ or /sdcard/DCIM/Screenshots/OEM-dependent
MediaStore (8 to 10)/data/data/com.android.providers.media/databases/external.dbPlus internal.db for system media
MediaStore (11+)/data/data/com.google.android.providers.media.module/databases/external.dbMainline module; some OEM builds keep com.android.providers.media
Trash (11+)Same folder as the original, named .trashed-<expiry>-<name>Hidden; the prefix carries an expiry time in Unix seconds
Thumbnails.thumbnails folders in shared storage, gallery app cachesLocation and format vary by release and gallery app

Google Photos and OEM galleries (Samsung Gallery, for example) keep their own databases, trash and cloud sync state in their sandboxes: collect them separately and verify their paths on your build.

What it proves

  • A photo or video was captured on a given date by a given camera model, and, if location was on, where.
  • Which app created a media file (owner_package_name, Android 10+): the camera, a messaging app, a browser, a screen recorder.
  • When the file was added to MediaStore, which is often when it was received or downloaded rather than when it was taken.
  • That a file was moved to trash, and until when it will be kept (is_trashed, date_expires).
  • That an image existed when a thumbnail of it exists without the original.

EXIF can be edited, and files received through messaging apps usually lose it. Treat EXIF as a claim to corroborate.

Key fields

SourceFieldMeaning
EXIFDateTimeOriginal, OffsetTimeOriginalCapture time (local) and its UTC offset
EXIFGPSLatitude, GPSLongitude, GPSAltitude, GPSDateStamp, GPSTimeStampPosition and GPS fix time (UTC)
EXIFMake, Model, SoftwareDevice and editing software
files table_data, relative_path, _display_name, volume_namePath and name
files tabledate_added, date_modified (seconds), datetaken (ms)Index and capture times
files tableowner_package_name, is_pending, is_trashed, date_expiresCreator app, trash state
files tablewidth, height, duration, _size, mime_typeMedia properties

Timestamps

Mind three clocks. EXIF DateTimeOriginal is local time with no zone: use OffsetTimeOriginal when present, or the device's time zone at capture. GPS stamps are UTC. MediaStore date_added and date_modified are Unix seconds, datetaken Unix milliseconds. Pixel PXL_ file names are commonly reported to use UTC while other cameras use local time: check against EXIF on your build.

exiftool -n -csv -DateTimeOriginal -OffsetTimeOriginal -GPSLatitude -GPSLongitude -Make -Model -r DCIM/ > exif.csv
sqlite3 external.db "SELECT _data, owner_package_name, datetime(date_added,'unixepoch'), datetime(datetaken/1000,'unixepoch'), is_trashed FROM files WHERE media_type IN (1,3) ORDER BY date_added;"

Retention

Files stay until deleted. On Android 11+ the system trash keeps items about 30 days; Google Photos and OEM galleries have their own trash with similar windows. MediaStore rows disappear with the file, but the database's WAL and free pages can keep old rows for a while, and thumbnail caches often outlive originals.

Collection

  • Logical: adb pull of DCIM, Pictures, Download, Movies and app media folders, preserving timestamps (adb pull -a).
  • Full file system extraction (AFU): external.db with WAL, gallery and Google Photos sandboxes, and hidden trash files.

Parsing

  • ExifTool reads EXIF, XMP and video metadata in bulk.
  • ALEAPP parses MediaStore and some gallery databases.
  • Autopsy and commercial suites extract EXIF, geolocate media and show thumbnails.

Investigator tips

See also