On a normal Android 14 device, you cannot bypass a FLAG_SECURE window with MediaProjection, because a window marked secure is excluded from screen recording and shows up blank in the capture. MediaProjection is Android's screen-recording interface, and FLAG_SECURE is the app-side control that keeps a sensitive screen out of it. The only way to record a FLAG_SECURE window anyway is to strip that flag, which requires a rooted device with a framework like Xposed or LSPosed, since that operates below the app where the platform enforces the flag. Android 14 also hardened screen capture further. So the practical point for a developer is defensive: FLAG_SECURE reliably blocks MediaProjection for users on healthy devices, and the bypass belongs to attackers who fully control a rooted device.
Short answer
FLAG_SECURE blocks MediaProjection screen recording on a normal Android 14 device, and bypassing it requires root. Per Android's FLAG_SECURE reference, a secure window is excluded from screenshots and from non-secure displays, which includes MediaProjection recording, so the window records as blank. On a rooted device, an Xposed or LSPosed module can strip FLAG_SECURE so the content is captured, but that needs full device control. Per the OWASP MASVS, such client-side controls are defeatable on a compromised device. Apply FLAG_SECURE to sensitive screens for the protection it gives healthy-device users, and protect data that cannot leak on the server, assuming a compromised client can record.
MediaProjection and how FLAG_SECURE blocks it
MediaProjection is the Android API that lets an app capture the screen for recording or casting, after the user grants permission, and it is what screen-recording apps use. Against it, FLAG_SECURE is the app-side defense: when you mark a window secure by setting that flag, the system excludes the window's content from screenshots and from capture on non-secure outputs, which includes MediaProjection. The result is that a screen recorder capturing your app sees a blank or black region where your secure window is, so the sensitive content never enters the recording.
This is the intended and reliable behavior on a standard device. FLAG_SECURE is enforced by the platform, so any capture path that goes through the normal system, including MediaProjection-based recorders and screen-sharing, respects it. For a banking, healthcare, or similar app that marks its sensitive screens secure, this means users cannot record those screens with an ordinary screen recorder, which is exactly the protection the flag is meant to provide. The question of a bypass is therefore really the question of what happens when the platform's enforcement can be subverted, which takes more than an app.
What Android 14 changed for screen capture
Android 14 tightened screen capture and added detection, reinforcing the protection around recording. It introduced a privacy-preserving screenshot detection API that lets an app register per-activity callbacks so it is notified when a user takes a screenshot while that activity is visible, though the callback does not provide the image and detection reacts rather than prevents. On devices with the relevant update, app screen sharing also lets users share a single app window instead of the whole screen, excluding system UI from the shared display.
These changes continue Android's direction of giving users control and apps visibility over capture, on top of the existing FLAG_SECURE exclusion. For a developer, the takeaway is that Android 14 makes the platform-level protections and signals stronger, not weaker, so a non-rooted device offers your secure content more protection, not less. None of this changes the underlying rule that FLAG_SECURE excludes a window from MediaProjection, and none of it can protect against an attacker who removes the platform's enforcement entirely, which is the only route to a real bypass.
The bypass requires root: Xposed modules
The reason a MediaProjection bypass of FLAG_SECURE requires root is that the flag is enforced by the system, below the app, so defeating it means modifying the system, which an ordinary app cannot do. On a rooted device, a hooking framework such as Xposed or its modern equivalent LSPosed can intercept the window management path and strip the secure flag, or otherwise disable the exclusion, so that MediaProjection or a root-level recorder captures content that would normally be blank. There are modules built specifically to disable FLAG_SECURE this way.
The essential point is the prerequisite: this needs a rooted device with a system-modifying framework installed, which is full control of the device by whoever wants to record. It is not something a remote attacker does to a victim's normal phone, and it is not something a regular screen-recording app can do. So the bypass exists, but it lives in the same category as every client-side control defeated on a compromised device: possible for someone who owns and has rooted the hardware, and not a threat to your protection for the ordinary users FLAG_SECURE is meant to shield. Understanding that boundary tells you how much to rely on the flag, which is a lot for healthy devices and not at all against a determined, rooted attacker.
Setting up a responsible test
Testing whether your FLAG_SECURE holds against MediaProjection is a legitimate exercise you do only against your own app, on a device you own. Use a dedicated test device or emulator that holds no personal data, install your own app build, and try to record its secure screens with an ordinary screen recorder to confirm they come out blank, which verifies the protection works for normal users. To evaluate the rooted-attacker case, use a rooted test device you control with the relevant framework, and observe that stripping the flag requires that full control.
Keep the exercise bounded. Only instrument applications you have the right to test, keep the rooted environment isolated from personal accounts and production systems, and record your findings so they inform your design. This mirrors how OWASP MASTG frames resilience testing: a controlled check of whether a protection behaves as intended and where its limits are. The purpose is to confirm that FLAG_SECURE does its job on a normal device and to understand, not to weaponize, the rooted-device case, so you can decide what additional protection your most sensitive content needs.
What this means for your app
The practical meaning is that FLAG_SECURE is a strong, worthwhile protection against screen recording for ordinary users, and not a boundary against an attacker who controls a rooted device. Marking your sensitive screens secure genuinely stops screen recorders, screenshots, and casting for the users on healthy devices who make up almost all of your audience, so it is the right thing to do and delivers real protection. Use it on any screen showing data you would not want captured.
At the same time, do not treat FLAG_SECURE as a guarantee that content can never be recorded, because a rooted device with the right module can defeat it, and no on-screen protection stops a second camera pointed at the display. So decide what depends on the recording being blocked with the assumption that a determined attacker can record anyway. For content whose exposure you can tolerate being deterred but not absolutely prevented, FLAG_SECURE is ideal; for content that must never leak, the protection has to live somewhere the device owner does not control.
Remediation
Remediation combines applying FLAG_SECURE well with protecting the real assets elsewhere. Set FLAG_SECURE on every window that shows sensitive content so ordinary capture is blocked, and use Android 14's screenshot detection where a reaction, such as warning the user or clearing content, adds value. Add viewer-tied watermarking to sensitive screens so that if content is captured on a compromised device, the leak can be traced, which deters intentional recording more than a block alone.
The durable protection is server-side and in what you choose to display. Keep high-value data on the server, deliver to the device only what a user is entitled to see, and enforce access with server-side authorization so a recording of the screen does not equal access to the underlying system. Assume the client may be rooted and the screen may be captured, and design so a captured recording does not expose anything you cannot afford to lose. FLAG_SECURE handles the healthy-device case well; the assume-compromise design handles the rooted one, which no client-side flag can.
Protection layers and limits
Seeing the layers together shows where trust belongs. The table below compares them.
| Layer | What it does | Limitation |
|---|---|---|
| FLAG_SECURE window | Excludes the window from MediaProjection recording | A rooted device with Xposed can strip it |
| Android 14 capture hardening | Adds screenshot detection and app-window sharing | Detection reacts rather than prevents |
| Xposed or LSPosed module | Removes FLAG_SECURE so capture succeeds | Requires full control of a rooted device |
| Server-side data protection | Keeps sensitive data off the device | The real protection against a recording |
Read the table top to bottom: FLAG_SECURE protects normal devices well, the bypass needs a rooted one, and only keeping data off the device protects against a determined attacker who records anyway.
Hardening checklist
Working through these steps applies the protection and its limits correctly. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Apply FLAG_SECURE | On every sensitive Android screen | [ ] |
| Test on your own device | Confirm secure screens record blank | [ ] |
| Assume root defeats it | Do not gate real secrets on the block | [ ] |
| Use detection where useful | React to screenshots or recording | [ ] |
| Protect data server-side | Do not ship what must never leak | [ ] |
| Watermark sensitive screens | Trace leaks to deter capture | [ ] |
The step that changes your posture most is protecting data server-side, because FLAG_SECURE and every client-side layer above it can be defeated on a rooted device, while server-held data cannot be recorded off the screen.
Assess your posture
Because screen-recording protection is one layer among several, seeing your app's actual posture helps more than assuming FLAG_SECURE covers everything. Knowing which screens are marked secure, where sensitive data is stored, and what secrets ship in the app is the input to deciding what must move server-side.
A scanner like PTKD.com analyzes your build and reports issues such as insecure data storage, leaked keys, and over-broad permissions by severity, mapped to OWASP MASVS, so you can see what your app exposes if a screen is recorded on a compromised device. To be clear about the boundary: PTKD does not make FLAG_SECURE unbreakable, which is not possible on a rooted device, and it does not test a live bypass. It helps you see your data-protection posture so you invest in the server-side layers that actually hold.
What to take away
- On a normal Android 14 device, FLAG_SECURE excludes a window from MediaProjection, so a screen recorder captures your secure screens as blank, which is the protection it is meant to provide.
- Bypassing that requires a rooted device with an Xposed or LSPosed module to strip FLAG_SECURE, which is full device control, not something a remote attacker or ordinary app can do.
- Android 14 further hardened screen capture with a screenshot detection API and app-window sharing, strengthening protection on non-rooted devices.
- Apply FLAG_SECURE to sensitive screens for the real protection it gives healthy-device users, but do not treat it as a guarantee against a rooted attacker or a second camera.
- Protect data that must not leak on the server, add watermarking and detection, and review your posture with a tool like PTKD.com.
