Privacy & screen protection
Turn on the app-level screen-capture switch and know exactly what it can — and cannot — do per platform.
CtrlApp ships an owner-controlled per-app policy for screen-capture protection. The switch is off by default; when on, each SDK applies the best available protection for its platform.
DashboardApps → your app → Privacy & Screen Protection → Screen capture
Per-platform behavior
- Android — sets
WindowManager.LayoutParams.FLAG_SECURE. Blocks native screenshots and screen recording on protected activities. - iOS — attaches a private window that masks the app while a screen recording is active and blurs during backgrounding.
- Flutter — routes to the Android / iOS behavior via the plugin bridge.
- .NET / MAUI — routes to the underlying platform mask.
- Web — best-effort DOM mask that blurs the page while backgrounded, blurred, or printing. Browsers cannot reliably prevent OS-level screenshots; treat this as UX, not a security boundary.
Browsers cannot block OS screenshots
No web SDK can. On the web, the switch reduces incidental screen-share exposure — do not present it to end users as a screenshot block.
Verify it
Verify it
- On Android, attempting a native screenshot from a protected activity fails or shows a blank frame.
- On iOS, backgrounding the app while recording produces a masked recording.
- On web, backgrounding, minimizing, or printing the tab visibly blurs the page.
- Toggling the setting in the dashboard changes the SDK behavior on the next launch (or next policy refresh).
Common mistakes
- If web users report the app can still be screenshotted — expected — clarify UX copy; do not promise browsers can block OS screenshots.
- If Android still allows screenshots — the activity is not protected by the SDK — call the SDK's protect helper on that activity.
Setting semantics and per-platform behavior are enforced in the SDKs (see packages/ctrl-sdk/src/privacy-shield.ts, sdk/ctrlapp_android/, sdk/ctrlapp_ios/).