Skip to content
AndroidForensics

App usageUser activity

Digital Wellbeing: app_usage Database

Google Digital Wellbeing's app_usage database on Android 9+: app open and close events, unlocks and notifications, Samsung's variant, retention and parsing.

Location
/data/data/com.google.android.apps.wellbeing/databases/app_usage
Android
Proves
When apps came to the foreground and went to the background, device shutdown and startup, and, on some versions, notification and unlock counts per app
Timestamps
Unix milliseconds (UTC): events.timestamp
Access
Full file system (root, exploit or agent); credential-encrypted sandbox, so AFU only. Logical: the dashboard on screen, or dumpsys usagestats for the underlying system events. Not in ADB backup.
Retention
A rolling window of roughly one to two weeks of events on the versions examined publicly; verify on your build
Collection
Full file system extraction, adb shell dumpsys usagestats, Screen photography of the dashboard (user present)

Tools

Compare all tools

What it is

Digital Wellbeing is Google's screen-time app, launched with Android 9 on Pixel phones and shipped on many other Android One and Google-certified devices since. It shows how long each app was used, how many notifications arrived and how often the phone was unlocked, and it enforces app timers, Bedtime mode and Focus mode.

To draw its dashboard, Digital Wellbeing (com.google.android.apps.wellbeing) reads usagestats through the usage access API and keeps its own copy of the events in a SQLite database named app_usage. That copy is useful in two ways: it is simple to query, and it sometimes covers a slightly different window than the system's own usagestats files, so each can fill gaps in the other.

Samsung phones use Samsung's own Digital Wellbeing (com.samsung.android.forest) with different databases, and some OEMs ship none. Check which package is present in installed packages before looking for the database.

Where it lives

ItemPathNotes
Events/data/data/com.google.android.apps.wellbeing/databases/app_usage (+ -wal, -shm)events and packages tables
Settings and limits/data/data/com.google.android.apps.wellbeing/databases/ and shared_prefs/App timers, Bedtime, Focus mode configuration
Samsung equivalent/data/data/com.samsung.android.forest/databases/Samsung schema; verify on your build
System source/data/system_ce/<user>/usagestats/The events Digital Wellbeing copies

The app updates through Google Play, so the schema follows the app version rather than the Android release.

What it proves

  • An app moved to the foreground (type 1) or background (type 2), with the package name, at a given millisecond.
  • The device was shut down or started, which explains gaps.
  • On versions that store them, notification arrivals per app and keyguard events used for the unlock count.
  • The user configured app timers, Bedtime or Focus mode, which can show an attempt to limit or hide use.

Like usagestats, it proves an app was on screen, not what the user did inside it, and it does not distinguish between users of a shared phone.

Key fields

TableColumnMeaning
events_idRow ID
eventstimestampUnix milliseconds
eventstypeEvent code, mirroring Android's UsageEvents constants
eventsinstance_idActivity instance, pairs a resume with its pause
eventspackage_idForeign key into packages
packages_id, package_namePackage name lookup

Common type values follow the system constants: 1 resumed, 2 paused, 23 stopped, 26 shutdown, 27 startup. Other values appear on some builds; map them against usagestats for the same period rather than assuming.

Timestamps

All times are Unix milliseconds in UTC.

SELECT datetime(e.timestamp/1000, 'unixepoch') AS utc,
       e.type, p.package_name, e.instance_id
FROM events e
LEFT JOIN packages p ON p._id = e.package_id
ORDER BY e.timestamp;

Session length is the difference between a type 1 and the next type 2 (or 23) with the same package and instance_id.

Retention

The database keeps a rolling window, roughly one to two weeks on the versions examined publicly, and older rows are pruned. Clearing the app's storage or turning off usage access removes it. The dashboard aggregates are recalculated from the events, so there is no long-term history beyond the window.

Collection

  • Full file system extraction (AFU): copy the databases/ folder with WAL files.
  • Logical: adb shell dumpsys usagestats returns the system's events, which is the same data at source. Photographing the Digital Wellbeing dashboard is weaker evidence but sometimes the only option.
  • Bugreport: includes the usagestats dump.

Parsing

  • ALEAPP parses app_usage (and Digital Wellbeing account data where present) into a timeline.
  • sqlite3 with the query above for validation.
  • Commercial suites list Digital Wellbeing events alongside usagestats.

Investigator tips

  • Line up Digital Wellbeing events with usagestats: matching events from two stores, written by two components, are stronger than either alone.
  • Use startup and shutdown events to explain gaps in battery history and other logs.
  • A foreground event for a messaging app just before a message's send time supports attribution; see the pattern-of-life guide.
  • Missing Digital Wellbeing data on a Pixel that has the app may mean usage access was revoked or storage cleared: check notification history and recent tasks for the same period.

See also