Lab Technical Report LAB-TR-0035

Where Removed Apps Leave Traces: A Per-Store Measurement on Android and iOS Phones

Daniel Addai

SectraTEK Lab, Prudential Associates

Corresponding author

Kingsley Albert Egyir

Sanders Larweh Tetteh

Selorm Adjabeng

Lab Technical Report, preprint, not peer reviewed

29 October 2026

Abstract

An examiner who asks whether an app was ever on a phone usually asks one store. Practitioner posts say which stores keep a trace after an uninstall; we found no measurement of how often they do. We read 13 stores of 14 Android full file system extractions, 7 Android bug reports and the app-related stores of 32 iOS extractions, and counted names of packages that a store holds but the phone no longer lists as installed (“ghosts”). The stores the operating system manages kept almost nothing. Of 770 Android ghosts, 700 sat in the app store’s local state; of 416 third-party ghosts, 409 did. 98 percent of the 770 were held by exactly one store, so stores seldom corroborate one another. A capture-recapture estimate of the removed apps that no store holds is not identified: two standard estimators give 1.9 and 16 times the ghosts seen, and a simulation shows how each fails. On iOS devices, 11 of 118 logged uninstalls (9 percent) left a name in any store we read. In these stores, a missing trace in one store is weak evidence that an app was never installed.

CCS Concepts • Applied computing → System forensics; • Security and privacy → Mobile platform security.

Keywords removed apps, uninstall residue, Android, iOS, usage statistics, capture-recapture, mobile forensics, empirical study

ACM Reference FormatDaniel Addai, Kingsley Albert Egyir, Sanders Larweh Tetteh, and Selorm Adjabeng. 2026. Where Removed Apps Leave Traces: A Per-Store Measurement on Android and iOS Phones. Lab Technical Report LAB-TR-0035, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0035/

1 Introduction

Whether an app was ever on a phone matters to many inquiries, and the app is often gone by the time the phone is examined. Practitioners look for what an uninstall leaves behind in usage statistics, permission records, notification settings and storage folders [1], [2], [3], and a security study has shown that Android’s clean-up at uninstall is incomplete [4]. What is missing is a count: how often each store keeps a trace of a removed app on phones nobody selected for the question, and whether the stores agree with one another. Without it, an examiner who finds nothing in one store cannot say how much that nothing is worth.

A motivating example. The following case is synthetic. A phone lists 500 installed apps and none called X. The examiner opens the usage statistics: no record of X. The app-store state of the same phone lists X with a first-download date four months before the extraction. A third store, the notification policy, has an entry for X, but notification policy can also hold entries that the operating system created from defaults. Each store gives a different answer to “was X here?”; which answer counts depends on what each store keeps after an uninstall and on how often it is the only one that does.

The problem. An examiner needs to know, per store, how often it still names a removed app, how often a second store would confirm it, and how many removed apps no store names at all. We ask four questions.

  • RQ1 (Prevalence). In which stores of Android and iOS phones does a package that is not installed still appear, and on what share of phones?
  • RQ2 (Agreement). Do stores corroborate one another, and how much does an examiner who reads one store miss?
  • RQ3 (Unseen). Can the number of removed apps that no store names be estimated by capture-recapture, and when does the estimate fail?
  • RQ4 (Age and short-lived installs). How old are the traces, and what share of recent installs is already gone?

Table 1 gives the answers.

Table 1: Research questions, answers and evidence. All values describe this sample.
RQAnswerEvidence
RQ1 PrevalenceThe system-managed stores kept almost nothing: runtime-permission grants, graphics statistics, media-store package fields and crash reports held no ghost on any phone. Ghosts were in the app-store state (14 of 14 phones had them), notification policy (12), package restrictions (11) and shared-storage folders (9). Third-party ghosts were almost all (409 of 416) in the app-store state. On iOS devices, ghosts were rare (median 1 per phone).Sections 4.1 to 4.3; Tables 3 to 5; Figure 1
RQ2 Agreement98 percent of the Android ghosts were held by exactly one presence store (754 of 770). Reading the app-store state alone finds 91 percent of them; any other single store finds at most 5.5 percent (42 of 770, shared-storage folders).Section 4.4; Table 6; Figure 2
RQ3 UnseenNot identified. Observed 770 ghosts; jackknife 1,452; Chao2 12,236. In synthetic scenarios the two estimators come close to the truth only when stores are independent and apps are equally easy to catch; with stores that see different sub-populations, Chao2 overshoots by a factor of 3 to 13 and the jackknife undershoots. The data cannot tell which scenario holds.Section 4.6; Tables 7 and 8; Figure 3
RQ4 Age and recencyTraces are old: median 443.1 days since first download. Of apps first downloaded within 30 days of the latest time evidence, 17.7 percent were already gone (31 of 175); within 90 days, 22.4 percent. No store pairs an install time with a removal time, so a minutes-or-hours rate cannot be measured.Section 4.7; Table 9; Figure 4

