For years, investigating a compromised Android device has meant relying on whatever evidence happened to survive on it. The logs were built for debugging, not detection, retention was measured in hours rather than months, and spyware knew exactly how to clean up after itself.
Intrusion Logging (IL) is built to change that. Arriving in Android 16 as part of Android’s Advanced Protection Mode, and developed in partnership with Amnesty International's Security Lab, it is the first feature on a major mobile platform designed from the ground up for forensic investigation. We wanted to see how much of a difference it makes, so we tested it on live Pixel hardware. What we found is a real step forward, with some important caveats worth understanding before you rely on it.
Why it Matters
To appreciate what IL does, it helps to know what investigators have had until now. Android's existing logs, logcat, tombstones, and bug reports, were all built for engineers rather than analysts. They overwrite themselves within minutes to hours, carry little security context, and capture at most a day or two of activity. Sophisticated spyware such as Pegasus, Graphite, and Predator has long exploited exactly these limitations, using aggressive anti-forensic techniques against a platform that was never built to remember.
IL inverts that model. Instead of mining diagnostic logs that happen to contain useful traces, it produces a dedicated, encrypted, user-owned security record, backed up to the owner's Google Account and retained for 12 months. It survives even if the device is wiped or seized, and crucially, even Google cannot access it.
What's Actually Inside an IL Bundle
When we pulled and decrypted IL bundles from a Pixel 10 Pro, individual collections ran from around 93,000 to nearly 600,000 events, the largest spanning more than three weeks of activity, across three event types.
DNS events are where a lot of the investigative value lives. Every hostname lookup is recorded alongside the specific app that requested it, so a suspicious domain is no longer an isolated network indicator but one tied directly to the package responsible. That kind of per-app DNS attribution did not exist in Android's standard logging.
Connection events capture destination IPs and ports with the same per-app attribution, giving analysts a map of what each application was actually talking to. In our example above and below, both streams carry the app name, so they line up.
Security events are the richest layer. Across our captures we observed 25 distinct subtypes, covering process launches (with the SHA-256 hash of the executed binary), ADB activity, device unlocks, boot state, certificate installations, password changes, and Advanced Protection policy updates. The app_process_start subtype is the standout: it moves an investigator from asking what was installed to knowing what actually ran, when, and with what system privileges.
Below is what is captured when the WhatsApp process is launched
Failed Device unlocks are also captured
A specific capture from our lab evaluation illustrates this investigative utility firsthand.
During a brief three-minute window, an investigator utilized ADB for app discovery and deletion, with IL preserving the entire sequence. The record included package listings, diagnostic queries, the final uninstallation, and even a complex multi-line awk script used to calculate storage impact. Every one of the nineteen distinct commands was logged in its entirety, as demonstrated by this uninstallation event:
That level of reconstruction was not possible on Android before.
The Limits
IL is not a complete record of device activity, and treating it as one would be a mistake.
The biggest blind spot is encrypted DNS. Any app that performs its own DNS-over-HTTPS resolution, Chrome being the obvious example, bypasses IL's view: you see the bootstrap lookup, then silence. This is not caused by Android's system-wide Private DNS, though. With Private DNS enabled in strict mode, IL kept recording normally, because the system resolver still handles the lookups first. The same held when we tested a full-device VPN: the tunnel did not hide per-app DNS or destinations, and the VPN connection itself showed up plainly in the record.
There are other gaps. Wi-Fi network history is not captured, so IL cannot tell you whether a device joined a rogue access point. Installer source is also missing from app-installation events: you learn that an app appeared, but not whether it came from the Play Store, was sideloaded, or installed through ADB. Interactive ADB sessions record that a shell was opened, but not what was typed inside it. And shutdowns leave no trace, so power-off times have to be inferred from gaps in the record.
Timing matters for incident responders too. IL logs are backed up to the cloud rather than streamed live, so the most recent 12 to 24 hours of activity may not be in the bundle yet when you first collect it. Document your collection time against the last event timestamp, and where possible, give the device time to complete a backup before drawing conclusions about recent activity.
Tooling: Promising, but Still Maturing
The open-source forensic ecosystem is catching up. Both androidqf and Amnesty International's Mobile Verification Toolkit (MVT) have added IL support, which is a meaningful step. We did hit a bug in the current MVT release (2026.5.12): every security event is labelled generically as event_id rather than its real subtype, collapsing process launches, ADB commands, certificate installs, and boot events into a single undifferentiated bucket. The fix is already merged upstream (PR #815) but has not yet shipped, so until it does, work from the raw payloads rather than the summary view.
Our own Threat Hunter for Android now supports IL collection and parsing directly, informed by this hands-on research.
What Comes Next
Google and Amnesty International's Security Lab deserve real credit here: they built IL around consent and privacy from the start — encrypted storage, user-controlled release, long-term retention, and an event stream focused on what matters for security rather than repurposed diagnostic data.
IL is a genuine step forward, but it is early. Enrolment is manual and per-device, with no management hook we could find, which raises real questions for enterprise and BYOD deployments.
The feature also protects only those who turn it on before something happens; it has no retroactivity. For anyone with a heightened risk profile, the time to enable it is now, not after a compromise is suspected.
Today, practical use still looks like a forensic workflow: user interaction on the device, then ADB or specialist tooling to retrieve and parse the bundle. That's workable for labs and incident responders, but it limits reach.
A consent-driven API that let trusted security tools like iVerify collect and analyze IL data at scale, without weakening the privacy model that makes the feature credible, would be the logical next step.
As rollout expands, Intrusion Logging should become one of the first artifacts collected in Android incident response. It will not be the whole story, but for the first time on Android, it may preserve enough of the story to know where to look next.
Subscribe to our blog to receive the latest research and industry trends delivered straight to your inbox. Our blog content covers sophisticated mobile threats, unpatched vulnerabilities, smishing, and the latest industry news to keep you informed and secure.