Lab Technical Report LAB-TR-0032
Resilience of Mobile Forensic Findings to the Loss of a Single Data Store
Lab Technical Report, preprint, not peer reviewed
Abstract
A finding about a phone is usually written as if the phone said it once. It rests on the stores that record the event, so a reader with fewer stores can reach another verdict. We define the witness set of an event and a finding’s resilience to losing stores, and prove that existence findings are monotone while absence findings are not: a lost store can turn a supported finding into an “absent” or an “unobservable”. We measured nine combinations of event type and evidence class that two or more stores can record, in 54 units (14 Android and 33 iOS extractions, 7 bug reports), with a linking rule validated on synthetic phones. In the median unit with two stores for the type, 88 percent of iOS text-message events, 43 percent of iOS call events, 59 percent of Android text-message events and 92 percent of Android screen-on events (extractions) had one witness. Linked records differed by under 7 seconds in the median, and 18 to 364 seconds for restarts. Without their only witness, 36 percent of single-witness iOS calls would read as absent, if the other store records at least half of calls. Reports should name each finding’s witnesses.
CCS Concepts • Applied computing → System forensics; • Information systems → Data provenance.
Keywords mobile forensics, corroboration, resilience, absence of evidence, event reconstruction, Android, iOS, empirical study
ACM Reference FormatDaniel Addai, Kingsley Albert Egyir, Sanders Larweh Tetteh, and Selorm Adjabeng. 2026. Resilience of Mobile Forensic Findings to the Loss of a Single Data Store. Lab Technical Report LAB-TR-0032, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0032/
1 Introduction
A finding about a phone is usually written as if the phone said it once: the device restarted on this day, the app was installed at this time, the call began at this minute. In fact the phone said it in as many places as keep a record of the event, and each place may be lost to a reader: an acquisition class that omits it, a tool that does not parse it, a retention limit that has erased it. Practice advises confirming reconstructed timelines through correlation and verification of evidence [8]. What is missing is a measure of how many stores witness an event on real phones, how well they agree, and what a reader concludes when one of them is missing.
A motivating example. Take a synthetic phone with two stores of restarts: a usage store that keeps ten days and a dropbox store that keeps three. Figure 1 shows nine days. The phone restarted on day 5 and on day 9; the dropbox store, which covers day 9, lost the entry for that restart. A reader with both stores finds a restart on day 9. A reader whose acquisition lacks the usage store finds the dropbox store silent on day 9 and writes that the phone did not restart: a confident absence, produced by a correct reading of the stores that reader had. The same reader cannot say anything about days 1 to 7, which no store they hold covers. Neither reader made an error of procedure. The first claim, that a restart occurred, can only gain support as stores are added; the second, that none occurred, can be overturned by adding one.
The problem. An examiner needs to know, for each finding, how many stores stand behind it, whether those stores can fail together, and what the finding becomes if some are missing. We ask four questions about Android and iOS stores.
- RQ1 (Definition). How can the witnesses of an event, and the resilience of a finding to their loss, be defined so that the effect on existence and absence claims is exact?
- RQ2 (Witness counts). For common event types, how many stores witness an event on real phones, and how often is a single store the only witness?
- RQ3 (Agreement). How closely do the stores that witness one event agree on its time?
- RQ4 (Loss). When the only witness is lost, how often do the remaining stores cover the time and so allow a reader to find absence, and how often is the finding unobservable?
Table 1 summarises the answers.
| RQ | Answer | Evidence |
|---|---|---|
| RQ1 Definition | The witness set of an event is the set of stores that hold a record of it. A finding is present, absent and observable, or unobservable. Existence findings are monotone in the stores read; absence findings are not. The number of stores that can be lost is the finding’s resilience, and it counts writers or families when stores fail together. | Section 3; four propositions with proofs |
| RQ2 Witness counts | In the median unit, 88 percent of iOS text-message events, 43 of iOS call events, 59 of Android text-message events, 92 of Android screen-on events, 94 of Android connected-call events and 89 of Android app first installs had one witness. App last updates had 30 percent. | Section 5.2; Table 4; Figure 3 |
| RQ3 Agreement | Where stores matched, the median difference was under 7 seconds for every type except restarts (18 to 364 seconds). Messages matched to the second in the median. | Section 5.3; Table 5 |
| RQ4 Loss | When the only witness is lost, another store covers the time for 36 percent of single-witness iOS calls and 29 percent of Android screen-on events; it is read as absence only if that store is trusted: for iOS calls, 36 percent of single-witness events have a covering store that records at least half of such calls. | Sections 5.4 and 5.5; Tables 6 to 8; Figure 4 |
Contributions. This report makes four contributions.
- A model of witness sets, three verdicts (present, absent and observable, unobservable) and resilience to the loss of stores, writers or families, with four propositions and proofs: existence is monotone, absence is not, store counts overstate protection when stores share a writer, and a narrative is as resilient as its weakest finding (Section 3).
- A linking and coverage rule for events across stores, with a detection rate that turns an “observer” into a measured quantity, validated on synthetic phones with known events and by property tests of the propositions on 3,000 random units (Sections 4 and 5.1).
- A measurement of seven event types (nine with the evidence class) in 54 research units: witness counts, timestamp agreement, single-witness shares, and what loss would leave (Sections 5.2 to 5.6).
- A reporting rule, and released code and synthetic data that reproduce the method (Sections 6 and Artifact Availability).
Scope. An event here is whatever the stores record; two stores may count different things as the same kind of event, and a store with no record is not proof that nothing happened. The results describe 54 research units, 12 of the 14 Android extractions being Samsung phones; Section 7 gives the limits.
2 Related Work
2.1 Corroboration, certainty and absence
Casey proposes an interim, standardised way to express the strength of a preliminary evaluative opinion on digital evidence within a Bayesian framework, with a strength-of-evidence scale (the C-Scale) [10]. We read the abstract and the use of the scale in a survey [8], not the full text, so we make no statement about how the scale treats the number of sources. A survey of timeline reconstruction names artifact persistence and the interpretation of absence as open problems [8]. Biedermann and Vuille treat the absence of data on a device as evidence whose weight depends on the probability that the data would have been recorded had the event occurred [7]; Horsman and Errickson discuss when finding nothing is evidence of something [14]. Sensitivity analyses of Bayesian networks vary likelihoods and report how conclusions move [17]. A claim-level verification framework for Windows artifacts links each claim to its supporting evidence, records conflict and explained absence, and reports the loss of the evidence behind a claim separately from the degradation of an artifact family, in seven controlled scenarios (abstract read only) [20]. Earlier work on smartphones as “distributed witnesses” reconstructs events from the databases of several phones together [19]; our witnesses are stores within one device. These works motivate our questions. None of those we could read counts witnesses per event, removes a store and reports the change, or measures on phones how often a single store is the only witness.
2.2 Time across stores
Work on timelines separates time domains, orders events by implicit counters, anchors clocks to external events and shows that normalisation does not always make timestamps comparable [11, 21, 15]. An experiment on four Android phones records which artifacts follow the device clock and which keep external time [16]. We take the existence of such differences as given and measure, for linked records of one event, how far the stored times lie apart.
2.3 Resilience, witnesses and redundancy in other fields
Database theory defines the resilience of a Boolean query as the minimum number of tuples whose deletion makes it false [13], and uses “witness” for the tuples that make a query true [9]; causality and responsibility for answers and non-answers extend the idea to absence [18]. Reliability engineering treats redundancy as protection only when failures are independent [6]. Linking records of one entity across sources has a long statistical literature [12]. We borrow the definition of resilience and the word witness, with stores as the deletable units, and we add what is specific to phones: the coverage of each store, the three-valued verdict, and a measured detection rate.
2.4 Earlier Lab reports
Two stores of one fact were compared for App Ops history [1]. Reports on retention horizons, device-life boundaries and answerability establish how far back a store reaches, where a device’s own life begins, and whether a date-bound question can be answered at all [3, 4, 5]; a report on evidence-state accounting names the states in which a security setting can be found or not found [2]. Those reports ask whether any store can answer. This report starts where an answer exists and asks how many stores stand behind it.
Position of this work. Corroboration across sources is old advice. What we add is a definition of the loss of a store that separates existence from absence, a proof that the two behave differently, and a measurement of witness counts, agreement and exposure on 54 units. In a search of arXiv, Zenodo, OpenAlex, Crossref and publisher sites on 29 October 2026 we found no prior work that defines or measures this on phones; the closest are a Windows framework that separates the loss of a claim’s evidence from the degradation of an artifact family [20] and a model that uses whole phones as witnesses [19]. The search was limited, because several publisher and conference pages could not be read (Section 7) and we could not read the full text of Casey (2020). A reader who knows of such work should treat our claim to novelty as void for it.
3 Model
3.1 Stores, events and witnesses
An evidence unit holds a set S of stores. For an event type τ, a store s has a coverage covs(τ): the interval of time over which it retains records of that type, taken from the span of its own records. An event e of type τ has a time and may have a key such as a package name. A store holds a record of e when a record is linked to it by the rule of Section 4.2. The witness set W(e) is the set of stores that hold a record of e. Each store has a writer, the component that writes its records, and belongs to a family (Table 2). “Witness” has other meanings in database theory; here it always means a store that holds a linked record.
3.2 Findings and verdicts
A finding F = (τ, w) says that an event of type τ occurred in the time window w. For a set X of stores that a reader holds, a store observes w if its coverage contains w. The verdict VX(F) is P (present) if some store in X holds a record in w; otherwise A (absent and observable) if some store in X observes w; otherwise U (unobservable). The negation of F is supported when the verdict is A. Figure 1 shows the three verdicts.
3.3 Resilience and four propositions
Let WX(F) be the stores of X that hold a record in w. When the verdict is P, the resilience ρ(F) = |WX(F)| − 1 is the number of stores that can be lost, in any combination, with the finding still supported. This is the resilience of a monotone Boolean query [13] with stores as the units of deletion. Replacing stores by writers gives ρw, and by families ρf.
Proposition 1 (existence is monotone). If X ⊆ Y and VX(F) = P, then VY(F) = P. Proof. P holds if some store of the reader holds a record in w; that store is also in Y. □
Proposition 2 (what loss leaves). Let VX(F) = P and Z ⊆ X. (a) If WX(F) ⊈ Z, then VX∖Z(F) = P. (b) If WX(F) ⊆ Z, the verdict is A when some store of X∖Z observes w and U otherwise. (c) If VX(F) = A and a store s ∉ X holds a record in w, then VX∪{s}(F) = P; absence is therefore not monotone. (d) A verdict A becomes U exactly when Z contains every observer of w. Proof. Each part follows from the three-way definition of the verdict by case analysis on whether a remaining store holds a record in w and whether a remaining store observes w. □
The loss of one store therefore turns a supported existence finding into a supported absence finding exactly when it was the only witness and another store observes the window. This is the exposure we measure in Section 5.4.
Proposition 3 (shared writers). ρw(F) ≤ ρ(F), with equality if each writer has one witnessing store. If every writer fails independently with probability q and the stores of a writer fail together, the finding is lost with probability q|w(W)|, where |w(W)| is the number of distinct writers, not q|W|. Proof. The map from stores to writers cannot increase the size of a set. The finding is lost exactly when every writer in w(W) fails. □ Independence of redundant versions is the assumption on which redundancy protects [6]; Table 2 marks the stores that share a writer.
Proposition 4 (narratives). For findings F1, …, Fm that all hold, ρ(F1 ∧ … ∧ Fm) = mini ρ(Fi). Proof. The conjunction fails when any conjunct fails, and the smallest set of stores whose loss falsifies Fi is its witness set, so the smallest killing set has size mini |W(Fi)|. □ If a share s of findings has one witness and findings are independent, a narrative of m findings has ρ ≥ 1 with probability (1 − s)m; with s = 52.5 percent, the pooled share for iOS call events (Table 4), a narrative of five calls reaches ρ ≥ 1 with probability 2.4 percent.
3.4 Observers that miss events
Verdict A treats an observer as a perfect recorder. Its soundness needs the assumption that a store whose coverage contains an event holds a record of it, which real stores do not satisfy. For a store o, let its detection rate do be the share of events witnessed by some other store inside o’s coverage that o also holds. Requiring do ≥ θ of an observer gives the verdict Aθ; θ = 0 is the verdict above. The rate is estimated from events that some store saw, so it overstates the rate for events that no store saw. P is sound if every record refers to an event that occurred, that is, if no store invents records and the linking is right. A is sound only if every observer holds every event inside its coverage, a detection rate of 1; the rates of Table 7 show that this does not hold, which is why the measured rate should be reported with every absence claim.
4 Method
4.1 Units, event types and stores
The frame is the Lab’s research corpus: 14 Android full file system extractions, 7 Android bug reports and 33 iOS full file system extractions, each counted as one unit. The 33 iOS and 14 Android extractions are distinct handsets (the frame of LAB-TR-0029 [5]); the seven bug reports carry six distinct serial hashes and a seventh, without a serial, from another manufacturer; whether a bug report comes from the same phone as an extraction was not tested. Of the Android extractions, 12 are Samsung phones; 9 run Android 16 and 5 Android 10 to 14. Of the iOS extractions, 20 run iOS 26, 12 run iOS 15 to 18 and one has no recorded release. Table 2 lists the seven event types and their stores by evidence class, chosen because at least two stores of the same unit can record the event. Table 4 reports nine combinations of type and class; restarts in bug reports had too few events (5 in all) to report. The meaning of the Android stores follows the platform sources [22, 23, 24, 25]: the device-startup event of the usage store means that the runtime started, the dropbox boot entry is written once per runtime start, usage files are pruned after ten days and dropbox entries after three days by default, and a first install time has more than one carrier. Install and update events cover non-system packages only; packages whose first install lies within two days of the day that holds at least 30 percent of all first-install times (the image-build day) are left out, and a package counts as updated when its last-update time exceeds its first-install time by more than 300 seconds. Three stores are not available everywhere: the vendor battery log on 8 of 14 Android extractions, the messaging application on 11, and the interaction, call-history and message databases on 31 of 33 iOS extractions. A store that is empty for a type whose capability is not documented (messages, calls, installs) is taken as not recording that type in that unit and does not take part; stores of documented types (restarts, screen on) take part when empty.
| Event type | Class | Stores (writer, family) | Tolerance |
|---|---|---|---|
| Restart | Android extraction | usage statistics, device-startup events (usage service, SVC); dropbox, boot entries (dropbox, LOG); bootstat, last-boot time (bootstat, SVC; latest restart only) | 300 s |
| Restart | Bug report | usage statistics dump; event log, boot-progress start (power service, LOG) | 300 s |
| Screen on | Android extraction | usage statistics, interactive events; vendor battery-history log, screen-on flag (battery service, LOG; 8 phones) | 2 s |
| Screen on | Bug report | usage statistics dump; event log, screen toggle; system log, wake-up lines (event log and system log share the power service as writer) | 2 s |
| Connected call | Android extraction | call-log provider, rows with duration above zero, as intervals (APPDB); vendor battery-history log, in-call flag as intervals (LOG) | 30 s gap |
| Call | iOS extraction | call-history database (APPDB); interaction store, call interactions (SVC) | 30 s |
| Text message | Android extraction | telephony provider, SMS and MMS rows (APPDB); messaging application database, SMS and MMS rows (APPDB; 11 phones) | 60 s |
| Text message | iOS extraction | message database (APPDB); interaction store, message interactions (SVC) | 60 s |
| App first install | Android extraction | package list, first-install attribute (package manager, SVC; where present); package restrictions, first-install time (package manager, SVC); APK file time, for packages never updated (file system, FSMETA) | 300 s, same package |
| App last update | Android extraction | package list, last-update time (SVC); APK file time, for updated packages (FSMETA) | 300 s, same package |
4.2 Linking rule
Records of one event type are sorted by start time and clustered in one pass. A record joins the open cluster with the same key whose time gap to it is smallest and at most the tolerance, provided the cluster has no record of the same store; otherwise it opens a cluster. Intervals (calls) are compared by the gap between intervals. The clusters are the events. The tolerances were fixed before any witness count was computed, at the values of Table 2, and varied from a tenth to ten times for sensitivity. Timestamp differences are measured at ten times the tolerance so that the tolerance does not truncate them. Times in a local zone (the vendor log; the event and system logs of bug reports) are converted with the zone recorded in the unit itself (a persistent property, or the offset between two renderings of one instant in the report), never from the events being compared. A link is ambiguous when the record had more than one candidate cluster.
4.3 Measures
For each event we take the witness set and the set of covering stores, those whose coverage contains the event time (and whose scope contains its key, for file times of packages that exist as APK files). We report: the share of events with one, two or more witnesses, pooled and as a median over units with at least 5 events; the share whose witnesses all lie in one family; the time difference of linked records; the detection rate of each store; and, for events with one witness, the outcome after its loss: unobservable if no other store covers the time, absent if another does, and absent at θ for a covering store whose detection rate in the class is at least θ (0.5 and 0.9). Day findings use whole UTC days inside the coverage of at least one store and the verdicts of Section 3.2. Shares are given as pooled values, which are dominated by the units with most events, and as unit medians. Groups with fewer than 3 units are not reported.
4.4 Validation on synthetic phones
A generator draws events from a Poisson process, lets each store capture an event with its own probability, adds Laplace noise to the stored time, and keeps the truth. We vary events per day (10 to 5,000), noise scale (0.1 to 60 s) and tolerance (1 to 300 s), and compare the linking and the single-witness share with the truth (Section 5.1). Separately, 3,000 random units with 2 to 5 stores, random coverage, families and writers are used to test Propositions 1 to 4 and the exact transitions of Proposition 2 by comparing the rules with a direct recomputation.
4.5 What was left out
Notification events of bug reports (usage-store interruptions against event-log enqueues) were extracted and not analysed: the usage events are a subset of the enqueues, and 49 percent of links at 5 seconds were ambiguous. The shadow copy of the call log was empty on every phone. The bootstat store holds only the latest restart. Removal events (app removed, record deleted) have no store of their own on these phones and are not analysed.
5 Results
5.1 The rule on synthetic phones, and the propositions
Table 3 and Figure 2 show the linking rule on phones whose events are known. When the tolerance is at least five times the noise scale and the expected number of other records within the tolerance (2λτ over a day, with λ events a day and tolerance τ) is below 0.15, precision and recall are at least 0.95 and 0.94 and the estimated single-witness share is within 0.03 of the true share. With a tolerance below the noise scale the share is over-estimated by up to 0.58, because true pairs are split; at 1,000 events a day and 300 seconds it is under-estimated by 0.10, because unrelated records are joined. A tolerance should therefore be a few times the noise and small against the mean gap between events. In the corpus, the base tolerances sit above most observed differences (Table 5), and between the base tolerance and ten times it the pooled one-witness share of any type changes by at most 3.5 points (Restart, Android); at a tenth of the tolerance it changes by up to 37.1 points (Call, iOS) (Table 9).
| Events a day | Jitter (s) | Tolerance (s) | Precision | Recall | True one-witness % | Estimated % |
|---|---|---|---|---|---|---|
| 100 | 1 | 5 | 1.00 | 0.98 | 46 | 47 |
| 100 | 1 | 30 | 0.99 | 0.99 | 42 | 42 |
| 100 | 1 | 60 | 0.98 | 0.98 | 45 | 45 |
| 100 | 1 | 300 | 0.89 | 0.92 | 45 | 43 |
| 100 | 10 | 5 | 0.93 | 0.23 | 44 | 90 |
| 100 | 10 | 30 | 0.96 | 0.86 | 44 | 53 |
| 100 | 10 | 60 | 0.96 | 0.95 | 44 | 44 |
| 100 | 10 | 300 | 0.89 | 0.91 | 45 | 43 |
| 1,000 | 1 | 5 | 0.96 | 0.95 | 44 | 46 |
| 1,000 | 1 | 30 | 0.89 | 0.91 | 44 | 42 |
| 1,000 | 1 | 60 | 0.82 | 0.85 | 43 | 40 |
| 1,000 | 1 | 300 | 0.54 | 0.60 | 44 | 34 |
| 1,000 | 10 | 5 | 0.72 | 0.23 | 44 | 87 |
| 1,000 | 10 | 30 | 0.73 | 0.69 | 44 | 49 |
| 1,000 | 10 | 60 | 0.68 | 0.71 | 44 | 40 |
| 1,000 | 10 | 300 | 0.46 | 0.51 | 44 | 34 |
The property tests found no violation. On 3,000 random units, 599,004 checks of Proposition 1 over pairs of store sets found no existence finding that stopped being present when stores were added; the same checks found 32,948 absence verdicts that became present and 16,161 unobservable verdicts that became present on adding a store, the non-monotone behaviour of Proposition 2(c). Of 72,076 day verdicts after the loss of one store, the exact transitions of Proposition 2 held in all (2,494 present-to-absent and 964 present-to-unobservable occurred), the writer resilience never exceeded the store resilience in 11,861 cases, and the minimum rule of Proposition 4 held in 2,421 brute-force checks.
5.2 How many stores witness an event
Table 4 and Figure 3 give the witness counts. A single witness is the norm for text messages on iOS (median unit 88 percent, range 6 to 100), screen-on events on Android extractions (92 percent) and bug reports (98), connected calls on Android (94) and app first installs (89). It is the minority for app last updates (30 percent), where the package list and the APK file time both record the event. iOS calls (43 percent) and Android text messages (59 percent) lie between. Restarts were witnessed by one store in 57 percent of 53 events pooled over 14 extractions; only 3 units had 5 or more, so no per-unit claim is made. The pooled shares differ from the unit medians where a few large units dominate the events: Android screen-on (66 percent pooled, 92 in the median unit; the two largest units hold 51 percent of the events), iOS calls (53 and 43) and iOS messages (94 and 88; the largest unit holds 42 percent of the events). One unit holds 57 percent of the Android text-message events. For iOS messages the interaction store covers only recent months: 90 percent of iOS message events lie in a window that only the message database covers (see Table 6).
| Event type | Class | Units | Events | One witness % | Two % | Three or more % | Per unit: one witness % | One family % |
|---|---|---|---|---|---|---|---|---|
| Restart | Android | 14 | 53 | 57 | 34 | 9 | 67 (50–78), n=3 | 60 |
| Screen on | Android | 8 | 5,549 | 66 | 34 | 0 | 92 (34–100), n=8 | 66 |
| Screen on | Bug report | 7 | 873 | 96 | 1 | 3 | 98 (70–100), n=7 | 96 |
| Connected call | Android | 7 | 5,386 | 95 | 5 | 0 | 94 (22–99), n=7 | 95 |
| Call | iOS | 28 | 46,797 | 53 | 47 | 0 | 43 (5–86), n=28 | 53 |
| Text message | Android | 10 | 337,129 | 56 | 44 | 0 | 59 (12–93), n=10 | 100 |
| Text message | iOS | 22 | 1,523,309 | 94 | 6 | 0 | 88 (6–100), n=22 | 94 |
| App first install | Android | 14 | 1,563 | 88 | 12 | 0 | 89 (77–99), n=14 | 88 |
| App last update | Android | 14 | 848 | 30 | 70 | 0 | 30 (25–64), n=14 | 30 |
Two writers matter. In bug reports the event log and the system log both record screen wake-ups from the same power service; of the 39 screen-on events with two or more stores, 26 were held by three stores but only two writers. On Android, the telephony provider and the messaging application are both application or provider databases, so every message witnessed by both belongs to one family; the loss of that family would leave none of the 147,448 doubly witnessed messages, which is what the last column of Table 4 records.
5.3 How well the stores agree
Where records were linked, the times agree closely (Table 5). Messages linked with a median difference of zero on both platforms; screen-on events differed by 0.62 seconds in the median between the vendor log and the usage store and by milliseconds between the event log, the system log and the usage dump; connected calls by 0.23 seconds; app installs by 1.6 seconds between the package restrictions and the APK file time; iOS calls by 6.9 seconds between the call-history and interaction databases. Restarts differ more: 18 seconds between the dropbox entry and the usage event, 180 between bootstat and the usage event and 364 between dropbox and bootstat. The platform sources give a reason: the dropbox entry is written when the boot-completed broadcast is received, and the usage event records the start of the runtime [22, 23]. The differences are small beside the tolerances for every type except restarts, so for most types a disagreement of times is not what limits the witness count; scope is. The exceptions are iOS calls and Android screen-on events, whose single-witness share moves with the tolerance (Section 5.6).
5.4 What losing the only witness leaves
Table 6 and Figure 4 give the outcome for events with one witness. For most types most single-witness events lie where no other store covers the time, so their loss gives an unobservable finding, not an absent one: 96 percent of single-witness iOS messages and 95 percent of single-witness Android connected calls. The exposure to a false absence is where another store covers the time: 36 percent of single-witness iOS calls, 29 percent of Android screen-on events and all but 14 of the 189,681 single-witness Android text messages. Whether a reader would find absence depends on how well the covering store records such events (Table 7): the interaction store holds 75 percent of the calls that the call-history database also holds, and the call-history database 94 percent of those the interaction store holds. For Android text messages the messaging application holds 45 percent of the messages that the telephony provider holds, so a reader with only the application finds absence for messages that the provider has; the provider holds 95 percent of the application’s. We did not determine whether the application was the user’s text-message application on these phones, so for this type the single witnesses may reflect a difference in scope more than a lost record. For connected calls the call log holds 54 percent of the intervals that the vendor battery log marks as calls; why is not determined by these data, and a difference in what each store counts as a call is one possible reason. When only stores with a detection rate of 0.9 or more count as observers, the exposure falls to 6 percent for iOS calls, 5 percent for Android screen-on and 0.1 percent for iOS messages.
| Event, class | Store pair (second minus first) | Linked pairs | Median |diff| | 95th percentile | Within 1 s % | Within tolerance % |
|---|---|---|---|---|---|---|
| Restart, Android | usage − bootstat | 11 | 180 | 1435 | 0 | 55 |
| Restart, Android | usage − dropbox | 20 | 18 | 49 | 0 | 100 |
| Restart, Android | bootstat − dropbox | 10 | 364 | 1526 | 0 | 50 |
| Screen on, Android | usage − battery log | 2,037 | 0.62 | 3.85 | 66 | 93 |
| Screen on, Bug report | power log − usage | 36 | 0.01 | 0.21 | 97 | 97 |
| Screen on, Bug report | usage − event log | 29 | 0.00 | 0.02 | 100 | 100 |
| Screen on, Bug report | power log − event log | 26 | 0.00 | 0.08 | 100 | 100 |
| Connected call, Android | battery log − call log | 258 | 0.23 | 76 | 81 | 91 |
| Call, iOS | interaction − call history | 23,241 | 6.89 | 31 | 10 | 93 |
| Text message, Android | telephony − messaging app | 147,908 | 0.00 | 28 | 92 | 97 |
| Text message, iOS | message db − interaction | 92,701 | 0.00 | 25 | 89 | 97 |
| App first install, Android | package list − APK file time | 13 | 1.60 | 14 | 38 | 100 |
| App first install, Android | package restrictions − APK file time | 182 | 1.64 | 24 | 34 | 100 |
| App last update, Android | package list − APK file time | 597 | 5.99 | 94 | 3 | 99 |
| Event, class | Single-witness events | Unobservable % | Another store covers % | Detection ≥ 0.5 % | Detection ≥ 0.9 % |
|---|---|---|---|---|---|
| Call, iOS | 24,582 | 64 | 36 | 36 | 6 |
| Text message, iOS | 1,430,654 | 96 | 4 | 4 | 0 |
| Text message, Android | 189,681 | 0 | 100 | 4 | 4 |
| Screen on, Android | 3,649 | 71 | 29 | 29 | 5 |
| Screen on, Bug report | 834 | 99 | 1 | 1 | 0 |
| Connected call, Android | 5,137 | 95 | 5 | 5 | 0 |
| App first install, Android | 1,368 | 63 | 38 | 0 | 0 |
| App last update, Android | 257 | 89 | 11 | 11 | 11 |
| Restart, Android | 30 | 67 | 33 | 33 | 0 |
| Event, class | Detection rate by store |
|---|---|
| Call, iOS | call history 94% (n=23,652); interaction 75% (n=29,636) |
| Text message, iOS | interaction 60% (n=155,468); message db 99% (n=93,776) |
| Text message, Android | messaging app 45% (n=329,615); telephony 95% (n=154,948) |
| Screen on, Android | battery log 91% (n=2,098); usage 69% (n=2,770) |
| Screen on, Bug report | event log 73% (n=40); usage 100% (n=39); power log 100% (n=36) |
| Connected call, Android | call log 54% (n=465); battery log 94% (n=266) |
| Restart, Android | dropbox 72% (n=29); bootstat 47% (n=17); usage 73% (n=30) |
| App last update, Android | APK file time 98% (n=605); package list 98% (n=605) |
| App first install, Android | APK file time 28% (n=705); package list 100% (n=13); package restrictions 98% (n=185) |
5.5 Day findings
Table 8 repeats the analysis for the finding “an event of this type occurred on this day”. Of 6,116 iOS days with a call, 3,585 rest on one store; losing it leaves 429 days that read as absent and 3,156 that are unobservable. For iOS messages the figures are 26,962, 24,661, 774 and 23,887; for Android text messages 8,320 days, 834 resting on one store, all of which read as absent because the other store covers them. Of 20 Android days with a restart, 13 rested on one store and all became unobservable. The converse also holds: absence is rarely observed twice. Of the days with no record, 79 percent (iOS calls), 91 percent (iOS messages) and 97 percent (Android screen-on) were observed by one store only, so the loss of that store makes the absence unobservable (Proposition 2(d)).
| Event, class | Units | Days present | Present, one store | Lost: reads absent | Lost: unobservable | Absent days, one observer |
|---|---|---|---|---|---|---|
| Restart, Android | 14 | 20 | 13 | 0 | 13 | 645 |
| Screen on, Android | 8 | 182 | 138 | 5 | 133 | 307 |
| Connected call, Android | 7 | 1,661 | 1,596 | 7 | 1,589 | 4,814 |
| Call, iOS | 28 | 6,116 | 3,585 | 429 | 3,156 | 9,530 |
| Text message, Android | 10 | 8,320 | 834 | 834 | 0 | 0 |
| Text message, iOS | 22 | 26,962 | 24,661 | 774 | 23,887 | 13,188 |
5.6 Sensitivity
Table 9 shows the pooled one-witness share at five tolerances. Where records are exact or the base tolerance exceeds the noise, the shares barely move (messages, installs, updates). They move where timestamps differ by seconds (iOS calls fall from 90 percent at a tenth of the tolerance to 49 at ten times; Android screen-on from 94 to 62). The two types with the highest pooled share and the one with the lowest are the same at all five tolerances; the order of the others changes. Ambiguous links are at most 3.6 percent of links at the base tolerance (restarts and text messages highest) and rise to 8.5 percent at ten times it.
| Event, class | ×0.1 | ×0.5 | ×1 | ×2 | ×10 | Ambiguous links, ×1 | ×10 |
|---|---|---|---|---|---|---|---|
| Restart, Android | 70 | 57 | 57 | 55 | 53 | 3.6 | 3.1 |
| Screen on, Android | 94 | 78 | 66 | 65 | 62 | 0.2 | 0.7 |
| Screen on, Bug report | 96 | 96 | 96 | 96 | 96 | 0.0 | 0.0 |
| Connected call, Android | 95 | 95 | 95 | 95 | 95 | 0.0 | 4.7 |
| Call, iOS | 90 | 67 | 53 | 49 | 49 | 0.4 | 1.9 |
| Text message, Android | 56 | 56 | 56 | 56 | 56 | 3.3 | 8.5 |
| Text message, iOS | 94 | 94 | 94 | 94 | 94 | 2.3 | 6.0 |
| App first install, Android | 88 | 88 | 88 | 88 | 88 | 0.0 | 0.0 |
| App last update, Android | 45 | 32 | 30 | 29 | 29 | 0.0 | 0.0 |
6 Discussion
What a finding should carry. A finding that states a time or a date should state its witness set, whether those stores share a writer or family, and for each absence claim the observers and their detection rate. “The phone was not restarted on 12 October” should read “no restart was recorded in the usage store, which covers the day and holds about three quarters of the restarts that another store also holds” (the detection rate of the usage store for restarts was 73 percent), and, if the usage store is missing, “not observable”. A reader whose acquisition class omits a store should write unobservable for the days only that store covered, not absent.
Why counting stores is not enough. Three reasons appear in the data. Stores share writers (Proposition 3), so two stores can be one witness. Stores differ in scope: a store that is a superset of another makes the narrower one a poor observer, as the interaction store is for messages. And retention: the witness count of an event is bounded by the number of stores whose retention reaches its date, which is why most iOS messages have one witness although two stores exist (Table 6). This links the report to retention horizons [3]: a horizon says where a store stops; the witness set says what stands behind a finding inside it.
Narratives. Proposition 4 makes long narratives fragile. A narrative built from many events inherits the resilience of its weakest event. Where a single-witness share is high, a timeline of tens of events almost certainly contains a finding that one lost store would remove, and the lost store may leave absence behind it, not a gap.
What is new, what is replication, what is engineering. The definitions, the propositions with their transitions and the measurement of witness counts, agreement and exposure are new as far as our search shows. The use of resilience and witness is borrowed from database theory, the reasoning about a probability of detection from earlier work on absence [7], and the timestamp findings agree in kind with work on time domains [11, 16]. The extractors for the stores are engineering.
7 Threats to Validity and Limitations
Construct. An event is a cluster of linked records; two stores may call different occurrences by the same type (a connected call and an in-call flag; a message and a message interaction). A single witness may therefore mean a different scope, not a lost record, and we do not separate the two; the report counts what a reader would have. Coverage is taken from each store’s own span of records, which assumes that a store keeps everything inside that span; a store that drops records inside it inflates the apparent gap. The detection rate is estimated from events some store saw. Install and update events exist only for packages still installed, because removed packages leave no row in these stores, a survivorship effect.
Internal. The tolerances and the coverage rule were fixed before any witness count and were not changed afterwards; they were not tuned on independent phones, and sensitivity is reported (Table 9). Three rules were added after the first counts and belong to the reported method: stores with no record of a message, call or install type do not take part in that type; the messaging application’s rows are limited to SMS and MMS, because its chat rows have no counterpart in the telephony provider; and observers are weighted by their detection rate (Section 3.4). Linking is greedy, and ambiguity is measured, not removed; a second, separately written greedy matching of two stores gave the same event counts to within 0.1 percent for messages and screen-on events and a 2.5 percent lower number of linked pairs for iOS calls. The parsers read file layouts that change with releases; the usage store has two layouts in these units. Local-time stores depend on the recorded time zone. The parsers were not checked against a second implementation; synthetic tests cover the linking and the propositions, not the parsers.
External. There are 54 units from one corpus; 12 of 14 Android extractions are Samsung phones, so Android results are Samsung results; the bug-report units are 4 Samsung phones and 3 others, and groups under 3 are not reported by device class. Some types rest on few units (restarts on 3 with 5 or more events; connected calls on 7 phones with the vendor log). We did not establish whether a bug report and an extraction of the corpus come from one phone, so leave-one-class-out is measured by store family, not by acquisition class, and the loss of an acquisition class is simulated only in the sense that a reader holds fewer stores. Pooled shares are dominated by a few large units; the medians are the safer figure.
Limitations. We did not estimate the number of events that no store saw, which capture-recapture methods could bound; we did not measure removal events; we did not test whether records of other stores of the same phone would add witnesses; and the novelty search could not reach several publisher and conference pages, nor the full text of Casey (2020), so it may have missed work.
8 Conclusion
Existence findings about a phone can only gain support from more stores, and absence findings can lose it. That asymmetry is exact, and it matters because a single witness is common: in the median unit 88 percent of iOS message events and 92 percent of Android screen-on events had one witness, and where a second store covered the time it often recorded only part of what the first did. We propose that every dated finding state its witness set, the shared writers, and the observers and detection rates behind any absence, and we release the code and synthetic phones that reproduce the method. What remains open is the number of events that no store saw, the effect of removal events, and a comparison on phones acquired in more than one class.
Artifact Availability
The analysis code (linking rule, coverage and verdict functions, aggregation), the synthetic-phone generator, the synthetic evaluation including the property tests, the extractor for the stores of Table 2, a README that reproduces every synthetic result, and the synthetic results will be released in the Lab's public artifacts repository, with no release date set. The package is not public yet, and the sentences that follow describe it as planned. Code is licensed MIT, data and text CC BY 4.0. The synthetic results (Table 3, Figure 2 and Section 5.1, and Figure 1) are to be reproducible from the files to be released; Tables 4 to 9 and Figures 3 and 4 depend on the research corpus, which cannot be released, and the extractor and analysis to be released run on any set of extractions or bug reports a reader holds. The extractor takes the evidence location only as a command-line argument. The analysis is tied to the formats of the releases it was tested on.
Data Handling Statement
The evidence for this study is drawn from the Lab’s research corpus of mobile device extractions and bug reports and was read only, together with synthetic data, namely the synthetic phones of Sections 1, 5.1 and Figure 1, whose events are invented. From the corpus, the extractor read the times of records of the stores of Table 2, the span of those stores, call durations, the interaction type and messaging protocol fields, the recorded time zone and package names; package names were used in memory to link records and kept only as salted hashes. No message text, number or name was read into a result. The report gives aggregate counts and device classes. It contains no identifiers, personal data, message or file content, or case information. Figures 3 and 4 show one anonymous value per unit or pooled values, not linked to a device, model or vendor.
Declaration of AI Assistance
The authors conceived the research questions and directed the work. The extraction and analysis code, the data checks and the first draft of this report were produced with AI assistance (Anthropic Claude). The authors reviewed the results and the text and are responsible for the content.
References
- Daniel Addai. 2026. Where Android Records Who Used What: App Ops History in Databases, XML Files and Bug Reports. Lab Technical Report LAB-TR-0003. SectraTEK Lab. https://doi.org/10.5281/zenodo.23717924 (DOI resolves; record page not readable by us.)
- Daniel Addai, Selorm Adjabeng, Kingsley Albert Egyir, and Sanders Larweh Tetteh. 2026. Not Found Is Not Off: Evidence-State Accounting for Reconstructing Phone Security Settings from Full File Systems and Android Bug Reports. Lab Technical Report LAB-TR-0019, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0019/
- Daniel Addai, Sanders Larweh Tetteh, Selorm Adjabeng, and Kingsley Albert Egyir. 2026. Retention Horizons of Volatile Stores in iOS and Android Extractions. Lab Technical Report LAB-TR-0021, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0021/
- Daniel Addai, Selorm Adjabeng, Kingsley Albert Egyir, and Sanders Larweh Tetteh. 2026. Device-Life Boundary Indicators and the Classification of Restored Versus Native Records on Android. Lab Technical Report LAB-TR-0028, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0028/
- Daniel Addai, Kingsley Albert Egyir, Sanders Larweh Tetteh, and Selorm Adjabeng. 2026. Measuring the Answerability of Date-Bound Questions from Mobile Device Extractions. Lab Technical Report LAB-TR-0029, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0029/
- Algirdas Avižienis. 1985. The N-version approach to fault-tolerant software. IEEE Transactions on Software Engineering SE-11, 12 (1985), 1491–1501. https://doi.org/10.1109/TSE.1985.231893 (Crossref record checked; full text not read.)
- Alex Biedermann and Joëlle Vuille. 2016. Digital evidence, “absence” of data and ambiguous patterns of reasoning. Digital Investigation 16 (Supplement), DFRWS EU 2016, S86–S95. https://doi.org/10.1016/j.diin.2016.01.011
- Frank Breitinger, Hudan Studiawan, and Chris Hargreaves. 2025. SoK: Timeline based event reconstruction for digital forensics: Terminology, methodology, and current challenges. arXiv:2504.18131. https://arxiv.org/abs/2504.18131
- Peter Buneman, Sanjeev Khanna, and Wang-Chiew Tan. 2001. Why and where: A characterization of data provenance. In Database Theory, ICDT 2001, LNCS 1973, 316–330. https://doi.org/10.1007/3-540-44503-X_20 (Crossref record checked; full text not read.)
- Eoghan Casey. 2020. Standardization of forming and expressing preliminary evaluative opinions on digital evidence. Forensic Science International: Digital Investigation 32, 200888. https://doi.org/10.1016/j.fsidi.2019.200888 (Bibliographic record and abstract read; full text not accessible to us.)
- Lisa Marie Dreier, Céline Vanini, Christopher J. Hargreaves, Frank Breitinger, and Felix Freiling. 2024. Beyond timestamps: Integrating implicit timing information into digital forensic timelines. Forensic Science International: Digital Investigation 49 (Supplement), 301755. https://doi.org/10.1016/j.fsidi.2024.301755
- Ivan P. Fellegi and Alan B. Sunter. 1969. A theory for record linkage. Journal of the American Statistical Association 64, 328 (1969), 1183–1210. https://doi.org/10.1080/01621459.1969.10501049 (Crossref record checked; full text not read.)
- Cibele Freire, Wolfgang Gatterbauer, Neil Immerman, and Alexandra Meliou. 2015. The complexity of resilience and responsibility for self-join-free conjunctive queries. Proceedings of the VLDB Endowment 9, 3 (2015), 180–191. arXiv:1507.00674. https://arxiv.org/abs/1507.00674
- Graeme Horsman and David Errickson. 2019. When finding nothing may be evidence of something: Anti-forensics and digital tool marks. Science & Justice 59, 5 (2019), 565–572. https://doi.org/10.1016/j.scijus.2019.06.004 (Bibliographic record only; not re-verified.)
- Lorenz Hornung, Carly Bakker, Bouke Timbermont, Roel van Dijk, Harm van Beek, and Natasha Alechina. 2026. A formal model for forensically sound timestamp normalization. In 33rd International Symposium on Temporal Representation and Reasoning (TIME 2026), OASIcs 146, 10:1–10:21. https://doi.org/10.4230/OASIcs.TIME.2026.10
- Jihye Jang, Eunji Lee, Yeon Baek, Jungho Kim, Sungjin Lee, and Gibum Kim. 2026. Time-anchor: Detecting system clock manipulation in android. Forensic Science International: Digital Investigation 58, 302191. https://doi.org/10.1016/j.fsidi.2026.302191 (Abstract and bibliographic record read; full text not read.)
- Michael Kwan, Richard Overill, Kam-Pui Chow, Hayson Tse, Frank Law, and Pierre Lai. 2011. Sensitivity analysis of Bayesian networks used in forensic investigations. In Advances in Digital Forensics VII, IFIP AICT 361, 231–243. https://doi.org/10.1007/978-3-642-24212-0_18 (Crossref record checked; full text not read.)
- Alexandra Meliou, Wolfgang Gatterbauer, Katherine F. Moore, and Dan Suciu. 2010. The complexity of causality and responsibility for query answers and non-answers. Proceedings of the VLDB Endowment 4, 1 (2010), 34–45. arXiv:0912.5340. https://arxiv.org/abs/0912.5340
- Heloise Pieterse and Martin Olivier. 2014. Smartphones as distributed witnesses for digital forensics. In Advances in Digital Forensics X, IFIP AICT 433, 237–251. https://doi.org/10.1007/978-3-662-44952-3_16 (Bibliographic record and abstract only; not re-verified.)
- Hyunwoo Shin and Jungheum Park. 2026. CAFE: A claim-level cross-artifact verification framework for assessing the reliability of Windows forensic evidence under anti-forensic manipulation. DFRWS APAC 2026. DFRWS programme page (Abstract read; full text not read.)
- Céline Vanini, Christopher J. Hargreaves, Harm van Beek, and Frank Breitinger. 2024. Was the clock correct? Exploring timestamp interpretation through time anchors for digital forensic event reconstruction. Forensic Science International: Digital Investigation 49 (Supplement), 301759. https://doi.org/10.1016/j.fsidi.2024.301759
- Android Developers. UsageEvents.Event. API reference. https://developer.android.com/reference/android/app/usage/UsageEvents.Event. Read October 29, 2026.
- Android Open Source Project. BootReceiver.java and DropBoxManagerService.java, platform/frameworks/base, main branch. BootReceiver.java; DropBoxManagerService.java. Read October 29, 2026.
- Android Open Source Project. UsageStatsDatabase.java, platform/frameworks/base, main branch. https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/services/usage/java/com/android/server/usage/UsageStatsDatabase.java. Read October 29, 2026.
- Android Open Source Project. Settings.java (package manager), platform/frameworks/base, main branch. https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/services/core/java/com/android/server/pm/Settings.java. Read October 29, 2026.