Contributions. This report makes four contributions. (1) A per-store map of what remains of removed apps, measured on 14 Android extractions, 7 Android bug reports and 32 iOS extractions (Section 4.1 to 4.3). (2) A measure of agreement between stores and of what a one-store reading misses (Section 4.4 and 4.5). (3) A test of capture-recapture estimation for apps that no store names, with a simulation that shows when it fails (Section 4.6). (4) A recency-based measure of how many recent installs are already gone, and the synthetic generator and analysis code to repeat the estimator study (Section 4.7 and Artifact Availability).

2 Background and related work

2.1 What an uninstall is meant to remove

Android removes an app’s private storage and its app-specific external storage on uninstall [5]. The usage-statistics service is documented in source form to filter and then prune the records of packages that were removed, and to rewrite its files dropping data for packages that can no longer be named [6]. Other services keep their own tables, and what they do at uninstall differs by service and release. iOS removes the app bundle and its data container; the installation log records the uninstall [7].

2.2 Residue after an uninstall

Zhang et al. audited Android’s clean-up and found 12 residue instances that an attacker can exploit [4]. Forensic work asks the reverse question: what remains as evidence. CleanerScope followed nine wiping apps through four phases on a phone and reports usage statistics as the most durable source [8]; Oh et al. evaluated six file-wiping apps [9]; a systematic review of Android anti-forensics notes that incomplete reporting of versions and models limits reproducibility [10], and a survey of residual mobile evidence finds cross-platform validation rare [11]. Jones et al. infer from disk sectors that a desktop application was once installed [12]. These studies use chosen apps in controlled settings or desktop disks. We found none that counts, per store and on unselected phones, how often a removed app is still named.

Practitioner sources make claims we can test. One says residual traces of an uninstalled app often remain in the monthly usage-statistics files [1]; another names a device-event database that may keep records of deleted apps [2]; a third says knowledge and Biome stores keep records of deleted apps for 28 to 30 days [3].

2.3 Estimating what no source shows

Estimating items that no list contains is old in ecology. It has been used for software defects found by inspections [13] and for software fault content before coding [14]. Chao’s estimator uses the numbers of items seen once and twice and is a lower bound under unequal catchability [15]; the jackknife of Burnham and Overton is a second standard [16]. Even under these assumptions the size of a population with heterogeneous detection is not identified, because models that fit the same capture histories imply very different sizes [26]. Work on residual risk in fuzzing finds that ignoring dependence among the observed elements biases an estimate of the unseen [17]; estimates from multiple lists can be unreliable when assumptions fail [18]; and without further assumptions the number seen by no list cannot be point-identified, so partial identification gives confidence sets under bounds on dependence [19]. We found no earlier use of these estimators in mobile forensics.

2.4 Position of this work

This report adds a measurement and a negative result. The measurement is the per-store prevalence of removed-app names on unselected phones, which we did not find elsewhere; the negative result is that these stores do not support an estimate of the apps no store names. It builds on our reports on retention horizons [20] (how far back a store reaches, not what it keeps after removal), on restored versus native records [21] (restores set first-download dates, which Section 4.7 uses), on answerability [22] (an answer of “never installed” depends on the result here), on identifier counters [23] (the clean-up-application question that report could not measure) and on SQLite deleted-row residue [24] (cell content, not names). Market telemetry reports short lifetimes of abandoned apps [25]; it does not come from device evidence.

3 Method

3.1 Definitions

For a device, the installed set is the set of package names (Android) or bundle identifiers (iOS) that the device’s own package registry lists. On Android the registry lists the packages of every user and profile, including a system package removed for one user and kept for others, so a package that any user or profile still has is not a ghost; on iOS it is the set of bundle containers present. A ghost is a name held by some store that is not in the installed set. A trace is a ghost seen in one store. A ghost is a candidate removed app; we do not claim that every ghost was installed (Section 6). We class a ghost by its name space as platform (Android, Google), phone-maker or carrier (a fixed list of prefixes in the released code) or third-party (everything else; this includes preinstalled third-party apps, so the class does not mean user-installed). We call a store a presence store if an entry requires that the package ran or was installed (usage statistics, app-ops access records, runtime grants, graphics statistics, code-optimisation list, crash reports, media-store package field, older package-list copies, shared-storage folders, the vendor screen-time database, and app-store state with a recorded first download). We call it a configuration store if an entry can come from defaults or a restore (notification policy, per-user package restrictions, and app-store state with no download recorded). Presence stores enter the estimators; configuration stores are reported separately.

Two more terms are used the same way throughout. A logged uninstall (iOS) is an “Uninstalling identifier” line in the installation log for a non-Apple bundle that is not in the installed set, counted once per bundle and device. A recent download is an app whose recorded first download lies within w days of the phone’s reference time (Section 3.3); it is gone if it is not in the installed set. The share of recent downloads that are gone is the only measure of short-lived installs we can compute: it is the share removed before the reference time, not the share removed within w days of installing, because no store we read gives a removal time.

