A screen recording callback is an application-level listener that reports when the system detects recording has started or stopped. On Android 15, it gives developers visibility into screen-sharing activity so they can respond with warnings, redaction, or safer UI behaviour. It is most useful when paired with a runtime check of current recording state.
Expanded Definition
A screen recording callback is a platform event hook that tells an app when recording or sharing of the display begins or ends. The key boundary is that it reports state change, not the content being captured, so it is a signalling mechanism rather than a protection control. In Android 15, the callback helps apps notice that a sensitive screen may be exposed and adapt the experience in real time.
That distinction matters because developers sometimes treat the callback as a substitute for prevention. It is not. It supports responsive behaviour such as masking values, changing layouts, or warning the user, but it cannot stop capture by itself. Guidance-vs-consensus note: there is broad agreement that detection is useful, but implementations differ on how aggressively apps should react to recording versus benign sharing use cases.
Android 15 behavior changes for screen recording callback is the most direct source for the platform’s intended use and helps clarify the lifecycle boundary between recording detection and app response.
Examples and Use Cases
- A banking app detects recording has started and hides account numbers, balances, and one-time prompts before they appear on-screen.
- A healthcare portal switches to a reduced-detail view when screen sharing is active so clinicians can continue work without exposing unnecessary patient data.
- A support workflow shows a clear banner when the user begins sharing their screen, helping them avoid revealing tokens, chat transcripts, or admin consoles.
- A developer tool keeps sensitive debug panes collapsed during recording while leaving non-sensitive navigation unchanged.
- A transaction app uses the callback together with a current-state check so the UI reflects the latest recording status, rather than relying on a stale event alone.
The main implementation tradeoff is between usability and exposure. Overreacting can frustrate legitimate collaboration, while underreacting leaves sensitive information visible long enough to be captured.
Security Implications
The security issue is not the callback itself but the exposure window it helps manage. If an application assumes users will not record sensitive flows, secrets, customer data, MFA prompts, or admin screens may be captured without any server-side signal. Once recorded, that material can be replayed, forwarded, or extracted outside the app’s control.
A common failure mode is treating detection as equivalent to redaction. If the app learns about recording too late, or does not re-check the current state before rendering critical content, the sensitive frame may already be exposed. Another failure mode is inconsistent handling across screens, where one workflow masks data and another silently leaks it.
Practitioners should watch for features that render high-value data in a single frame, such as verification codes, recovery secrets, or privileged actions. In those cases, the callback is most useful as a trigger for safer UI behaviour, not as the control that carries the protection by itself.
Domain and Governance Relevance
In broader cybersecurity terms, screen recording callbacks sit in the class of runtime exposure controls: they help an application respond when confidentiality risk increases during interactive use. That makes them relevant to secure UX design, data minimisation, and protection of high-sensitivity workflows where visual disclosure is itself a control failure.
For identity-heavy systems, the relevance is sharper. Authentication, recovery, and privileged administration screens often expose the very artifacts that attackers want to capture, including tokens, codes, or privileged state. A callback-driven response can support safer presentation of those flows, but governance still needs clear rules for which screens must mask content, which may tolerate sharing, and who owns those decisions.
The practical question for teams is not whether recording exists, but whether the application degrades safely when it does. That is a design and ownership issue as much as a technical one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Recording callbacks help reduce exposure of privileged data on-screen. |
| 3 — Data Protection | The term concerns preventing visual disclosure of sensitive data. | |
| Recommendation — Restrict high-value screen content so recording events cannot expose unnecessary privileged information. Apply data protection rules to mask or suppress sensitive fields when screen capture is detected. | ||
| NIST CSF 2.0 | PR.DS — Data Security | The callback is used to preserve confidentiality of displayed data. |
| PR.PT — Protective Technology | The feature supports protective UI behaviour during exposure events. | |
| Recommendation — Use runtime recording awareness to protect data displayed in sensitive user flows. Implement protective UI responses when the system reports recording is active. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Screen capture can expose secrets, tokens, and recovery artifacts used by NHI workflows. |
| Recommendation — Mask secrets and credential artifacts whenever recording could reveal them on screen. | ||
| NIST AI RMF | GV — Govern | Governance is needed to decide how apps should respond to recording events. |
| Recommendation — Define policy for when applications must warn, redact, or block sensitive content. | ||
Related resources from NHI Mgmt Group
- What is the difference between screen scraping and API-based banking access?
- Why do custom domains make OAuth callback governance harder?
- Why do passwordless projects still fail if passwords are removed from the main login screen?
- Why do OAuth and OIDC flows need both callback protection and token validation?
