When we talk about mobile forensics, the conversation often drifts toward flashy artifacts like chat messages, call logs, or photos. Those are important, of course. But there’s another category of evidence that doesn’t get nearly enough attention: the silent witnesses that reveal how someone uses their device, not just what they store on it.

cover

Think of pattern of life analysis as the difference between knowing someone owns a car and knowing they drive to work every morning at 8:15, stop at the same coffee shop, and rarely use the highway. On iOS, this kind of data is famously concentrated in knowledgeC.db, an artifact so well-documented that it’s become almost synonymous with iOS usage analysis. Accessing it requires full filesystem extraction, which is its own challenge, but at least investigators know where to look.

Android tells a different story. The platform’s usage tracking is distributed across multiple databases, each with its own schema, retention policy, and extraction requirements. There’s no single knowledgeC.db to rule them all. Instead, forensic analysts must piece together evidence from UsageStats, Digital Wellbeing, appops logs, and increasingly, device-specific systems like Samsung’s Rubin.

This fragmentation isn’t just a technical inconvenience. It creates real investigative risks. Relying on a single data source can lead to incomplete timelines, and on some devices, it can produce outright incorrect conclusions. The goal of this article isn’t to walk through acquisition methods I’ve covered elsewhere in my mobile forensics overview, but to focus specifically on analyzing the pattern of life artifacts that Android leaves behind. If you’re working a case and need to reconstruct what a user did with their device, these are the databases you need to know.

Android encryption, what matters for your investigation

Before diving into specific artifacts, we need to address the elephant in the room: Android’s encryption model determines whether you can even access these files in the first place.

Since Android 7.0, File-Based Encryption (FBE) has been the standard. FBE separates storage into two distinct areas. Device Encrypted (DE) storage contains system files and data accessible immediately after boot, before any PIN or pattern is entered. Credential Encrypted (CE) storage holds everything else: user data, databases, app-specific files. CE is only decrypted after the user enters their credentials for the first time after boot.

This distinction matters enormously in practice. Files in DE storage, like /data/system/ configuration files and certain system logs, are accessible without knowing the device PIN. But the databases that contain the richest usage information sit in CE storage. This means usagestats/, dwbCommon.db, appops.xml, and telephony.db all require what the industry calls AFU access (After First Unlock), a challenge that becomes even more complex with newer Android versions as I explored in my analysis of Android 14 forensic challenges.

In real-world investigations, this creates a critical decision point. BFU (Before First Unlock) acquisitions capture only what’s in DE storage and can be severely limited. AFU acquisitions, where the examiner obtains the device after it’s been unlocked at least once, provide access to the CE storage where pattern of life data lives. As Cellebrite’s documentation on FBE vs FDE explains, the choice between these acquisition strategies directly determines which artifacts you’ll be able to analyze.

If you’re acquiring an Android device, understanding FBE isn’t optional. It’s the foundation that determines whether your investigation will have access to the usage data you need or whether you’ll be working with an incomplete picture.

UsageStats and what it reveals about app usage

The heart of Android pattern of life analysis lives in the UsageStats system. This is a directory, typically found at /data/system/usagestats/, that Android populates with granular data about application usage.

Every time an app moves to the foreground or background, UsageStats records it with millisecond-precision timestamps. The system tracks when each app was opened, how long it remained active, and aggregates this data into time buckets: daily, weekly, monthly, and yearly summaries. Even after an application is uninstalled, residual traces often remain in the monthly bucket files, documenting when that app was last used.

What’s particularly valuable for forensic investigators is the combination of granularity and persistence. The daily XML files typically retain the most detailed events for the past seven days. Weekly buckets cover approximately the last month. Monthly summaries can extend back six months or more, depending on the device and Android version. Beyond those retention windows, the data gets overwritten.

ALEAPP, the open-source parser created and maintained by Alexis Brignoni, handles both the legacy XML format and the Protobuf format introduced in Android 9. The usagestats.py script, last updated in March 2025, parses these files and produces timeline output that investigators can directly use. A typical query looks like this:

SELECT package_name, 
       datetime(time/1000,'unixepoch') as event_time,
       type
FROM usageevents
ORDER BY time ASC;

This simple query reveals the exact sequence of app interactions, providing a minute-by-minute reconstruction of device usage. Combined with the aggregate duration data in the time bucket files, analysts can determine not just which apps were used, but for how long, and how that usage patterns evolved over days or weeks.

The limitations are worth noting. UsageStats doesn’t capture every user action within an app. It records app focus events, not individual actions like typing a message or taking a photo. And the retention window means older usage patterns may be lost entirely.

Digital Wellbeing and dwbCommon.db in practice

If UsageStats tells you which apps were used, Digital Wellbeing tells you about the device itself. The app that Google built to help users track their screen time maintains its own usage database at /data/com.google.android.apps.wellbeing/databases/dwbCommon.db.