3.2 Evidence and stores

The Lab’s research corpus held 14 Android full file system extractions (14 phones, by a hash comparison of device identifiers recorded in private notes; on 5 Android releases from 10 to 16), 7 Android bug reports (seven devices, hash evidence in the same notes) and 32 iOS extractions with the stores below (33 devices in the frame; one of the 34 extractions repeats a handset and was dropped, and one holds none of the stores). Table 2 lists the stores. Package names were compared in memory and never written to a report. Whether a bug report and an extraction come from the same phone was not tested.

Table 2: Evidence classes, the stores read, and the installed set used.
ClassStores readInstalled set
Android extractionOlder package-list copies; per-user package restrictions; usage statistics (token-mapped records); app-ops access records; notification policy; runtime-permission grants; code-optimisation usage list; graphics statistics (per-day folders); shared-storage app folders; vendor screen-time database; app-store local state; system crash reports; media-store package fieldPackage registry and package list
Android bug reportUsage-statistics dump; app-ops dump; graphics-statistics dump; battery-statistics dump; package-change list; notification dump; shortcut servicePackage dump and storage package list
iPhone extractionApp state registry; knowledge store (app and notification streams); interaction store; privacy-permission store; data-container metadataBundle-container metadata (and bundles that extend an installed bundle)

3.3 Measures

Prevalence (RQ1) is the number of phones on which a store held at least one ghost, and the number of ghosts. Agreement (RQ2) is the number of presence stores holding each ghost; we also drop one store at a time and count the ghosts that vanish. For RQ3, with m presence stores readable on a phone, S ghosts seen, and f1, f2 ghosts seen by exactly one and two stores, the first-order jackknife is S + f1(m−1)/m [16] and the bias-corrected Chao2 is S + ((m−1)/m) f1(f1−1) / (2(f2+1)) [15]. Both estimators assume a closed population, stores that act as independent samples of it (or whose dependence is the same for every app), correct matching of names, and a nonzero chance for every app of being seen by some store. We expect the stores to break the last two: the app-store state is a near-census of what was downloaded, the other stores see small and different parts of the population, and a removed app may be in the reach of no store at all. We sum per-phone values and bootstrap over phones (2,000 draws). A simulation (Section 4.6) draws populations of 200 removed apps and five stores (the phones had more) under six capture mechanisms (400 replications each). For RQ4, the reference time of a phone is the latest time seen in its usage, graphics, app-ops, screen-time and app-store records; a download counts as recent if it lies within w days of it, and as gone if the app is not installed.

3.4 Order of work

We chose the stores and the split into presence and configuration stores after exploratory runs on the same devices, not before; the final run was then fixed and is the only one reported. We did not test any rule against devices held out.

4 Results

4.1 Android extractions: where the ghosts are

Table 3 gives the result per store. The 14 Android extractions held 770 ghosts in all (median 35.5 per phone, against a median of 515.5 installed packages), 416 of them third-party (54 percent), 279 from the platform and Google namespaces and 75 from phone-maker or carrier namespaces.

Share of the 14 Android phones on which each store held a name of a package that is no longer installedPhones with at least one such name, out of the phones on which the store could be read: App-store state 14 of 14; Notification policy 12 of 14; Package restrictions 11 of 14; Shared-storage folders 9 of 14; App-ops records 5 of 14; Vendor screen-time db 4 of 12; Older package lists 3 of 12; Usage stats (named) fewer than 3 of 13; Code-optimisation list fewer than 3 of 14; Runtime grants 0 of 14; Graphics statistics 0 of 14; Media-store package 0 of 14; Crash reports 0 of 13. Counts of 1 or 2 are shown as fewer than 3.Phones with a trace, by store0100 percent of phonesApp-store state14 of 14Notification policy12 of 14Package restrictions11 of 14Shared-storage folders9 of 14App-ops records5 of 14Vendor screen-time db4 of 12Older package lists3 of 12Usage stats (named)<3 of 13Code-optimisation list<3 of 14Runtime grants0 of 14Graphics statistics0 of 14Media-store package0 of 14Crash reports0 of 13
Figure 1: Phones on which each store held the name of a package that is not installed, out of the phones on which the store could be read. Counts of one or two are shown as fewer than three.
Table 3: Ghosts by store on the Android extractions. “Phones read” counts the phones on which the store could be read. Counts of one or two phones are shown as fewer than three; ghost counts are shown in full.
StoreRolePhones readPhones with a ghostGhostsMedian per phone
App-store local state, first download recordedpresence141470032.5
Shared-storage app folderspresence149421.0
App-ops access recordspresence145120.0
Vendor screen-time databasepresence12480.0
Older copies of the package listpresence123110.0
Usage statistics (named records)presence13<312–
Code-optimisation usage listpresence14<3<3–
Runtime-permission grantspresence1400–
Graphics statisticspresence1400–
Media-store package fieldpresence1400–
System crash reportspresence1300–
Notification policyconfiguration14121568.5
Per-user package restrictionsconfiguration141148246.5
App-store local state, no download recordedconfiguration14101132.0

