Cite as
Addai, D., SectraTEK Lab (2026). Reading one artifact in three evidence sources. LAB-0004, version 1.0. https://lab.sectratek.com/research/lab-0004/
Methodology note
Drafted with AI assistance and reviewed by the author before publication.
Summary
- A fact about a phone can sit in more than one source, but each source keeps its own record of it. A boot history, a log line, a count and a last-use time are four different things.
- Reach varies from about an hour (the system log inside a bug report: median 1.0 hour, at most 3.1) through days (Android usage statistics, App Ops history, the iOS unified log) to the 11.8 and 32.5 days of the two decoded sysdiagnose logs we read.
- Many permission and reset records keep a state or a last use, not a history. Such a record can confirm one date and deny none.
- A date is only as good as its clock. Some dates carry no year, some are local time without a zone, and one recovery clock printed 1970.
- Before you report a negative, say which source, which store, how far back it reaches, which clock dates it, and whether it keeps history.
One question, three containers
An examiner is rarely asked what a phone holds. The question is whether it restarted, whether an app used the camera, whether it was reset. What arrives depends on the case: a full file system extraction, an Android bug report, or an iOS sysdiagnose. It is natural to assume that all three can answer the same question, perhaps with different detail. That assumption is the one this article tests against the Lab's Technical Reports.
The three containers are made differently, and the difference decides what they can say.
- Full file system extraction
- A copy of the files on the phone, read in place. It holds databases with their write-ahead logs, property files, log files and many small stores, some that accumulate and some that roll over. On Android and iOS.
- Bug report
- A zip file the Android phone builds on request. Its main file is a text dump of hundreds of system services and several logs, each as they stood at that moment. A service dump can be cut at the device's time limit. Android only.
- Sysdiagnose
- An archive the iPhone writes on request. It carries the unified log of the device as compressed log files, which a decoder turns back into records, and a set of state files. iOS only.
We use four questions throughout: did the phone restart, which app used a protected resource, was the phone reset, and was an app opened on a given day. For each one the Lab's reports measured what some store holds on some devices. This article puts those results side by side. It does not claim that we saw one phone through all three sources.
Pick a question and a source
Figure 1 is the explorer. Choose a question, then a source. The panel shows what is readable, how far back it reaches on a log scale, which clock dates it, and what it cannot say. The example record is a synthetic example written with offsets from a time t0; it is not a value from any device. If scripts are off, the table under the figure holds the same content.
Full file system extraction. Android and iOS
Did the phone restart, and when?
Can say in part
What is readable
Android. The boot-reason history in persistent_properties: one line per boot with a reason and a time. On Samsung phones the recovery history also lists each start of the recovery environment.
iOS. The unified-log files. Their records carry a boot-session identifier, so boots inside the log window can be counted.
The clock
Android: UTC epoch seconds written by the running system. iOS: log file start times in UTC.
The limit
Only the last few boots survive, and a reason can be free text. A missing entry does not show that no restart happened. An entry does not say who restarted the phone.
How far back
- Android boot-reason historyupper bound: last few boots, oldest at most 32 d before newest on 12 of 14
- iOS unified log, Persist streammedian 2.5 d
- iOS unified log, Special streammedian 24.0 d
The history held 42 entries on 14 extractions, two to four per phone. This is a count of boots, not a window counted back from capture.
Example record synthetic example
boot-reason history, newest first
reboot,userrequested,<t0 - 2 d>
reboot,<t0 - 9 d>Bug report. Android only
Did the phone restart, and when?
Can say in part
What is readable
Android. The same boot-reason history, present in all 7 reports in our sample (23 entries, two to four each). Samsung reports may also carry copies of the recovery history (3 of 7). The system log is in the report but is short.
The clock
One device clock for the whole report. Log lines carry month, day and time but no year; the year is taken from the report header.
The limit
A restart two days ago may be in the boot history and will not be in the log. A section the device cut at its time limit says nothing about what it did not reach.
How far back
- Bug report, system log bodymedian 1.0 h, longest 3.1 h
The boot history is a count of boots, as in an extraction. The system log body is the only dated window in this report for the question.
Example record synthetic example
boot-reason history: 3 entries
log line: MM-DD HH:MM:SS.mmm (no year)Sysdiagnose. iOS only
Did the phone restart, and when?
Can say in part
What is readable
iOS. The unified log of the archive, after decoding. Count the distinct boot identifiers in its window: 25 in an 11.8-day log and 2 in a 32.5-day log, from two different devices.
The clock
Log record times. The decoder matters: one without the log codec of iOS 27.0 archives recovered 4.6 percent of the records and still reported completion with warnings. Record the decoder version.
The limit
A count of boot identifiers is a count, not a reason. The two logs differ in device and use, so the counts say nothing about the two iOS releases.
How far back
- Sysdiagnose log, one iOS 27.0 archive11.8 d, one device
- Sysdiagnose log, one iOS 26.6 archive32.5 d, one device
Two archives, two devices. We did not measure sysdiagnose windows on a sample.
Example record synthetic example
boot identifier A: t0 - 11 d to t0 - 4 d
boot identifier B: t0 - 4 d to t0
2 identifiers: at least one boot changeFull file system extraction. Android and iOS
Which app used the camera, microphone or location, and when?
Can say in part
What is readable
Android. App Ops history databases: one row per time window, with the first access in the window and a count. A second file, appops_accesses.xml, holds the last access for each app and operation.
iOS. The privacy permission table (TCC): one row per service and app, with a decision and the date of its last change.
The clock
Android: epoch times. A database time is the first access of its window and the XML time is the last access, so they are equal for only 54 percent of XML times inside the database span.
The limit
A row is an aggregate: a count without every time. A last-access time can confirm one date and deny none. On iOS the date is the last change of a grant, not a use.
How far back
- Android App Ops history databasesmedian 7.8 d
The last-access file held a median of 2,081 dated entries per phone, 39 percent within 30 days and 14 percent older than a year. The iOS table held a median of 160 rows, 27 percent changed within 30 days.
Example record synthetic example
history row: package=org.example.recorder op=RECORD_AUDIO t=T count=3
XML entry: package=org.example.recorder op=RECORD_AUDIO last=T + 40 s
TCC row: service=camera decision=allowed changed=t0 - 210 dBug report. Android only
Which app used the camera, microphone or location, and when?
Can say in part
What is readable
Android. The App Ops service dump: mode lines per user id and package, and an access line for each recorded access with a printed time and an offset before the dump. 12,761 dated entries over 7 reports. An hour-long table for location, microphone and camera appeared in 1 of 5 reports.
The clock
The printed time minus its offset gives one instant per report (spread 0.0 s), the moment of the dump. All five reports checked were in UTC+0.
The limit
A snapshot at dump time. On three of five reports 99.1 to 99.8 percent of the user-id mode lines read ignore, so they carry little per-app information.
How far back
- Bug report, App Ops dump (last access)median 432 d, last use only
Last-access times reach back far because they are last-use records. They are not a history.
Example record synthetic example
RECORD_AUDIO Access: <printed time> (<4 h before dump>)
dump instant D = printed time + offsetSysdiagnose. iOS only
Which app used the camera, microphone or location, and when?
Little
What is readable
iOS. Unified-log lines for permission decisions: 6,099 in an 11.8-day log and 8,825 in a 32.5-day log. A cache dump gives a cached verdict and a reason for each writing process.
The clock
Log record times; the decoder version matters, as for the restart question.
The limit
The requesting app is usually <private> in the line. In one sysdiagnose checked for camera sessions, all 102 sessions came from the face-authentication daemon and none from the Camera app or another app. A log alone does not show which app used a sensor.
How far back
- Sysdiagnose log, one iOS 27.0 archive11.8 d, one device
- Sysdiagnose log, one iOS 26.6 archive32.5 d, one device
Two decoded logs from two devices.
Example record synthetic example
request: service=<name> requester=<private>
result: decision=<n> reason=<n>Full file system extraction. Android studied; iOS not studied
Was the phone reset, and when?
Can say in part
What is readable
Android. The Samsung recovery history: a factory reset confirmed in Settings appears as a wipe entry with a requested time, and format lines under the same two-letter code in the companion file. Also the boot-reason history and the setup flags.
iOS. Not studied. No Lab report studies reset traces on iOS.
The clock
Two clocks in one entry: the header time, from the recovery program (plausible on 4 of 9 histories, wrong on others), and the requested time, device local time written by the requesting program.
The limit
Absent on all three units of one flagship generation, so absence there says nothing. An entry shows recovery was started with these options, not that the reset finished. None of 65 boot-reason entries was a factory-reset entry. A date estimated from another entry held on one phone and was off by 526 days on another.
How far back
- Android boot-reason historyupper bound: last few boots, oldest at most 32 d before newest on 12 of 14
The recovery history was on 9 of 12 Samsung extractions and keeps entries as they accumulate (132 entries in all). It is not a fixed window. The boot-reason history keeps only the last few boots.
Example record synthetic example
--wipe_data
--reason=MasterClearConfirm
--requested_time=<t0, device local>
extra_history: [Qx][S] format_volume : /dataBug report. Android only
Was the phone reset, and when?
Little
What is readable
Android. Copies of the recovery history in 3 of 7 reports (1, 4 and 19 entries, none a wipe), the boot-reason history in 7 of 7, and the setup-flag history blocks.
The clock
One device clock. The setup-flag history blocks print month, day and time but no year.
The limit
Four of seven reports had no recovery copy, so a missing wipe entry says nothing. The boot history and the setup flags have the same limits as in an extraction: a flag change alone is not a reset.
How far back
- Bug report, system log bodymedian 1.0 h, longest 3.1 h
No window was measured for the recovery copies. The log body is hours.
Example record synthetic example
recovery copy: present in 3 of 7 reports
setup flag block: MM-DD HH:MM:SS.mmm (no year)Sysdiagnose. iOS only
Was the phone reset, and when?
Not studied
What is readable
iOS. No Lab report studies reset traces in a sysdiagnose. The Lab reads setup indicators on iOS to bound the start of a phone's life; that is not a reset study.
The clock
Not studied.
The limit
This article makes no statement for this cell.
How far back
No window measured for this source.
The Lab has not measured this.
Example record synthetic example
No example: not studied.Full file system extraction. Android and iOS
Was an app opened on a given day?
Can say in part
What is readable
Android. Usage statistics: daily files with events, and longer weekly, monthly and yearly files.
iOS. Biome app-focus segments, and the knowledgeC app-focus stream where it holds records.
The clock
Android: epoch milliseconds in file names. iOS: Biome segment names, read as microseconds since 2001 and checked against file times.
The limit
Beyond about ten days an Android phone keeps only coarse aggregates. A phone can be younger than the question: 13 of 33 iPhones and 5 of 14 Android phones were under a year old at acquisition.
How far back
- Android daily usage statisticsmedian 9.8 d
- iOS Biome app focusmedian 38 d, on 25 of 33 iPhones
knowledgeC app focus held records on only 2 of 33 iPhones. For a day 30 days back, app use was answerable on 17 of 33 iPhones and 0 of 14 Android phones.
Example record synthetic example
daily usage file: name = epoch ms for t0 - 6 d
app-focus segment: name = microseconds since 2001Bug report. Android only
Was an app opened on a given day?
Little
What is readable
Android. A usage-events section with recent events.
The clock
One device clock, as for the rest of the report.
The limit
One day of events. A question about last week is not answerable from this source.
How far back
- Bug report, usage eventsabout 1 d, on 4 of 7 reports
The window was about one day on 4 of 7 reports.
Example record synthetic example
usage events: t0 - 20 h to t0Sysdiagnose. iOS only
Was an app opened on a given day?
Little
What is readable
iOS. BatteryUI per-app runtime buckets. In the iOS 26 archives a bucket is 3,600 s wide; in the iOS 27.0 archive it is 86,400 s wide.
The clock
Bucket boundaries, not event times.
The limit
A runtime bucket is not an open event, and a day-wide bucket cannot place use inside the day. The widths come from archives of three devices, so they are hypotheses about the releases.
How far back
No window measured for this source.
Not measured. The sysdiagnose archives came from three devices, below the cell minimum of the retention study.
Example record synthetic example
app=org.example.chat bucket=[t0 - 2 d, t0 - 1 d) runtime=1,260 sRestart, full file system extraction: can say in part. Android keeps only the last few boots; the iOS log reaches days.
Show this figure as a table
| Question | Source | Can say | Readable | How far back | Clock | Limit |
|---|---|---|---|---|---|---|
| Restart | Full file system | Can say in part | Android: The boot-reason history in persistent_properties: one line per boot with a reason and a time. On Samsung phones the recovery history also lists each start of the recovery environment. iOS: The unified-log files. Their records carry a boot-session identifier, so boots inside the log window can be counted. | Android boot-reason history: upper bound: last few boots, oldest at most 32 d before newest on 12 of 14; iOS unified log, Persist stream: median 2.5 d; iOS unified log, Special stream: median 24.0 d The history held 42 entries on 14 extractions, two to four per phone. This is a count of boots, not a window counted back from capture. | Android: UTC epoch seconds written by the running system. iOS: log file start times in UTC. | Only the last few boots survive, and a reason can be free text. A missing entry does not show that no restart happened. An entry does not say who restarted the phone. |
| Restart | Bug report | Can say in part | Android: The same boot-reason history, present in all 7 reports in our sample (23 entries, two to four each). Samsung reports may also carry copies of the recovery history (3 of 7). The system log is in the report but is short. | Bug report, system log body: median 1.0 h, longest 3.1 h The boot history is a count of boots, as in an extraction. The system log body is the only dated window in this report for the question. | One device clock for the whole report. Log lines carry month, day and time but no year; the year is taken from the report header. | A restart two days ago may be in the boot history and will not be in the log. A section the device cut at its time limit says nothing about what it did not reach. |
| Restart | Sysdiagnose | Can say in part | iOS: The unified log of the archive, after decoding. Count the distinct boot identifiers in its window: 25 in an 11.8-day log and 2 in a 32.5-day log, from two different devices. | Sysdiagnose log, one iOS 27.0 archive: 11.8 d, one device; Sysdiagnose log, one iOS 26.6 archive: 32.5 d, one device Two archives, two devices. We did not measure sysdiagnose windows on a sample. | Log record times. The decoder matters: one without the log codec of iOS 27.0 archives recovered 4.6 percent of the records and still reported completion with warnings. Record the decoder version. | A count of boot identifiers is a count, not a reason. The two logs differ in device and use, so the counts say nothing about the two iOS releases. |
| Permission use | Full file system | Can say in part | Android: App Ops history databases: one row per time window, with the first access in the window and a count. A second file, appops_accesses.xml, holds the last access for each app and operation. iOS: The privacy permission table (TCC): one row per service and app, with a decision and the date of its last change. | Android App Ops history databases: median 7.8 d The last-access file held a median of 2,081 dated entries per phone, 39 percent within 30 days and 14 percent older than a year. The iOS table held a median of 160 rows, 27 percent changed within 30 days. | Android: epoch times. A database time is the first access of its window and the XML time is the last access, so they are equal for only 54 percent of XML times inside the database span. | A row is an aggregate: a count without every time. A last-access time can confirm one date and deny none. On iOS the date is the last change of a grant, not a use. |
| Permission use | Bug report | Can say in part | Android: The App Ops service dump: mode lines per user id and package, and an access line for each recorded access with a printed time and an offset before the dump. 12,761 dated entries over 7 reports. An hour-long table for location, microphone and camera appeared in 1 of 5 reports. | Bug report, App Ops dump (last access): median 432 d, last use only Last-access times reach back far because they are last-use records. They are not a history. | The printed time minus its offset gives one instant per report (spread 0.0 s), the moment of the dump. All five reports checked were in UTC+0. | A snapshot at dump time. On three of five reports 99.1 to 99.8 percent of the user-id mode lines read ignore, so they carry little per-app information. |
| Permission use | Sysdiagnose | Little | iOS: Unified-log lines for permission decisions: 6,099 in an 11.8-day log and 8,825 in a 32.5-day log. A cache dump gives a cached verdict and a reason for each writing process. | Sysdiagnose log, one iOS 27.0 archive: 11.8 d, one device; Sysdiagnose log, one iOS 26.6 archive: 32.5 d, one device Two decoded logs from two devices. | Log record times; the decoder version matters, as for the restart question. | The requesting app is usually <private> in the line. In one sysdiagnose checked for camera sessions, all 102 sessions came from the face-authentication daemon and none from the Camera app or another app. A log alone does not show which app used a sensor. |
| Reset | Full file system | Can say in part | Android: The Samsung recovery history: a factory reset confirmed in Settings appears as a wipe entry with a requested time, and format lines under the same two-letter code in the companion file. Also the boot-reason history and the setup flags. iOS: Not studied. No Lab report studies reset traces on iOS. | Android boot-reason history: upper bound: last few boots, oldest at most 32 d before newest on 12 of 14 The recovery history was on 9 of 12 Samsung extractions and keeps entries as they accumulate (132 entries in all). It is not a fixed window. The boot-reason history keeps only the last few boots. | Two clocks in one entry: the header time, from the recovery program (plausible on 4 of 9 histories, wrong on others), and the requested time, device local time written by the requesting program. | Absent on all three units of one flagship generation, so absence there says nothing. An entry shows recovery was started with these options, not that the reset finished. None of 65 boot-reason entries was a factory-reset entry. A date estimated from another entry held on one phone and was off by 526 days on another. |
| Reset | Bug report | Little | Android: Copies of the recovery history in 3 of 7 reports (1, 4 and 19 entries, none a wipe), the boot-reason history in 7 of 7, and the setup-flag history blocks. | Bug report, system log body: median 1.0 h, longest 3.1 h No window was measured for the recovery copies. The log body is hours. | One device clock. The setup-flag history blocks print month, day and time but no year. | Four of seven reports had no recovery copy, so a missing wipe entry says nothing. The boot history and the setup flags have the same limits as in an extraction: a flag change alone is not a reset. |
| Reset | Sysdiagnose | Not studied | iOS: No Lab report studies reset traces in a sysdiagnose. The Lab reads setup indicators on iOS to bound the start of a phone's life; that is not a reset study. | Not measured The Lab has not measured this. | Not studied. | This article makes no statement for this cell. |
| App use | Full file system | Can say in part | Android: Usage statistics: daily files with events, and longer weekly, monthly and yearly files. iOS: Biome app-focus segments, and the knowledgeC app-focus stream where it holds records. | Android daily usage statistics: median 9.8 d; iOS Biome app focus: median 38 d, on 25 of 33 iPhones knowledgeC app focus held records on only 2 of 33 iPhones. For a day 30 days back, app use was answerable on 17 of 33 iPhones and 0 of 14 Android phones. | Android: epoch milliseconds in file names. iOS: Biome segment names, read as microseconds since 2001 and checked against file times. | Beyond about ten days an Android phone keeps only coarse aggregates. A phone can be younger than the question: 13 of 33 iPhones and 5 of 14 Android phones were under a year old at acquisition. |
| App use | Bug report | Little | Android: A usage-events section with recent events. | Bug report, usage events: about 1 d, on 4 of 7 reports The window was about one day on 4 of 7 reports. | One device clock, as for the rest of the report. | One day of events. A question about last week is not answerable from this source. |
| App use | Sysdiagnose | Little | iOS: BatteryUI per-app runtime buckets. In the iOS 26 archives a bucket is 3,600 s wide; in the iOS 27.0 archive it is 86,400 s wide. | Not measured Not measured. The sysdiagnose archives came from three devices, below the cell minimum of the retention study. | Bucket boundaries, not event times. | A runtime bucket is not an open event, and a day-wide bucket cannot place use inside the day. The widths come from archives of three devices, so they are hypotheses about the releases. |
Three patterns repeat. First, for a restart the extraction and the bug report hold the same short boot list, and what differs is the log beside it: days in an iOS extraction, hours in a bug report, a decoded window of weeks in a sysdiagnose. Second, for a permission use the extraction holds the most on Android, but a row is an aggregate or a last access; on iOS the permission table records grants, and the log hides the requester. Third, a reset leaves its richest trail on one manufacturer's Android phones, and for the other cells the honest entry is little or not studied.
How far back each source reaches
An empty result is an answer only if the store reached the day in question. Figure 2 puts the stores of Figure 1 on one scale. Choose how long before capture the event happened, and see which stores have a typical reach at least that long.
- Full file system extraction
- Android boot-reason historyupper bound: last few boots, oldest at most 32 d before newest on 12 of 14
- Android App Ops history databasesmedian 7.8 d
- Android daily usage statisticsmedian 9.8 d
- iOS unified log, Persist streammedian 2.5 d
- iOS unified log, Special streammedian 24.0 d
- iOS Biome app focusmedian 38 d, on 25 of 33 iPhones
- Bug report (Android)
- Bug report, system log bodymedian 1.0 h, longest 3.1 h
- Bug report, event log bodymedian 0.5 h, longest 2.9 h
- Bug report, usage eventsabout 1 d, on 4 of 7 reports
- Bug report, App Ops dump (last access)median 432 d, last use only
- Sysdiagnose (iOS)
- Sysdiagnose log, one iOS 27.0 archive11.8 d, one device
- Sysdiagnose log, one iOS 26.6 archive32.5 d, one device
Show this figure as a table
| Store | Source | Reach | Kind of record |
|---|---|---|---|
| Android boot-reason history | Full file system extraction | upper bound: last few boots, oldest at most 32 d before newest on 12 of 14 | upper bound on a short list of boots |
| Android App Ops history databases | Full file system extraction | median 7.8 d | dated history or window |
| Android daily usage statistics | Full file system extraction | median 9.8 d | dated history or window |
| iOS unified log, Persist stream | Full file system extraction | median 2.5 d | dated history or window |
| iOS unified log, Special stream | Full file system extraction | median 24.0 d | dated history or window |
| iOS Biome app focus | Full file system extraction | median 38 d, on 25 of 33 iPhones | dated history or window |
| Bug report, system log body | Bug report (Android) | median 1.0 h, longest 3.1 h | dated history or window |
| Bug report, event log body | Bug report (Android) | median 0.5 h, longest 2.9 h | dated history or window |
| Bug report, usage events | Bug report (Android) | about 1 d, on 4 of 7 reports | dated history or window |
| Bug report, App Ops dump (last access) | Bug report (Android) | median 432 d, last use only | last use (one date per record) |
| Sysdiagnose log, one iOS 27.0 archive | Sysdiagnose (iOS) | 11.8 d, one device | dated history or window |
| Sysdiagnose log, one iOS 26.6 archive | Sysdiagnose (iOS) | 32.5 d, one device | dated history or window |
Reach follows what bounds a store. Stores pruned by age sat at their limit on most phones: Android daily usage statistics within 10.2 days, DropBox entries within 3.1 days and notification history within 1.5 days. Stores kept to a size had no typical reach: the Persist stream of the iOS unified log ran from 0.39 to 21.2 days across 19 phones on the same release. A single published figure for such a store describes one device.
The oldest record can also overstate the window. An iOS database read without its write-ahead log showed an older oldest record than the database with its log on 18 of 25 phones, because the log already held deletions that the main file did not. In 4 of 7 bug-report system logs, a few stray lines up to 16.6 days old sat above a body of at most 3.1 hours. Count a bug-report log from the start of its body, and read databases with their logs applied.
Two more limits sit outside the store. The phone may be younger than the question: 13 of 33 iPhones and 5 of 14 Android phones were under a year old at acquisition. And for sysdiagnose we have only two decoded logs and no sample, so the two bars in Figure 2 are single archives, not medians.
Whose clock stamps the date
The same moment can be printed in different ways, and a wrong clock does not show in the date it prints. Figure 3 lists the clocks behind the dates in Figure 1.
| Date | Found in | Whose clock | Year and zone | What to check |
|---|---|---|---|---|
| Android boot-reason history | Extraction, bug report | The running system, as UTC epoch seconds. | Epoch, so no year problem. | Free-text reasons; only the last few boots. |
| Samsung recovery header time | Extraction, some bug reports | The recovery program's own clock. | Printed year can be 1970 or wrong; plausible on 4 of 9 histories. | Compare the gap between two wipes with the gap between their requested times. |
| Samsung requested time | Extraction | The program that asked for the reset, in device local time. | Local time, not UTC. | Treat a time estimated from another entry as a candidate, never as recorded. |
| Android usage, DropBox, network files | Extraction | Time in the file name, epoch milliseconds. | Process statistics and Samsung battery files use local time with no zone (up to 14 h). | A horizon in days is not changed by a 14 h uncertainty. |
| Bug report log lines and flag history | Bug report | One device clock for the whole report. | Month, day and time; no year. Year taken from the report header. All 7 reports were UTC+0. | Zone and daylight-saving conversion are proven on constructed text only. |
| Bug report App Ops dump | Bug report | Printed time and an offset before the dump instant. | Time minus offset gave one instant per report (spread 0.0 s). | A snapshot at dump time, not a history. |
| iOS unified log | Extraction, sysdiagnose | File header start time, UTC seconds since 1970; record times from the log. | UTC. | Record the decoder version; compare records decoded with what the file predicts. |
| iOS knowledgeC, interactionC, Biome | Extraction | Seconds since 2001; Biome segment names read as microseconds since 2001. | Biome reading checked against file times on 102 of 102 segments. | Read databases with their write-ahead log applied. |
| The device clock itself | All | The newest dated record on the phone against the capture time. | Admit a phone if the gap is within 72 h before to 1 h after. | Failed on 6 of 32 iPhones with a reference time and 1 of 14 Android phones. |
Two examples show why this matters. A Samsung recovery entry carries a header time from the recovery program and a requested time from the program that asked for the reset. On one phone the header clock printed 1970. On a second phone the gap between two wipes was 118 days by header time and 644 days by requested time, a difference of 526 days. The printed year did not reveal the failure; comparing the two gaps did.
In a bug report, log lines carry no year, so the year is taken from the report header. All seven reports we read were in UTC+0, so zone and daylight-saving conversion has been tested only on constructed text. Before using any device-written date, the Lab compares the newest dated record on the phone with the capture time. It admits a phone if the gap lies between 72 hours before and 1 hour after. That rule failed on 6 of 32 iPhones that had a reference time and on 1 of 14 Android phones; in five of the six iPhone cases the reference was only the archive's file time, so the gap may measure later handling.
History, last use or state
A store can keep events dated when they happened (history), one record per subject dated at its latest event (last use), or a current value dated at its last change (state). A last-use or state record can confirm its one date and deny no other.
The Android App Ops record shows how this works. A history row holds the first access in a time window and a count. The XML file holds the last access. Of the XML times that fall inside the database span, 54 percent equal a database time. Of the rest, 81 percent fall inside a window that counted more than one access, as the platform source predicts. On the 13 phones that had both forms, 66 percent of the last-access entries were older than the oldest history row. Such an entry is the only dated trace of an access beyond the reach of the history, and it cannot say anything about the days around it.
On iOS the permission table holds a median of 160 rows per phone, each with one date, the last change. A question of the type "did the app use the camera on that day" is at most partly answerable from it. In the bug report the App Ops dump is a snapshot at the moment of the dump, with times printed relative to it.
A routine you can repeat
On a test phone you own, create known events at written times: restart it, grant and use one permission once, open one app. Capture the sources your platform offers, close together. Then read each fact with these steps.
- Name the source and the platform. A negative from a bug report is not a negative from an extraction.
- Name the store that would hold the fact, and say whether it keeps history, a last use or a state.
- State the window. The oldest and newest dated record in that store, counted back from capture, with any database read together with its write-ahead log. For a bug-report log, count from the start of its body.
- State the clock. Whose clock, whether a year is printed, whether the time is UTC or local, and whether the clock was checked against the capture time.
- Check the capture. Look for sections cut at a time limit, the decoder version and its warnings, and the age of the device.
- Write the sentence. For example: "In the bug report, the system log reached back 1 hour and keeps events; it holds no record of the restart. This does not show that the phone did not restart."
The decoder step is not a formality. In one iOS 27.0 archive a decoder without the log codec recovered 4.6 percent of the records and still reported completion with warnings. A section that a bug report cut at its time limit is not a clean section either: it says nothing about what it did not reach.
What this does not prove
Read these before you rely on a panel
- We did not compare the three sources on one phone at one moment. The cells combine results from different devices. A bug report and an extraction in the collection are not known to come from the same phone.
- The numbers describe the Lab's research collection, not phones in general. Samsung supplies 12 of the 14 Android extractions, most iPhones run iOS 26, and cells are small.
- The sysdiagnose cells rest on two decoded logs and ten archives from three iPhones. Reach for sysdiagnose is not measured on a sample, and no Lab report studies reset traces on iOS.
- A record shows that a store held a value. It does not show who acted, why, or that the action finished.
- A missing record does not show that the event did not happen, in any of the three sources. It shows only that this store, read this way, held nothing.
- The dots in Figure 1 are our reading, not a measurement.
Sources
Every number in this article comes from a Lab Technical Report. LAB-TR-0001, 0003, 0004, 0009 and 0011 are on Zenodo (concept DOIs 10.5281/zenodo.23717909, 10.5281/zenodo.23717924, 10.5281/zenodo.23717926, 10.5281/zenodo.23717932 and 10.5281/zenodo.23717934). LAB-TR-0012, 0021 and 0029 are available on this site, with no DOI yet (LAB-TR-0012, LAB-TR-0021, LAB-TR-0029).
| Statement or number | Source | Where |
|---|---|---|
| Samples: 33 iOS and 14 Android full file system extractions, 7 Android bug reports; iOS 26 on 20 of 33 iPhones, iOS 15 to 18 on 12; Android 16 on 9 of 14 phones, Android 10 to 14 on 5; 12 of 14 Android phones Samsung; bug reports from Android 16 (4), 15 (1) and 10 (2) | LAB-TR-0029 | 4.1 |
| Sysdiagnose evidence: ten archives from three iPhones (iOS 26.6, 26.6.2, 27.0); two archives decoded as logs; 780 h and 283 h windows (32.5 and 11.8 days) | LAB-TR-0011; LAB-TR-0012 | 0011 Section 3.1 (Table 1), Section 4.6 (Table 7); 0012 Section 4 (Table 2) |
| Bug report and extraction not known to be from the same phone | LAB-TR-0021 | 4.1 |
| Android boot-reason history: on all 14 extractions and all 7 bug reports; 42 entries on 14 extractions (two to four per phone); 23 entries in 7 reports; oldest entry at most 32 days before newest on 12 extractions; none of 65 entries a factory-reset entry | LAB-TR-0004 | 5.1, 5.5 |
| Samsung recovery history: 9 of 12 Samsung extractions; absent on all three units of one flagship generation; 132 entries; copies in 3 of 7 bug reports with 1, 4 and 19 entries, none a wipe | LAB-TR-0004 | 5.1, Table 4 |
| Recovery header clock plausible on 4 of 9 histories; requested time is device local time; header gap 118 days against requested-time gap 644 days on one phone (difference 526 days) | LAB-TR-0004 | 1, 5.3, 5.4, Table 3 |
| Setup flags cycled 13 times on 8 phones that held no wipe entry | LAB-TR-0004 | 5.6, Table 3 |
| Canonical boot reasons such as reboot,userrequested (public documentation) | AOSP: source.android.com/docs/core/architecture/bootloader/boot-reason | Page |
| Android App Ops: history databases reach a median of 7.8 days; daily usage statistics median 9.8 days; Biome app focus on 25 of 33 iPhones, median 38 days; knowledgeC app focus on 2 of 33; bug-report usage events about 1.0 day on 4 of 7 reports; App Ops dump last access median 432 days | LAB-TR-0029 | 5.3, Table 4 |
| Answerable at 30 days: app use on 17 of 33 iPhones and 0 of 14 Android phones; permission use on 0 and 2 | LAB-TR-0029 | 5.4, abstract |
| Last-access file: median 2,081 dated entries per phone, 39% within 30 days, 14% older than a year; iOS TCC table median 160 rows, 27% changed within 30 days; bug-report App Ops dump 12,761 dated entries over 7 reports; on 13 phones with both forms 66% of last-access entries older than the oldest history row | LAB-TR-0029 | 5.6, Table 7 |
| 13 of 33 iPhones and 5 of 14 Android phones under a year old at acquisition | LAB-TR-0029 | 5.2, Table 3 |
| App Ops: 54% of XML times inside the database span equal a database time; 81% of the rest fall inside a window that counted more than one access | LAB-TR-0003 | 5.3, 5.4, abstract |
| Bug report App Ops dump: 99.1 to 99.8 percent of user-id mode lines read ignore on three of five reports; time minus offset gives one instant (spread 0.0 s); all five reports UTC+0; one-hour table in 1 of 5 reports | LAB-TR-0003 | 5.5, Table 8 |
| iOS Persist stream median 2.5 days, Special 24.0 days; Persist 0.39 to 21.2 days within iOS 26 (19 phones) | LAB-TR-0021 | 5.2 (Table 4), 5.5 (Table 6) |
| Android limits: daily usage within 10.2 days, DropBox within 3.1, notification history within 1.5 | LAB-TR-0021 | 5.3, Table 5 |
| Bug report logs: system log body median 0.04 days (1.0 h) and longest 3.1 h; event log body median 0.02 days and longest 2.9 h; stray head lines up to 16.6 days in 4 of 7 system logs | LAB-TR-0021 | 5.4, Table 5 |
| interactionC read without its write-ahead log showed an older oldest record on 18 of 25 phones | LAB-TR-0021 | 5.8, Table 7 |
| Clock rule (newest record within 72 h before to 1 h after capture); failed on 6 of 32 iPhones with a reference time and 1 of 14 Android phones; Biome name reading confirmed on 102 of 102 segments; process statistics and Samsung battery files in local time with up to 14 h uncertainty | LAB-TR-0021 | 3.2, 3.3, 5.8, Tables 2 and 7 |
| Bug report log lines print month, day and time without a year; year taken from the header | LAB-TR-0021 | 3.2 |
| Sysdiagnose log: distinct boot identifiers 25 (11.8 days) and 2 (32.5 days); decoder without the iOS 27.0 codec recovered 4.6% of records and reported completion with warnings; BatteryUI buckets 3,600 s in iOS 26 archives and 86,400 s in the iOS 27.0 archive; access payloads for permission checks remain private | LAB-TR-0011 | 4.1, 4.3, 4.6 (Table 7) |
| TCC results: 6,099 in the iOS 27.0 log and 8,825 in the iOS 26.6 log; capture sessions in one iOS 26.5.2 sysdiagnose: 102, all from the face-authentication daemon; requester usually private | LAB-TR-0012 | 5.2, 5.3, 5.4 |
| Sysdiagnose archives not part of the retention sample (three devices, below the five-device cell minimum) | LAB-TR-0021 | 7 (Limitations) |
| Bug report holds dumps of hundreds of services and logs; a service dump can be cut at its time limit | LAB-TR-0001 | Abstract, 3.3 |
| Screen Time: reading the database without its write-ahead log changed at least one count on 14 of 17 stores | LAB-TR-0009 | Abstract |
Version history and corrections
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-11-06 | First publication. |
Corrections log
No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.