FLAG_SECURE blocks screen capture and screen sharing of the specific window it is set on, but it does not stop everything, which is exactly why it should be one layer rather than a guarantee. It protects only the window that carries the flag, so a dialog, a notification, a picture-in-picture window, or any surface without it can still be captured or shared. It does not stop an accessibility service from reading on-screen text, because that reads the view content rather than the pixels, and it does not survive a rooted or hooked device or a physical camera. Understood defensively, these gaps tell you where to add protection on your own app.
Short answer
The protection is FLAG_SECURE, which marks a window's surface as secure so it is excluded from screenshots and from screen sharing via MediaProjection. Per the Android WindowManager reference, it applies per window, so its known bypass conditions are surfaces you did not flag, such as dialogs, notifications, and picture-in-picture, plus accessibility services that read text rather than pixels, and rooted or hooked devices. Test it on your own app on an isolated device by attempting a screen share, in line with OWASP MASTG guidance. The remediation is to flag every sensitive window, keep secrets out of notifications and other surfaces, and treat it as one layer. The relevant OWASP control is MASVS-PLATFORM.
The protection involved: FLAG_SECURE and MediaProjection
The control at the center of this is FLAG_SECURE, a flag you set on an Android window to mark its surface as secure. When set, the system excludes that window from screenshots and from screen recording or sharing performed through MediaProjection, the API apps use to capture or cast the screen. A properly flagged window appears black in a MediaProjection capture, which is why FLAG_SECURE is the standard control for blocking screen sharing of sensitive content.
The important detail is the word window. FLAG_SECURE is a property of one surface, and MediaProjection captures the whole screen. So the flag protects the specific window that carries it, while anything on screen that is not that window, a separate dialog, a system notification, an overlay, or a picture-in-picture window, is outside its scope and can still be captured. This per-window nature is the root of most FLAG_SECURE bypasses.
What FLAG_SECURE does and does not stop
FLAG_SECURE does stop the ordinary cases well. On a standard device, a window with the flag cannot be screenshotted or captured through MediaProjection, so a normal screen-share or recording of that window shows black. For its intended purpose, blocking OS-level capture of a specific secure surface, it works as documented on current Android.
What it does not stop is anything outside that one window or outside the OS capture path. It does not protect a surface you did not flag, it does not prevent an accessibility service from reading the text of your views, and it does not survive an attacker with a rooted or hooked device who can disable the flag, nor a second device photographing the screen. So the honest framing is that FLAG_SECURE blocks OS-level capture of the exact window you secured, and nothing beyond that boundary.
Known bypass conditions
The known bypass conditions follow directly from that boundary. The most common is a surface that was never flagged: if sensitive content appears in a dialog, a bottom sheet, a picture-in-picture window, or any window separate from the one you secured, a screen share captures it because that surface has no FLAG_SECURE. This is less a bypass of the flag than a gap in coverage, but the effect is the same.
Beyond unflagged surfaces, sensitive data placed in notifications or toasts can be captured, since those render outside your secured window. An accessibility service can read the on-screen text through the accessibility tree, which FLAG_SECURE does not touch because it operates on the rendered surface, not the view content. And on a rooted or hooked device, tools can disable the flag entirely. None of these requires defeating the flag cryptographically; they exploit the fact that it protects one surface against one capture path.
Per-window gaps and other surfaces
The per-window gap deserves specific attention because it is the easiest to miss. Your main screen may be flagged while a login dialog, an error sheet, a share sheet, or a picture-in-picture player is not, and any of those can display or overlap sensitive content during a screen share. Every window that can show sensitive data needs its own FLAG_SECURE; setting it on the Activity does not automatically cover a separate Dialog or PopupWindow.
Other surfaces multiply the problem. Notifications can reveal sensitive text on the lock screen and in captures, toasts appear over any window, and the Recents thumbnail of an activity without the flag can expose a snapshot. Treating the screen as a single protected thing is the mistake; it is many surfaces, and FLAG_SECURE only covers the ones you explicitly flag, which is why coverage, not the flag itself, is where apps usually fall short.
How to test it safely
Test only your own app, on a device or emulator you control, in an isolated environment, never against software you do not own. The direct check is to start a screen recording or a screen-share session with your own build and walk through every sensitive screen, dialog, notification, and picture-in-picture state, confirming each shows black or reveals nothing. Anything that appears in the capture is an unprotected surface to fix.
Extend the test to the other vectors defensively. Trigger notifications and toasts that might carry sensitive text and check whether they appear in a capture, and review what an accessibility service could read from your views. This mirrors the OWASP MASTG approach of testing screenshot and screen-capture protections on your own app, and the goal is to enumerate the surfaces that leak so you can flag or redesign them, not to attack anything external.
Remediation and the OWASP control
Remediation is about coverage and layering. Set FLAG_SECURE on every window that can show sensitive content, including dialogs, sheets, and picture-in-picture, ideally through a shared base class or helper so no screen ships without it. Keep sensitive data out of notifications, toasts, and the Recents preview, and reduce how much sensitive text is on screen at all, since accessibility and other paths can reach text the flag does not protect.
The relevant OWASP control is MASVS-PLATFORM, which covers platform-interaction protections including screenshots, screen sharing, and backgrounding, tested through the MASTG. Treat FLAG_SECURE as one platform control within that, not as a complete defense: pair it with minimizing sensitive on-screen data and, for genuinely high-value data, with server-side controls, so that a captured surface reveals as little as possible even where the flag does not reach.
Gaps and fixes
Mapping each gap to whether the flag covers it clarifies where to act. The table below summarizes the vectors.
| Vector | Covered by FLAG_SECURE? |
|---|---|
| Screen share of the flagged window | Yes, it shows black |
| A dialog or window without the flag | No, flag it too |
| Notifications and toasts | No, keep secrets out of them |
| Accessibility reading the view text | No, it reads content not pixels |
| Rooted or hooked device | No, the flag can be disabled |
| Physical camera on another device | No, outside any software control |
Read the table as a coverage map. Only the first row is fully handled by the flag; every other row is a surface or condition you address by flagging it, removing sensitive content from it, or accepting it as outside FLAG_SECURE and layering another control.
Hardening checklist
A focused checklist turns the gaps into fixes. The list below covers the measures that matter.
| Check | Action | Done? |
|---|---|---|
| Every window | Set FLAG_SECURE on all sensitive windows, dialogs, and PiP | [ ] |
| No sensitive notifications | Keep secrets out of notifications, toasts, and Recents | [ ] |
| Minimize on-screen data | Reduce sensitive text an accessibility service could read | [ ] |
| Layered defense | Do not rely on FLAG_SECURE as the only protection | [ ] |
| Test capture | Attempt a screen share on your own build and fix leaks | [ ] |
The two that matter most are flagging every sensitive window and keeping sensitive data out of surfaces the flag does not cover, since those close the per-window and notification gaps that cause most real leaks. Testing a screen share against your own build is how you confirm the coverage is actually complete.
What to take away
- FLAG_SECURE blocks screen capture and sharing of the one window it is set on, but not surfaces you did not flag, so it does not stop everything.
- The protection is FLAG_SECURE against MediaProjection; its known bypasses are unflagged dialogs, notifications, picture-in-picture, accessibility text reading, and rooted or hooked devices.
- Test on your own app on an isolated device by attempting a screen share across every screen, dialog, and notification, per OWASP MASTG.
- Remediate by flagging every sensitive window, keeping secrets out of notifications, minimizing on-screen data, and treating it as one layer.
- The relevant OWASP control is MASVS-PLATFORM; scan with PTKD.com to find windows where screenshot protection is missing.