Four stores held no ghost on any phone: runtime-permission grants (14 phones read), graphics statistics (14), the media-store package field (14) and crash reports (13). The code-optimisation list and the named usage-statistics records each held ghosts on fewer than three phones (the usage statistics held 12 ghosts in all). The app-store state held ghosts on all 14 phones (median 32.5). Per-user package restrictions held 482 entries, but almost all in the platform (375) or phone-maker (105) namespaces and only fewer than three third-party, which suggests that they track preinstalled components. Notification policy held 156, of which 17 third-party. Shared-storage folders held 42 ghosts on 9 phones, 35 of them in phone-maker namespaces.

Unnamed residue. Where the usage-statistics store was readable, 12 of 13 phones held records whose package token no longer resolves to a name (1,134 tokens in all, median 66.0 per phone). Their names are gone but their records are not. We did not establish why; the source describes a rewrite that drops data for packages that can no longer be named [6], which would remove such records on a later run.

4.2 Android bug reports

The 7 bug reports held 186 ghosts in presence stores, 16 of them third-party. The battery-statistics dump named ghosts in every report. Table 4 gives the result. A bug report is a text dump, and our readers pick package names from fixed line patterns, so a name can be a service or process identifier; the bug-report counts are a coarser measure than the extraction counts.

Table 4: Ghosts by dump section in the Android bug reports. Counts of one or two reports or ghosts are shown as fewer than three.
SectionReports readReports with a ghostGhosts
Battery-statistics dump7772
Usage-statistics dump44100
Notification dump (configuration)7570
App-ops dump7<311
Package-change list7<34
Graphics-statistics dump7<3<3
Shortcut service (configuration)500

4.3 iOS extractions

On the 32 iOS devices with these stores, third-party ghosts were rare: 37 in all, median 1.0 per phone, 21 held by one store and 16 by two. The installation log gives what Android lacks, an explicit removal witness. It recorded 118 uninstalls of third-party apps that are not installed now, on 18 devices (1 to 22 per device). Of them, 11 (9.3 percent) left a name in any store we read: 7 in the app state registry and 8 in the knowledge store; none in the interaction store, the privacy-permission store or a data container. The 22 data-container ghosts are therefore not from these logged uninstalls. The log held an install-staging entry for only 3 of the 118 bundles, so install times were unavailable for 115. None of the 118 left a data container, which an offloaded app would have left [27]; 68 of them, however, lie within five minutes of another logged uninstall on the same device, so many may be batch removals by the user or by the system, and we did not determine which.

Table 5: Ghosts by store on the iOS extractions (third-party bundles). Counts of one or two are shown as fewer than three.
StorePhones readPhones with a ghostGhosts
Data-container metadata with no installed bundle322222
App state registry321519
Knowledge store31711
Interaction store3100
Privacy-permission store32<3<3

4.4 Agreement between stores

Table 6 and Figure 2 show how many presence stores hold each ghost. On the Android extractions 754 of 770 ghosts (98 percent) were in one store, 16 in two and none in more. Among configuration stores, 255 of 751 traces (34 percent) were also held by a presence store; the rest have no corroboration. Dropping the app-store state removes 688 of the 770 ghosts (89 percent); dropping any other single store removes at most 38 (5 percent, shared-storage folders). The figures differ from the shares read alone (700, or 91 percent, for the app-store state; 42, or 5.5 percent, for shared-storage folders) because dropping a store removes only the ghosts that no other store holds.

Table 6: Presence stores holding each ghost. Ghosts are pooled over phones.
GroupGhostsIn one storeShareIn twoIn three or more
Android extractions77075497.9%160
  third-party only41640497.1%120
Android bug reports18618599.5%01
iOS extractions372156.8%160
How many stores hold the same removed-app nameAndroid phones: 754 of 770 ghosts in one store, 16 in two, 0 in three or more; Android bug reports: 185 of 186 ghosts in one store, 0 in two, 1 in three or more; iOS devices: 21 of 37 ghosts in one store, 16 in two, 0 in three or more.Ghosts by number of presence stores holding themAndroid phones754 of 770Android bug reports185 of 186iOS devices21 of 37one storetwo storesthree or more
Figure 2: Share of ghosts (names of packages that are not installed) held by one, two, or three or more presence stores. The label gives the ghosts held by exactly one store out of all ghosts.

4.5 Residue given a removal witness

Android has no uninstall log in these extractions. The nearest witness is a package in an older copy of the package list that is not installed now: 11 such packages on 3 phones. The per-user package restrictions still named 11 of them and the notification policy 4; the app-store state named fewer than three, and every other store none. The package-change list of one bug report named 4 packages that are not installed; no other section of that report held them. These witness sets are small, and they select packages that were installed at the time of a snapshot.

4.6 Apps that no store names

