Screenshot Privacy for Local AI Screens

Direct answer

A screenshot-privacy review should map each sensitive screen to the capture surfaces it can reach: a user-requested screenshot, screen recording, casting or a non-secure display, the Recents/app-switcher snapshot, system UI, and an explicit share or export action. These are different boundaries. `ANDROID-PRIVACY-01` treats data access and user control as application responsibilities; `PRIVACY-01` also makes clear that local inference does not prove the rest of an app has no data flow. Neither fact means a screen can be made impossible to capture. Start from concrete screen states rather than a blanket “private app” setting. List the content shown during initial loading, model or language setup, an active prompt, generated output, history, an error, a permission dialog, and a user-reviewed export. For each state identify who can see the content, whether it is sensitive, whether a snapshot is retained when the activity leaves the foreground, and which control applies. A screen with a personal transcript can need different handling from a public settings page. Avoid collecting real sensitive examples for screenshots; use synthetic fixtures with unique canary text. Android exposes window-level security controls such as `FLAG_SECURE` and a screenshot-detection callback on supported platform versions. Their documented scope matters: a secure window can restrict screenshots or display on non-secure outputs while applied, but a detection callback is not a prevention mechanism and cannot establish that every capture path is blocked. Operating-system behavior, external cameras, accessibility, user-controlled sharing, and content copied elsewhere remain separate considerations. Verify the exact API behavior against current official Android documentation and the app's target versions before describing it. Test lifecycle boundaries that often reveal stale previews. Navigate from a sensitive result to another screen, background the app, open Recents, lock and unlock, rotate or recreate the activity, and return. Check both the visible window and the task snapshot. Verify that protection is applied before private content is first rendered, remains scoped to the intended screen, and is removed only when the screen no longer requires it. A late effect can protect a screenshot taken after navigation but still expose the initial frame. Do not place private text in notifications, debug overlays, accessibility labels, or analytics because the main window is protected. Keep screenshots and exports as separate product functions. Blocking screenshots everywhere may interfere with legitimate user choice or support; allowing a user to export selected content does not justify background capture. Show a preview before a share or export, identify the fields and destination pathway that the user selected, and avoid bundling unreviewed prompts, transcripts, filenames, or diagnostics. If an app allows copy, clipboard and recipient apps introduce their own boundary. Do not suggest `FLAG_SECURE` encrypts content or controls an export after the user has explicitly shared it. The evidence record should include app build, Android API level, exact screen/state, capture action, protection configuration, result, and known exclusions. Repeat the test on every relevant activity or window type; one protected screen does not prove the whole app. State only what was observed, such as “this result screen used the secure-window flag in this build,” not “screenshots are impossible” or “data cannot leak.” This makes screenshot protection a reviewable UI control while keeping user-selected sharing and other data paths visible.

A private transcription appears in Recent Apps

A user opens a saved voice transcript, switches apps, and later returns. The product wants to reduce casual exposure in the task switcher while still allowing the user to export a selected note deliberately.

Decision

Apply a narrowly scoped screen-capture control before sensitive text appears, test the task snapshot and lifecycle transitions, and keep export as a separate user action.

Expected outcome

The test documents the exact screens and platform conditions affected without claiming that external cameras, sharing, or every capture route are prevented.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Screen inventory
• Capture and recents tests
• User-visible disclosure

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

A screen inventory, together with capture and recents tests and user-visible disclosure checks, should be recorded and compared so that behavior across states and surfaces can be reviewed against the intended configuration.

1. Inventory sensitive screen states. List loading, setup, prompt, result, history, error, permission, and export screens. Mark which fields are sensitive and which window or system surface can display them.
2. Choose a scoped Android control. Use the current official API documentation to decide whether a secure-window flag or detection callback applies to the exact screen and supported OS range. Do not treat detection as prevention.
3. Protect before first private render. Apply the chosen state before rendering private content. Navigate, background, open Recents, lock/unlock, recreate the activity, and return to check both live window and task snapshot.
4. Exercise user-directed boundaries separately. Test copy, share, and export with a preview and synthetic canary text. Check notification, accessibility, logging, and analytics surfaces that are not covered by a window flag.
5. Record precise scope and exclusions. For each build and API level, record screen, state, control, capture action, result, and exclusions. Avoid statements that all screenshots or leaks are impossible.

Acceptance criteria

• Every sensitive screen state has a documented capture-surface decision and a test for task-switcher lifecycle behavior.
• The selected protection is active before sensitive content renders and is scoped to the intended screen; export/share remains a separate explicit action.
• The result states API/build scope and exclusions and makes no absolute capture-prevention or privacy guarantee.

Decision table

Failure patterns to prevent

• Blocking screenshots everywhere without need
• Assuming capture controls secure exports

Blocking screenshots everywhere without need, or assuming capture controls also secure exports, can create gaps or unnecessary friction, so the guidance limits release wording to what has been recorded as evidence.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• Android WindowManager.LayoutParams FLAG_SECURE
• Android 14 screenshot detection
• Android security and privacy overview

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions