If FLAG_SECURE is not blocking a screen recording, the most common reasons are that the flag is not actually set on the window being recorded, that it was applied too late, that you are testing on an emulator, or that a device's manufacturer build does not fully honor it. FLAG_SECURE is per window and must be set before the window renders, so a dialog, a separate surface, or a late call can leave content capturable. On some Xiaomi, Samsung, or custom-ROM builds, the flag has been reported not to be fully honored, and emulator or specific MediaProjection behavior can differ from a normal device. Confirm the flag is set on the exact window and test on real target devices.
Short answer
When FLAG_SECURE fails to block a recording, check your own setup first, then device behavior. Per the Android WindowManager reference, the flag applies to the specific window it is set on and must be set before the window shows its content, so a wrong window, a late call, or a separate surface leaves content capturable through MediaProjection. Emulators may not honor it, so test on real devices. Some manufacturer builds, including certain Xiaomi and Samsung versions, and custom ROMs, have been reported not to fully respect it. Confirm the flag is on the exact window shown, set early, and verify across your target devices, treating FLAG_SECURE as one layer.
First: is the flag actually set correctly?
Before blaming the device, confirm the flag is genuinely applied to the window being recorded. FLAG_SECURE protects only the specific window it is set on, and it must be set before that window renders its content, typically in onCreate before setContentView. If you set it on the wrong window, or after the content is already shown, the recording can capture what you expected to be protected.
Verify this concretely on your own app. Check that the exact screen appearing in the recording is the one carrying the flag, and that any dialog, bottom sheet, or picture-in-picture window shown over it also has the flag, since those are separate windows. A large share of not-working reports come down to the flag being set on the Activity while the sensitive content is actually in a different window that was never flagged.
Setup mistakes that make it fail
Several setup mistakes silently defeat FLAG_SECURE. Setting it too late is common: if the call happens after the window is already displaying content, the protection may not apply to what is on screen. Setting it on the wrong window, such as the Activity when the sensitive view lives in a dialog or a PopupWindow, leaves that separate window unprotected. And a separate rendering surface, like a SurfaceView or a media surface, can behave differently from the main window.
In Jetpack Compose, the flag still applies to the host Activity's window, so you set it on that window rather than expecting a composable to carry it. The reliable pattern is to apply FLAG_SECURE early, on every window that shows sensitive content, ideally through a shared base Activity or helper so no screen ships without it. Ruling out these mistakes usually explains a recording that still captures content, before any device-specific cause.
OEM overrides: Xiaomi, Samsung, and custom ROMs
Once your setup is confirmed correct, device behavior is the next place to look. FLAG_SECURE is honored by standard Android and by major manufacturers, but there have been reports over time of specific manufacturer builds or built-in screen recorders, including on some Xiaomi and Samsung versions, not fully respecting it, and custom ROMs can deliberately disable it. So the same app that is protected on one device may be captured on another.
This is why testing across your actual target devices matters, rather than a single device. If a particular manufacturer's build or its native screen recorder captures a flagged window, that is a device-level behavior you cannot fully control from the app, which reinforces treating FLAG_SECURE as one layer rather than a guarantee. For high-value data, assume some devices may not honor it and reduce how much sensitive content is on screen accordingly.
MediaProjection bugs and emulators
Screen recording on Android goes through MediaProjection, and a few environment-specific behaviors can make FLAG_SECURE appear broken. Emulators are a frequent false alarm: an emulator may not enforce secure surfaces the way a physical device does, so a recording or screenshot on an emulator can capture a flagged window even though a real device would not. Always confirm behavior on a real device before concluding the flag is broken.
Version and implementation differences can also play a role, and historically there have been inconsistent cases where specific capture paths or builds behaved inconsistently. The practical stance is to test on current, physical target devices with the actual capture method your users would use, rather than relying on an emulator or a single environment, since that is where FLAG_SECURE either genuinely works or genuinely does not for your users.
How to test it correctly
Test only your own app, on real devices you control, in an isolated environment. Start a screen recording with the device's own recorder and walk through every sensitive screen, dialog, and picture-in-picture state, confirming each shows black or nothing. Repeat on each manufacturer and Android version you support, since the result can differ by device, following OWASP MASTG guidance for testing screen-capture protections on your own app.
Avoid drawing conclusions from an emulator, which may not enforce secure surfaces. If a real device captures a flagged window, first re-verify that the flag is set on that exact window and set early, then treat a confirmed capture on a specific manufacturer build as a device behavior to account for. The goal is to know, per target device, whether the protection holds, so you can design around the devices where it does not.
Causes and fixes
Matching the cause to a fix turns a vague not-working into a concrete step. The table below pairs the common causes with their fixes.
| Cause | Why the recording still captures | Fix |
|---|---|---|
| Flag on the wrong window | The recorded surface is not flagged | Set FLAG_SECURE on every shown window |
| Flag set too late | Applied after the window rendered | Set it before setContentView |
| Testing on an emulator | Emulators may not enforce it | Test on real devices |
| Manufacturer or ROM override | The build does not fully honor it | Test across target devices, layer defenses |
| Separate surface | A dialog or SurfaceView is uncovered | Flag that window or surface too |
Read the table in order, since the first three are within your control and explain most cases. Only after ruling out setup and emulator issues is a manufacturer or ROM override the likely cause, and that one you manage by testing broadly and not relying on the flag alone.
Remediation checklist
A short checklist resolves or explains most not-working cases. The list below covers it.
| Check | Action | Done? |
|---|---|---|
| Correct window | Confirm FLAG_SECURE is on the window being shown | [ ] |
| Set early | Apply it before the window renders content | [ ] |
| Real device | Test on physical devices, not an emulator | [ ] |
| OEM coverage | Test across your target manufacturers and versions | [ ] |
| Layered defense | Reduce on-screen sensitive data, do not rely on it alone | [ ] |
The two that resolve most reports are confirming the flag is on the correct window set early, and testing on a real device rather than an emulator. If it still fails on a specific manufacturer build after that, treat it as a device behavior to design around, not a bug you can fix from the app.
What to take away
- A FLAG_SECURE recording failure is usually a setup issue: the flag on the wrong window, set too late, or a separate window left unflagged.
- Emulators may not enforce secure surfaces, so always confirm behavior on a real device before concluding the flag is broken.
- Some manufacturer builds and custom ROMs, including certain Xiaomi and Samsung versions, have been reported not to fully honor FLAG_SECURE.
- Set the flag early on every sensitive window, test across your target devices, and treat FLAG_SECURE as one layer, not a guarantee.
- Scan with PTKD.com to find windows where screenshot and recording protection is missing across your app.