On the Android extractions the jackknife gives 1,452 and Chao2 12,236 for 770 ghosts seen (Table 7). The bootstrap interval over phones for the ratio to the ghosts seen is 1.87 to 1.90 for the jackknife and 10.67 to 19.10 for Chao2. The two differ by a factor of 8, and at most one of them can be right. Figure 3 shows why neither can be trusted here. In the simulation, when stores are independent and apps are equally easy to catch, the estimators come close to the truth; when apps differ in how easily they are caught, or stores depend on one another, both under-estimate; and when stores see different sub-populations of apps, so that almost no app is seen twice, Chao2 overshoots by a factor of 3 to 13 and the jackknife under-estimates. The corpus resembles the last pattern, since 98 percent of ghosts are seen once. Rare, independent capture would produce the same pattern, and then the high estimate would be closer to right. The capture histories cannot separate the two cases, which is why the number is not identified (Section 2.3). We report the estimators as a range, not as an estimate, and offer no number for the apps no store names.

The ghost count itself is no bound. Some ghosts are not removed apps (Section 6), and some removed apps left a trace in no store we read.

Table 7: Estimators on the corpus (pooled over phones; bootstrap 95 percent interval of the ratio to the ghosts seen).
GroupSeenJackknifeChao2Jackknife ratioChao2 ratio
Android extractions7701,45212,2361.87 to 1.9010.67 to 19.10
Android, third-party4167825,3521.85 to 1.894.89 to 16.36
Android bug reports1863314,8561.75 to 1.805.38 to 36.95
iOS devices3754421.31 to 1.591.02 to 1.24
Table 8: Synthetic scenarios: median over 400 replications of 200 removed apps and five stores. Values are divided by the true count.
ScenarioSeenJackknifeChao2Chao2 at or below truth
independent, equal rates0.831.121.0052.2%
rates differ by source0.851.141.0138.5%
rates differ by app0.530.810.8883.0%
sources positively dependent0.400.480.44100.0%
sources see disjoint sub-populations0.400.7213.040.0%
disjoint sub-populations, apps differ0.200.363.320.0%
Estimators of the apps no store holds, in six synthetic scenarios and on the Android phonesMedian estimate divided by the true count (logarithmic axis): independent, equal rates: jackknife 1.12, Chao2 1.0 times the true count; rates differ by source: jackknife 1.14, Chao2 1.01 times the true count; rates differ by app: jackknife 0.81, Chao2 0.88 times the true count; sources positively dependent: jackknife 0.48, Chao2 0.44 times the true count; sources see disjoint sub-populations: jackknife 0.72, Chao2 13.04 times the true count; disjoint sub-populations, apps differ: jackknife 0.36, Chao2 3.32 times the true count; Android phones, relative to the ghosts seen: jackknife 1.89, Chao2 15.9.Estimate divided by the true count (log scale)0.31 (exact)310independent, equalrates differ: sourcerates differ: appdependent storesdisjoint sub-populationsdisjoint, apps differAndroid (ratio to seen)jackknifeChao2
Figure 3: Median estimate divided by the true number of removed apps in six synthetic scenarios (400 replications each), and, in the last row, the same two estimators divided by the number of ghosts seen on the Android phones, where the truth is unknown.

4.7 Age of traces and the share of recent installs already gone

The app-store state records the first download of each app. Of its 700 ghosts, the median first download lay 443.1 days before the latest time evidence on the phone (quartiles 177.1 to 780.2, longest 2,595 days; Figure 4). The state keeps its names for years. Table 9 turns the dates around: of the apps first downloaded within w days of the latest time evidence, how many are no longer installed. None was first downloaded within one day. Of 10 downloaded within seven days, fewer than three were gone. Within 30 days, 31 of 175 were gone (17.7 percent), and within 90 days 125 of 558 (22.4 percent); for third-party apps, 11.1 percent and 18.4 percent. A restore at setup also sets first-download dates [21], so these shares may include apps reinstalled by a restore; we did not test whether an update moves a first-download date. Apps removed and then dropped from the app-store state are in neither count, which lowers the shares. We cannot give a rate of installs removed within minutes or hours: no store we read pairs an install time with a removal time, and a removal in the last hours of a phone’s life leaves no earlier trace to set against it.

Age of the app-store traces of removed appsNumber of removed apps whose first download lies this many days before the latest time evidence on the phone: 0-30 days: 31; 31-90 days: 94; 91-180 days: 57; 181-365 days: 123; 366-730 days: 176; over 730 days: 219.Removed apps by days since first download0-303131-909491-18057181-365123366-730176over 730219days
Figure 4: Removed apps still named in the app-store state, by days between their first download and the latest time evidence on the phone (14 phones, 700 apps).
Table 9: Apps first downloaded within w days of the latest time evidence, and how many are no longer installed. Counts of one or two are shown as fewer than three, and shares from fewer than three are not shown.
WindowAll apps downloadedgoneshareThird-party downloadedgoneshare
1 day00–00–
7 days10<3–4<3–
30 days1753117.7%63711.1%
90 days55812522.4%2885318.4%