This database goes beyond simple app usage. The usageEvents table contains event types that are far more granular than what UsageStats provides. According to research documented by Belkasoft and corroborated by other forensic practitioners, the event type codes tell a detailed story:

Event Type Meaning
1 App in foreground
2 App in background
15 Screen on
16 Screen off
18 Device unlocked
23 Notification received

This means Digital Wellbeing records not just app activity, but the physical interactions with the device. Screen on and off events reveal when the user picked up their phone. Unlock events, captured in eventType=18, show when and how often the device was accessed. Notifications received can indicate which apps were actively delivering content even when not directly used.

Here’s where things get interesting for Samsung devices. The Binary Hick has documented how Samsung’s proprietary system, called Rubin, integrates with Digital Wellbeing but maintains its own parallel dataset. On Samsung devices, eventType=18 (device unlocked) may be missing from dwbCommon.db but present in Rubin’s database. This is a critical finding: relying solely on Digital Wellbeing for Samsung device analysis could produce an incomplete or incorrect unlock timeline.

Belkasoft has also documented additional usage data sources, including reflection_gel_events.db and app_usage_stats.xml, that can complement Digital Wellbeing data. The key takeaway is that no single database tells the complete story. Cross-validation between multiple artifacts isn’t just good practice, it’s essential for accurate results.

appops.xml and what it records about permissions

The third major piece of the pattern of life puzzle comes from a file that most investigators overlook: /data/system/appops.xml. This XML file tracks not just which permissions were granted to applications, but when those permissions were actually exercised.

Every time an application accesses a sensitive permission like the microphone, camera, location, SMS, or contacts, appops.xml records the timestamp of that access. This is fundamentally different from UsageStats or Digital Wellbeing. Those systems track app usage in general. appops.xml specifically documents when an app crossed the line into sensitive system resources.

In practical terms, this means you can determine exactly when a particular app last used the microphone, which is devastating evidence in cases involving covert recording, surveillance, or extortion. You can see which apps accessed the camera, when they did so, and correlate that with geolocation data to build a complete picture. You can identify apps that read SMS messages or contacts, even if those apps were subsequently uninstalled.

The critical detail that makes appops.xml valuable is that it records denied permissions too. When a user explicitly denies an app’s permission request, that denial is logged with a timestamp. This can reveal attempts to access sensitive resources that the user deliberately blocked, which is itself meaningful context in an investigation.

As documented by Forensafe and GumshoeForensics, the file requires either manual parsing or processing through ALEAPP. The main limitation is that appops.xml only stores the most recent access for each permission-app combination. It doesn’t maintain a history. That’s where it complements Digital Wellbeing: appops.xml gives you the “last seen” for sensitive permissions, while UsageStats and Digital Wellbeing provide the broader usage timeline.

Bringing it all together: super-timeline with Plaso

Everything we’ve discussed so far builds toward a single goal: reconstructing a complete user activity timeline. The final piece of this puzzle is location data, and a 2024 change by Google has fundamentally altered how we approach it.

For years, Google Timeline (formerly Location History) was primarily a cloud-based dataset. Investigators could request it via Google Takeout as part of legal discovery. But in late 2024, Google announced that Timeline would now be stored locally on the device with a reduced retention period of three months, a shift documented by ElabForensics. The data lives at /data/com.google.android.gms/files/.

This changes forensic practice significantly. A Google Takeout request no longer provides the historical depth it once did. But a physical acquisition of a device in AFU state can now capture location data that was previously only available from the cloud, and potentially more recent than what cloud requests would return.

Correlating this location data with the usage artifacts creates investigative power. You can answer questions like: “At 2:15 PM on Tuesday, the user was at this location. What app were they using at that exact moment?” Or: “The user opened this messaging app immediately after arriving at this location. Is there a pattern?”

Plaso, the open-source timeline analysis framework, is purpose-built for exactly this kind of correlation. It supports Android-specific parsers that can ingest UsageStats, SQLite databases, and system logs into a unified timeline. The command pipeline looks like:

log2timeline.py android.plaso /path/to/android_image/
psort.py -o l2tcsv android.plaso > timeline.csv

This produces a single chronological view of all events, regardless of source. Investigators can then query this combined timeline to find correlations that would be invisible when looking at individual artifacts in isolation.

The forensic community has long recognized that piecing together user activity requires multiple data sources. With Android’s fragmented storage of usage data, that recognition becomes practical necessity. UsageStats, Digital Wellbeing, appops, and location data each cover different aspects of device interaction. Only by combining them can an investigator claim to have reconstructed a meaningful pattern of life.

What makes Android forensics challenging is also what makes it rewarding. The platform’s openness and fragmentation mean that skilled analysts can access rich datasets that simply don’t exist on more locked-down platforms. The artifacts are there, distributed across multiple databases, waiting for someone who knows where to look. The question is no longer whether Android pattern of life data exists, but whether investigators know how to find and interpret it.