What specific Android files and paths contain usagestats and app activity for forensic collection?
Executive summary
Android devices scatter application-usage evidence across system XML, protobuf blobs and SQLite databases stored primarily under /data and per-user system folders; key artifacts include usagestats (XML/protobuf) files, Digital Wellbeing and launcher activity databases, and package metadata such as packages.xml and packages.list which investigators routinely collect with forensic tooling or privileged access [1] [2] [3]. Modern Android (Android 10+) moved many usagestats records into protobuf-format interval files under the usagestats service, so examiners must parse both legacy XML and newer protobuf blobs to reconstruct app foreground/background events and durations [4] [5].
1. Where the usagestats live on disk: /data/system/usagestats and per-user subfolders
The primary repository for Android usage statistics is the usagestats service directory under the system data partition — typically /data/system/usagestats (and per-user variants such as /data/system/usagestats/) — which contains interval files (daily/weekly/monthly) that record packages, event logs and configurations used to timeline app activity [1] [4]. Analysts have documented both XML-formatted app_usage_stats.xml files from older releases and binary protobuf IntervalStats files in Android 10+ daily folders; practical parsing examples and protobuf schemas are provided by forensic researchers such as Yogesh Khatri and others who reverse-engineered the usagestatsservice_pb2 format [4] [6].
2. app_usage_stats.xml, recent_taks / app_usage and Digital Wellbeing databases
Some devices and OEM services still generate readable XML artifacts — app_usage_stats.xml and recent_tasks XML — that list last_time_active, total_time_active, app_launch_count and visibility timestamps useful for foreground/background inferences [1] [6]. Complementary records appear in Digital Wellbeing-related databases (for example dwbCommon.db and app_usage SQLite artifacts) and in launcher/assistant event DBs such as reflection_gel_events.db that capture activity and device-interaction events; Belkasoft’s artifact mapping highlights these specific filenames as forensic-interest items [1] [2].
3. Package and account metadata that support usage interpretation
Files that identify installed packages and accounts help contextualize usagestats: packages.xml and frosting.db capture installation and update metadata, /data/system/packages.list can enumerate installed apps and paths, and accounts_ce.db/accounts_de.db store user account assignments used by applications — all valuable to corroborate that a package observed in usagestats belonged to an installed app and which user profile owned it [1] [2] [3].
4. Parsing challenges: protobufs, OEM variants and access requirements
Android 10’s shift to protobuf-encoded usagestats means investigators must use specific parsers or protobuf descriptors to decode IntervalStats files; researchers and tools (e.g., community scripts and commercial parsers integrated into AXIOM) have adapted to this change, but variations by Android version and OEM-layered services mean parsing is not uniform across all devices [5] [4]. Accessing the /data and system partitions to pull these files typically requires a physical image, root-level access or forensic acquisition tools (ADB pulls of /data paths will often fail without privileged access), so collection constraints must be acknowledged [3].
5. Tooling and corroboration: what commercial and community tools surface
Commercial forensic suites (Belkasoft X, Magnet AXIOM) map and parse many of these artifacts into “Android Usage History” and “Application Activity” reports, including power and battery artifacts that corroborate app-active intervals; community projects and research artifacts also supply parsers and schemas for usagestats protobufs [2] [5] [7]. Practitioners should validate tool outputs against raw artifacts because some tools may not fully decode newer protobuf structures or OEM-specific files [5].
6. Limits of current reporting and investigative practice
Available public reporting catalogs common files and parsing approaches but cannot claim exhaustiveness across every OEM skin or Android patch level; sources catalog usagestats, Digital Wellbeing databases, reflection_gel_events.db, packages.xml/frosting.db and packages.list as primary targets, while warning that acquisition method and Android version materially affect what is recoverable [1] [2] [3]. Where sources do not enumerate every vendor-specific path or every protobuf field, examiners must treat findings as version- and device-dependent and corroborate with multiple artifacts before drawing behavioral conclusions [5] [4].