The ghosts include 8 packages whose names carry a clean-up keyword (the list of [23]); a name is not evidence of use.

5 Discussion

What an absence means. For third-party apps, the app store’s own state named 409 of the 416 ghosts; the other stores added seven. An examiner who reads usage statistics, permission records and storage folders and finds nothing has looked where the operating system cleans up. The absence is then weak evidence that the app was never installed, and the app-store state, where it exists, is the first place to look. This agrees with the source description of pruning in the usage-statistics service [6] and disagrees with the practitioner statement that monthly usage files keep removed apps [1]: on the 13 Android phones whose usage statistics we could read, named records of removed apps appeared on fewer than three. The practitioner statement may hold on a build that prunes later; we did not stratify by release.

Corroboration is rare, so a second store seldom confirms the first. A finding from one store is a finding from one witness; the other stores usually have no record to contradict or confirm it. An examiner should say which store a ghost came from and that the others were read and silent.

Unnamed records. Usage-statistics records whose package token no longer resolves are present on most phones. They show that something was recorded for a package that is gone, without saying which; a count of them shows that such records exist, not how many apps they come from.

For tools. A tool that lists “apps ever installed” from one store reports one witness. Stating the stores consulted and the stores silent costs nothing and prevents the reading we warn against.

6 Threats to validity and limitations

A ghost is not proof of removal. A name can be held for a package that was never installed on the phone (a restore request, a default entry, a profile). Presence stores reduce this; only 255 of 751 configuration traces were corroborated by a presence store, so the configuration counts are an upper bound on removed apps. The app-store state, which carries most ghosts, can name apps that were downloaded for another profile or restored; we did not separate them.

Other false positives. We read the app-store state of the primary user only, and the registry lists the packages of every user and profile (Section 3.1), so work-profile and secondary-user apps are not counted as ghosts; the same holds for a name that another user still has. The reverse error remains possible: a package name can disappear from the registry when a system or vendor package is renamed, split or replaced by an update or a module, and then shows as a ghost although the capability is still installed under a new name. The 279 platform and 75 phone-maker ghosts (Section 4.1) are the most exposed, and the third-party class is the cleaner reading; even there, a pre-installed package that was withdrawn counts. We did not test whether an app-store update changes any of the dates used. On iOS, an offloaded app has no bundle container but keeps its data container [27], so some of the 22 data-container ghosts may be apps the user still sees. A logged uninstall is a line in a log whose other causes (updates, system clean-up) we did not test.

The installed set and the readers. We read the registry of each extraction once. A store that failed to parse is unavailable, not empty; read errors were logged and none arose on the final run. The bug-report readers pick names from line patterns and can pick up service or process identifiers. The iOS bundle containers are the installed set, and extension bundles were matched by prefix.

Sample. 14 Android extractions (12 from one phone maker, 9 on the newest Android release), 7 bug reports and 32 iOS devices are not a random sample of phones; store behaviour depends on the build, and we did not stratify. We read the Biome streams of iOS neither as files nor as strings, so the iOS side covers five stores only.

Survivorship and time. Only ghosts that some store kept can be seen, so removed apps that left no trace are not counted. Because some ghosts are not removed apps, the ghost count is not a bound in either direction, and the estimators are not identified for the reason given in Section 4.6. The reference time of a phone is the latest time we saw, not the acquisition time, and removals in the last hours before it are invisible.

Design. The stores and the split into presence and configuration stores were chosen after exploratory runs on the same devices (Section 3.4). No uninstall was performed; we make no claim about why a store keeps or drops a name.

7 Conclusion

Removed apps leave few traces in the stores the operating system manages, and the traces that exist sit in app-level and policy stores, mostly in one. On 14 Android extractions, 98 percent of the 770 ghosts were in exactly one store, and the app-store state alone named 91 percent of them. A capture-recapture estimate of the apps that no store names is not identified on this evidence. On iOS devices, 9 percent of 118 logged uninstalls left a name in any store we read. For the examiner, a missing trace in one of these stores is weak evidence that an app was never on the phone; the finding that matters is which store said so, and which were silent. Future work is a controlled uninstall on test phones, which would date removals and test why each store keeps what it keeps.

Artifact Availability

The analysis code, the readers, a generator of synthetic phone histories with known removed apps, sample synthetic data and a README will be released in the Lab's public artifacts repository, with no release date set (code under the MIT licence, data and text under CC BY 4.0). The package is not public yet, and the sentences that follow describe it as planned. The synthetic part of Table 8 reproduces from them; the corpus tables need the Lab’s research corpus, which cannot be released. Code that reads the corpus takes its paths from a configuration file.

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 generated for the estimator study. The report gives aggregate counts and device classes. It contains no identifiers, personal data, message or file content, or case information. Package names and bundle identifiers were compared in memory and in private files and never appear in a result; no application name from a device appears in this report or its figures. Counts of one or two are shown as fewer than three where a class could identify a device.

