AfterCall (also written "Aftercall") is an Android ad-fraud/adware technique first publicly documented by DoubleVerify's Fraud Lab (DV Engineering) on 13 July 2026 and subsequently covered by The Hacker News' ThreatsDay Bulletin (23 July 2026), Cybernews and the Spanish-language ad-tech trade outlet IPMark (both 24 July 2026), and Malwarebytes Labs (27 July 2026, author Pieter Arntz) -- the source article that triggered this hunt.

The apps are distributed through the official Google Play Store disguised as everyday utilities -- alarm clocks, calendars, notes apps -- and, per Malwarebytes' review, also as cleaner/optimizer and messaging apps. Unlike normal Android permissions, they deceptively obtain the SYSTEM_ALERT_WINDOW ("Display over other apps"/"Appear on top") special permission. Because this permission cannot be granted through a standard in-app dialog, the app redirects the user into the Settings app and supplies a false justification for why it is needed (e.g., an alarm app claiming the permission is required for alarms to fire while the device is locked); IPMark notes less technically-savvy users are more likely to approve the redirect without understanding the implication. Some apps additionally request the USE_FULL_SCREEN_INTENT permission, which lets a notification render as a full-screen activity even over the lock screen.

Once granted, the app registers a manifest BroadcastReceiver for the PHONE_STATE / ACTION_PHONE_STATE_CHANGED system broadcast, set to an unusually high priority (998) so it runs ahead of other apps (such as legitimate caller-ID tools) listening for the same event. The receiver watches for the call-state transition from RINGING to IDLE -- the moment a call ends -- and immediately launches a full-screen overlay Activity displaying an advertisement, functioning even when the serving app is not actively in use. To increase apparent legitimacy, the ad is wrapped in a fake "call info" screen showing caller details and a profile picture, mimicking a native post-call summary. The same apps also register for device-startup, app-update, and power-connection broadcasts to help the ad-serving mechanism survive reboots and updates.

To resist user-driven removal, the ad-displaying Activity is configured (via manifest attributes such as excludeFromRecents) to omit itself from the Android "Recent Apps"/Overview screen, so a user who swipes away the offending screen cannot easily trace it back to the installed app responsible -- Malwarebytes and The Hacker News both describe this explicitly as evading "identification and manual removal." DoubleVerify notes detection is difficult precisely because the apps do not share package names or identical code structure, and because legitimate caller-ID/utility apps can produce superficially similar post-call behavior, limiting the effectiveness of both static (package/signature) and simple behavioral detection; IPMark's coverage characterizes DV Fraud Lab's countermeasure as AI-driven analysis of behavioral variants across the app population rather than signature matching. Cybernews' 24 July 2026 report additionally found that, despite DoubleVerify's prior disclosure, some AfterCall-pattern apps remained available for download on Google Play at time of writing, including at least one with over 100,000 installs -- indicating the technique's replication rate was still outpacing platform-side takedown as of that date.

DoubleVerify's Fraud Lab states it uncovers dozens of new apps implementing this technique every month, and assesses the scheme as collectively responsible for hundreds of millions of fraudulent/low-quality ad impressions, harming advertisers (wasted spend, unwanted brand association with intrusive behavior) and users (unwanted, difficult-to-remove ad bombardment) alike. No CVE applies -- this is a permission-abuse/ad-fraud technique rather than a software vulnerability -- and no specific package names, C2 infrastructure, or file hashes were disclosed by any source reviewed, consistent with the technique being a UX/permission-abuse pattern replicated across many independently-built apps rather than a single piece of malware with fixed indicators.

Platform-side mitigation: per Android's own developer documentation (source.android.com/docs/core/permissions/fsi-limits), Android 14+ restricts the default grant of USE_FULL_SCREEN_INTENT to apps that declare calling or alarm functionality, and Google Play auto-revokes the permission at install time for apps outside those categories; devices running Android 13 or earlier retain the prior default grant. The SYSTEM_ALERT_WINDOW overlay permission itself still requires only a manual Settings grant regardless of Android version or app category, so this control narrows but does not close the AfterCall vector.

MITRE ATT&CK Mobile scope: this is a narrow, single-technique-family ad-fraud campaign rather than a multi-stage intrusion -- no exploit, no C2, no credential access, no data collection, no lateral movement, and no privilege escalation are described by any source. Cross-checked against the full current Mobile ATT&CK matrix (12 tactics, ~90 techniques/sub-techniques), the sourced behavior supports exactly five techniques across three tactics: Persistence (Event Triggered Execution: Broadcast Receivers, T1624.001, for the high-priority PHONE_STATE receiver); three Defense Evasion techniques (Masquerading: Match Legitimate Name or Location, T1655.001, for the utility-app disguise; Hide Artifacts: User Evasion, T1628.002, for the Recent-Apps exclusion; Impair Defenses: Prevent Application Removal, T1629.001, for the resulting identification/removal resistance); and Impact (Generate Traffic from Victim, T1643, for the fraudulent ad-impression generation). Candidate techniques explicitly ruled out for lacking sourced support include System Information Discovery (T1426) and Access Notifications (T1517) -- phone-state monitoring here is purely an execution trigger, not reconnaissance or notification interception -- Lockscreen Bypass (T1461) -- USE_FULL_SCREEN_INTENT is an OS-sanctioned notification capability, not a defeat of lock authentication -- Boot or Logon Initialization Scripts (T1398) and Foreground Persistence (T1541) -- only manifest broadcast receivers are described, not root-level boot scripts or foreground-service abuse -- and any Command and Control, Credential Access, or Collection technique, since ad-serving traffic is ordinary ad-network communication and no source describes data collection beyond the call-state signal used to fire the ad. A separate DoubleVerify report on a 'zombie'-developer-account Android ad-fraud scheme (compromised dormant accounts driving bot-based click fraud on gaming apps) was reviewed and confirmed unrelated to AfterCall -- no shared mechanism, apps, or actors -- and is excluded from this record.