Android MediaProjection API is an Android platform API that lets an app capture screen contents and system audio from the device. It works by granting time-limited capture permission through a user consent prompt, then exposing a virtual display or audio stream for recording, casting, or remote support workflows.
What Android MediaProjection API Does
Android MediaProjection API gives an app a temporary, user-approved way to capture what is shown on the screen and, on supported devices, system audio. That makes it the platform mechanism behind screen recording, casting, remote assistance and some accessibility or collaboration features, but it also means the API can expose highly sensitive on-device information if it is misused.
The important security property is consent-backed capture. Android does not hand out persistent screen access by default; the app must obtain an explicit prompt-driven grant and then work within the scope of that session. In practice, that boundary is only as strong as the app requesting capture and the user’s understanding of what is being shared.
Why Screen and Audio Capture Is Sensitive
Screen capture can expose passwords, one-time codes, private messages, financial data, internal dashboards and other information that is never meant to leave the device. When system audio capture is also enabled, the risk extends to calls, notifications and other spoken or played content that may reveal context the user did not intend to share.
That sensitivity is why MediaProjection is often treated as a high-trust capability even when it is legitimate. A benign support workflow can become a data disclosure path if the app records beyond the intended session, overlays misleading UI, or captures sensitive views without clear user awareness.
Consent, Scope and User Expectations
MediaProjection is designed to make capture visible to the user, but visibility is not the same as informed consent. The prompt establishes authority for the session, yet the user still needs to understand what is being shared, for how long, and with whom the output may be stored or transmitted.
That distinction matters because the API sits at the boundary between device privacy and application functionality. If an app turns a temporary screen-sharing action into broad recording, analytics, or remote surveillance, the problem is no longer the API itself but the way the app stretches the granted scope.
How Developers Should Think About Safe Use
MediaProjection should be treated as a privileged data-access path inside the app, not as a routine utility call. Developers need to design for narrow capture windows, visible indicators, clear stop controls and careful handling of anything recorded from the display or audio stream.
It is also wise to assume that captured content may contain secrets, regulated data or private communications. The safest design pattern is to minimise retention, avoid background capture, and ensure that sharing or storage of recordings is intentional, bounded and transparent to the user.
Risk and Threat Considerations
MediaProjection creates a direct path from the device screen to an app-controlled recording stream, so the main risk is unintended disclosure of whatever appears on the display during the granted session. That risk rises when users are interrupted, when sensitive apps remain visible, or when a capture app disguises the true purpose of the request.
Failure mechanism: An app obtains a valid capture grant, then records sensitive on-screen content or system audio beyond the user’s practical expectation, or uses the captured stream as an exfiltration channel.
Impact: Credentials, messages, financial details, internal business data and other private content can be exposed, stored, replayed or transmitted outside the device boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | MediaProjection usage should be logged and reviewable when capture is initiated or stopped. |
| Recommendation — Log capture start, stop and privilege-relevant events for screen-recording features. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Screen and audio capture features need traceable event records for misuse review. |
| Recommendation — Record and review MediaProjection usage events in your audit logging process. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | MediaProjection is a privileged capture path that should be limited to narrowly approved use. |
| AU-2 — Event Logging | Capture sessions should generate events that support detection and post-incident review. | |
| Recommendation — Restrict screen-capture permissions to the smallest set of approved app functions. Define audit events for capture requests, grants, start and stop actions. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Capture activity is security-relevant application behaviour that needs logging and monitoring. |
| Recommendation — Define logging requirements for screen- and audio-capture features. | ||
Practitioner Guidance
Why practitioners should care: If your app uses MediaProjection, you are handling a high-sensitivity data stream, not just a convenience feature. Product, security and privacy teams should agree on where capture starts and stops, how users are informed, and what data is allowed to persist after the session ends.
What to watch for: Be especially cautious where screen capture overlaps with authentication flows, enterprise apps, healthcare data, payment data or support tooling. The strongest operational control is to keep capture narrow, visible and user-initiated, then minimise what is stored or forwarded afterward.
Related resources from NHI Mgmt Group
- How should security teams handle Android app release cycles when target API requirements change?
- Why do older Android API levels create risk for enterprise mobile apps?
- What breaks when Android apps target a newer API level without setting a minimum version?
- What is the difference between target API level and minimum API level in Android apps?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org