Declaration of AI Assistance

The authors conceived the research questions and directed the work. The measurement 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

  1. Andrea Fortuna. 2026. Android pattern of life: hidden artifacts that reconstruct a user’s daily routine. Blog post, April 23, 2026. Retrieved October 29, 2026 from https://andreafortuna.org/2026/04/23/android-pattern-of-life-hidden-artifacts-reconstruct-daily-routine/
  2. Belkasoft. n.d. Android System Artifacts: Forensic Analysis of Application Usage. Vendor article. Retrieved October 29, 2026 from https://belkasoft.com/android-system-artifacts-forensic-analysis-of-application-usage (Read as an extract.)
  3. Magnet Forensics. 2024. 5 iOS forensics evidence sources to capture before they expire. Blog post, October 17, 2024. Retrieved October 29, 2026 from https://www.magnetforensics.com/blog/ios-forensics-evidence-sources-to-capture-before-they-expire/
  4. Xiao Zhang, Kailiang Ying, Yousra Aafer, Zhenshen Qiu, and Wenliang Du. 2016. Life after App Uninstallation: Are the Data Still Alive? Data Residue Attacks on Android. In Network and Distributed System Security Symposium (NDSS ’16), San Diego, CA. Internet Society. doi:10.14722/ndss.2016.23061
  5. Android Developers. n.d. Access app-specific files. Retrieved October 29, 2026 from https://developer.android.com/training/data-storage/app-specific
  6. Android Open Source Project. n.d. UsageStatsDatabase.java, frameworks/base/services/usage (GitHub mirror, master). Retrieved October 29, 2026 from https://raw.githubusercontent.com/aosp-mirror/platform_frameworks_base/master/services/usage/java/com/android/server/usage/UsageStatsDatabase.java (Read as an extract; the snapshot date of the mirror was not seen, so behaviour is not tied to a release.)
  7. Alexis Brignoni. 2019. iOS Mobile Installation Logs Parser. Initialization vectors (blog), January 6, 2019. Retrieved October 29, 2026 from https://abrignoni.blogspot.com/2019/01/ios-mobile-installation-logs-parser.html (The post names uninstall-related log entries; it does not quote the exact line wording we match.)
  8. Abdus Satter, Shishir Panta, Ibrahim Baggili, and Uju E. Okoye. 2026. CleanerScope. DFRWS APAC 2026. https://dfrws.org/?p=21461 (The page returned an access error; the description rests on the abstract as shown in a search result.)
  9. Dong Bin Oh, Somi Lim, Suji Lee, Yesong Jo, Gahyun Choi, Bumyun Kim, and Huy Kang Kim. 2026. Forensic analysis and evaluation of file-wiping applications in Android OS. Journal of Forensic Sciences 71, 1 (2026), 338–352. doi:10.1111/1556-4029.70174
  10. Joshua Dowrick, Paolo Modesti, and Benjamin Findlay. 2026. Android anti-forensics: A systematic review of applications, techniques, and investigative challenges. Forensic Science International: Digital Investigation 58 (2026), article 302159. doi:10.1016/j.fsidi.2026.302159 (Repository record, Crossref record and abstract read.)
  11. Uju Okoye, Roohana Karim, Abdur Rahman Onik, and Ibrahim Baggili. 2026. SoK: Anti-forensics evolution, platform coverage, and mobile residual evidence. Forensic Science International: Digital Investigation 57 (2026), article 302127. doi:10.1016/j.fsidi.2026.302127 (Crossref record read; the abstract was seen in a search result, the article page was not readable.)
  12. Jim Jones, Tahir Khan, Kathryn Laskey, Alex Nelson, Mary Laamanen, and Douglas White. 2016. Inferring Previously Uninstalled Applications from Residual Partial Artifacts. In Annual ADFSL Conference on Digital Forensics, Security and Law, Daytona Beach, FL. Retrieved October 29, 2026 from https://commons.erau.edu/adfsl/2016/wednesday/3
  13. Håkan Petersson, Thomas Thelin, Per Runeson, and Claes Wohlin. 2004. Capture-recapture in software inspections after 10 years research: theory, evaluation and application. Journal of Systems and Software 72, 2 (2004), 249–264. doi:10.1016/S0164-1212(03)00090-6 (Crossref record read.)
  14. Stephen G. Eick, Catherine Loader, M. David Long, Lawrence G. Votta, and Scott Vander Wiel. 1992. Estimating software fault content before coding. In Proceedings of the 14th International Conference on Software Engineering (ICSE ’92), 59–65. doi:10.1145/143062.143090 (Crossref record read; the text was not read.)
  15. Anne Chao. 1987. Estimating the Population Size for Capture-Recapture Data with Unequal Catchability. Biometrics 43, 4 (1987), 783–791. doi:10.2307/2531532 (Bibliographic record read; the formula was taken from secondary descriptions, not re-verified.)
  16. K. P. Burnham and W. S. Overton. 1979. Robust Estimation of Population Size When Capture Probabilities Vary Among Animals. Ecology 60, 5 (1979), 927–936. doi:10.2307/1936861 (Bibliographic record read; the formula was taken from secondary descriptions, not re-verified.)
  17. Seongmin Lee and Marcel Böhme. 2026. Dependency-aware Residual Risk Analysis. In ICSE 2026, Rio de Janeiro. Retrieved October 29, 2026 from https://conf.researchr.org/details/icse-2026/icse-2026-research-track/138/Dependency-aware-Residual-Risk-Analysis
  18. Olivier Binette and Rebecca C. Steorts. 2022. On the Reliability of Multiple Systems Estimation for the Quantification of Modern Slavery. Journal of the Royal Statistical Society: Series A (2022). arXiv:2112.01594
  19. Jinghao Sun, Luk Van Baelen, Els Plettinckx, and Forrest W. Crawford. 2020. Dependence-robust confidence intervals for capture-recapture surveys. arXiv:2008.00127. (The arXiv page states that the paper is to appear in the Journal of Survey Statistics and Methodology.)
  20. Daniel Addai, Sanders Larweh Tetteh, Selorm Adjabeng, and Kingsley Albert Egyir. 2026. How Far Back Can a Phone See? Measured 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/
  21. Daniel Addai, Selorm Adjabeng, Kingsley Albert Egyir, and Sanders Larweh Tetteh. 2026. Where a Phone’s Own Life Begins: Device-Life Boundary Indicators and 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/
  22. Daniel Addai, Kingsley Albert Egyir, Sanders Larweh Tetteh, and Selorm Adjabeng. 2026. Can This Phone Answer This Question? Measuring the Answerability of Date-Bound Questions from Device Life, Retention and Record Semantics. 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/
  23. Daniel Addai, Sanders Larweh Tetteh, Selorm Adjabeng, and Kingsley Albert Egyir. 2026. How Many Records Are Gone? Upper Bounds from Identifier Counters in Android Media and Message Stores. Lab Technical Report LAB-TR-0030, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0030/
  24. Daniel Addai, Kingsley Albert Egyir, Sanders Larweh Tetteh, and Selorm Adjabeng. 2026. Zeroed Cells, Kept Pages, Pending Logs: What SQLite Leaves of a Deleted Row on 47 iOS and Android Devices. Lab Technical Report LAB-TR-0023, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0023/
  25. Xuanzhe Liu, Huoran Li, Xuan Lu, Tao Xie, Qiaozhu Mei, Feng Feng, and Hong Mei. 2018. Understanding Diverse Usage Patterns from Large-Scale Appstore-Service Profiles. IEEE Transactions on Software Engineering 44, 4 (2018), 384–411. doi:10.1109/TSE.2017.2685387. arXiv:1702.05060 (The arXiv version, read for the uninstall-lifetime figures, is titled “Mining Behavioral Patterns from Millions of Android Users”; it reports that about 60 percent of abandoned apps in one Chinese app store lasted under 1.5 days.)
  26. W. A. Link. 2003. Nonidentifiability of population size from capture-recapture data with heterogeneous detection probabilities. Biometrics 59, 4 (2003), 1123–1130. doi:10.1111/j.0006-341X.2003.00129.x (Record and abstract read on the USGS publications page.)
  27. Apple. n.d. How to check the storage on your iPhone and iPad. Apple Support. Retrieved October 29, 2026 from https://support.apple.com/en-us/108429

