How to Prevent Android Screenshots using FLAG_SECURE

FLAG_SECURE is Android's window flag that tells the system to treat a screen's contents as secure, which blocks OS-level screenshots, screen recording, and casting for that window. You set it with getWindow().setFlags using WindowManager.LayoutParams.FLAG_SECURE. It still works on Android 14 and later, and it does block screen recording, not just still screenshots. But it is not a complete defense: a physical camera, a rooted device, or a patched build can all defeat it, so treat it as one layer rather than a guarantee.

Short answer

FLAG_SECURE is a legitimate, documented control for blocking system screen capture, but not an absolute one. Per the Android WindowManager reference, a window with this flag is excluded from screenshots, screen recordings, non-secure displays, and the Recents preview. It still applies on Android 14 and 15. It also stops screen recording, because recording uses the same secure-surface path. It is not reliable against a determined attacker: a second-device photo, a rooted or hooked device, or an instrumented build can bypass it. OWASP MASVS treats screenshot protection as one platform control among many, so pair FLAG_SECURE with not displaying more sensitive data than necessary.

What FLAG_SECURE does

FLAG_SECURE is a flag you set on an Android window through WindowManager.LayoutParams. When set, the system marks that window's surface as secure and excludes its contents from screenshots, from screen recordings, from non-secure external displays such as casting, and from the thumbnail Android shows in the Recents view. To the user, a screenshot attempt either fails with a message like "Can't take screenshot due to security policy" or captures a black frame.

The flag is per-window, not per-app. It protects only the window you set it on, so every Activity, dialog, or separate window that shows sensitive content needs the flag individually. This per-window scope is the single most common source of gaps, because it is easy to protect the main screen and forget a dialog or a secondary Activity.

How to set FLAG_SECURE

You set the flag before the window renders content, typically in an Activity's onCreate. The standard call is getWindow().setFlags with FLAG_SECURE for both the flag and the mask, placed before setContentView. In Jetpack Compose you set it on the Activity window in the same way, since Compose still renders into the Activity's window.

For content in separate windows, such as a Dialog or a PopupWindow, set the flag on that window as well, because it does not inherit from the Activity. A disciplined approach is to apply the flag in a shared base Activity or a helper that every sensitive screen uses, so no individual screen depends on a developer remembering the call.

Can you screenshot on Android 14+?

No, not through normal means, if the window has FLAG_SECURE set. On Android 14 and Android 15, the flag behaves as documented: the system blocks the screenshot and shows a security-policy message or a black capture. Android did not remove or weaken FLAG_SECURE in these versions, so a standard user pressing the screenshot buttons still cannot capture a protected window.

The qualifier matters. "Cannot screenshot" applies to the built-in capture paths on a normal, unmodified device. It does not extend to a rooted device, a custom ROM, or a build where the flag has been patched out, and it never applies to someone photographing the screen with another phone. So the honest answer is that FLAG_SECURE stops ordinary screenshots on current Android, while leaving the out-of-band vectors open.

Does it prevent screen recording?

Yes. Screen recording and screen casting use the same secure-surface mechanism as screenshots, so a window with FLAG_SECURE appears black in a recording or a cast, and the video shows nothing of the protected content. This is the same guarantee as for still captures, extended to moving images.

The same limits apply, though. A MediaProjection-based recorder on a normal device captures black for the protected window, but a rooted or hooked device can defeat the flag, and an external camera recording the screen is entirely outside its scope. Treat "prevents screen recording" the same way as "prevents screenshots": true for OS-level capture, not for a determined attacker.

Is FLAG_SECURE a reliable control?

FLAG_SECURE is reliable for exactly what it is designed to do, which is block OS-level screen capture on a standard device, and it is not reliable as a defense against a motivated attacker. It is the correct control to use, but it should be one layer rather than your only protection for high-value data. The table below separates what it blocks from what it does not.

The pattern is clear: FLAG_SECURE covers the software capture paths the operating system controls, and it cannot cover anything outside that, from a second-device photo to a device whose framework has been modified. Judge it by that boundary when you decide how much to rely on it for a given screen.

How to test FLAG_SECURE responsibly

Test only your own app, on a device or emulator you control, in an isolated environment. The simplest check is manual: open each sensitive screen on a test build and attempt a screenshot and a screen recording, confirming both are blocked. This alone catches the most common gap, which is a screen that was never given the flag. Repeat the check after any release that adds new screens or dialogs, because a flag that was set once does not automatically extend to windows added later.

For a repeatable audit, tooling helps. Objection, the open-source runtime toolkit built on Frida, exposes an android ui FLAG_SECURE command that can report and toggle the flag on a running window, which lets you verify which windows in your own app are protected. Use such tools strictly against your own application on an isolated test device, in line with OWASP MASTG guidance, and treat the goal as finding unprotected windows to fix, not as attacking software you do not own.

Remediation checklist

Remediation is mostly about coverage and layering. Make sure every window that shows sensitive content sets the flag, and do not lean on FLAG_SECURE as a sole defense where the data is genuinely high-value. The checklist below captures the common fixes.

Two points do most of the work. First, apply the flag through a shared base class or helper so no sensitive screen can ship without it. Second, combine it with rendering no more sensitive data on screen than necessary, which is the OWASP MASVS approach of reducing exposure rather than relying on a single control.

Where this fits in a security scan

Screenshot protection is one of many platform controls a review should check, alongside permissions, network security, and stored secrets. A missing FLAG_SECURE on a screen that shows account details or tokens is exactly the kind of gap that is easy to miss by hand across a large app with many screens.

A scanner like PTKD.com analyzes your mobile app build and reports findings ordered by severity and mapped to OWASP MASVS, which helps you see platform-control gaps in context rather than one screen at a time. To be clear about the boundary: a scanner flags where protections are missing and where risk is concentrated, but you still set FLAG_SECURE in code and decide which screens need it. Applied where the scan shows it is missing, FLAG_SECURE closes the specific gap.

What to take away

• FLAG_SECURE marks a window secure and blocks OS-level screenshots, screen recording, casting, and the Recents thumbnail.
• It still works on Android 14 and 15, so a normal user cannot screenshot or record a protected window.
• It is per-window, so every sensitive Activity, dialog, and WebView needs the flag, which is where most gaps appear.
• It is not a defense against a physical camera, a rooted or hooked device, or a patched build, so use it as one layer.
• Test only your own app on an isolated device, and scan with PTKD.com to find screens where the control is missing.