Some screens should not end up in a screenshot, a screen recording, or the recent-apps thumbnail: a banking balance, a one-time passcode, a private message. On Android, FLAG_SECURE is the switch that blocks those captures for a window. iOS has no exact equivalent, but it offers its own ways to protect sensitive screens. This is a useful privacy measure with a clear limit, since nothing stops someone photographing the screen with another phone. Here is what FLAG_SECURE does, how the platforms differ, and when to reach for it.
Short answer
On Android, WindowManager.LayoutParams.FLAG_SECURE marks a window as secure so the system blocks screenshots, screen recording, and showing the content on non-secure displays or in the recent-apps preview. Per Android's documentation, you set it on windows that display sensitive content. iOS has no direct equivalent, but you can detect screenshots and screen recording and obscure sensitive content when the app is backgrounded, so it does not appear in the app switcher. It is a defense-in-depth privacy measure, useful for sensitive screens, but not absolute, since it cannot stop someone photographing the display with another device.
What you should know
- FLAG_SECURE blocks captures on Android: screenshots, recording, and previews.
- It is per window: apply it to screens with sensitive content.
- iOS differs: no FLAG_SECURE, but detection and backgrounding protections exist.
- It is defense-in-depth: it raises the bar, it is not absolute.
- Use it for sensitive screens: balances, passcodes, private content.
What does FLAG_SECURE do on Android?
It tells the system to treat a window's content as secure and keep it off captures. When you set FLAG_SECURE on a window, Android blocks screenshots and screen recording of that window, prevents its content from appearing on non-secure external displays, and keeps it out of the recent-apps thumbnail, so the sensitive screen does not leak into a saved image or a cast display. This is a window-level flag, so you apply it to the specific screens that show sensitive data rather than the whole app, and the protection applies while that window is shown. The result is that a user, malware with screen-capture access, or the system's own previews cannot capture the marked content, which closes several quiet leakage paths for sensitive information shown on screen.
Android versus iOS: protecting sensitive screens
The platforms take different approaches. The table compares them.
| Goal | Android | iOS |
|---|---|---|
| Block screenshots of a screen | FLAG_SECURE on the window | No direct API to prevent |
| Block screen recording | FLAG_SECURE blocks it | Detect via screen-captured state and hide content |
| Keep sensitive data out of app switcher | FLAG_SECURE hides it | Obscure the view when backgrounding |
| Know a screenshot was taken | Limited | Screenshot notification is available |
So on Android, FLAG_SECURE directly prevents the capture, while on iOS you cannot stop a screenshot outright, but you can detect screenshots and screen recording and react, and you can blur or replace sensitive content when the app moves to the background so the app-switcher snapshot does not expose it. The intent on both is the same, keep sensitive screens from leaking into images, but the mechanism differs.
When should you use it, and what are its limits?
Use it on screens that show data you would not want captured, and treat it as one layer. Good candidates are screens displaying account balances, one-time passcodes, full payment details, private messages, or other sensitive content, where a stray screenshot or a screen recording would be a privacy or security problem. On Android, set FLAG_SECURE on those windows; on iOS, hide sensitive content on backgrounding and consider reacting to capture detection. The limit to keep in mind is that none of this stops someone pointing another camera at the screen, and it does not protect the underlying data, only its appearance in captures. So pair screen-capture protection with the real controls, encrypted storage, server-side enforcement, and minimal sensitive data on screen, rather than relying on it as security by itself.
What to watch out for
The first trap is treating FLAG_SECURE as data protection, when it only blocks captures of what is displayed and does nothing for the stored or transmitted data. The second is over-applying it to the whole app, which can frustrate users who legitimately screenshot non-sensitive screens; scope it to sensitive windows. The third is forgetting the iOS app-switcher snapshot, which can expose a sensitive screen if you do not obscure it on backgrounding. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and assesses how your app handles sensitive data, which complements screen-capture protection by checking the storage and network side. The flag itself you apply per screen in the app.
What to take away
- On Android,
FLAG_SECUREmarks a window secure so the system blocks screenshots, screen recording, non-secure displays, and the recent-apps preview. - iOS has no direct equivalent, but you can detect screenshots and recording and obscure sensitive content when the app is backgrounded.
- Use it on screens showing sensitive data like balances, passcodes, and private content, scoped per screen rather than app-wide.
- It is defense-in-depth, not absolute, so pair it with encrypted storage and server-side enforcement, and use a pre-submission scan such as PTKD.com to check the data side.