Cite and download

Cite as

Daniel Addai, Kingsley Albert Egyir, Sanders Larweh Tetteh, and Selorm Adjabeng. 2026. Where Removed Apps Leave Traces: A Per-Store Measurement on Android and iOS Phones. Lab Technical Report LAB-TR-0035, version 1.0. SectraTEK Lab, Prudential Associates. Preprint, not peer reviewed. https://lab.sectratek.com/research/reports/lab-tr-0035/

Citation guide
lab-tr-0035.bib
@techreport{addai2026labtr0035,
  author      = {Addai, Daniel and Egyir, Kingsley Albert and Tetteh, Sanders Larweh and Adjabeng, Selorm},
  title       = {Where Removed Apps Leave Traces: A Per-Store
                 Measurement on Android and iOS Phones},
  institution = {SectraTEK Lab, Prudential Associates},
  type        = {Lab Technical Report},
  number      = {LAB-TR-0035},
  year        = {2026},
  month       = oct,
  howpublished = {https://lab.sectratek.com/research/reports/lab-tr-0035/},
  note        = {Version 1.0, preprint, not peer reviewed. CC BY 4.0}
}

Licence: CC BY 4.0. The print layout of this page is set for US Letter in two columns.

Versions and corrections

VersionDateChange
1.02026-10-29First release.

Corrections: none so far. Errors can be reported through the corrections page.

UpDownto moveEnterto openEscto close