Camera Data Retention for On-Device AI

Direct answer

A camera privacy review should follow an image from acquisition to its last retained derivative. “Processed on device” says where one computation happened; it does not say whether the original image, preview, decoded bitmap, OCR text, generated description, thumbnail, cache, or export remains afterward. The privacy responsibility in `ANDROID-PRIVACY-01` and the distinction in `PRIVACY-01` require an explicit data inventory. In Cove Photo's checked code, `COVE-OCR-01` records that visible text may be returned as a structured Text field, stored as `detectedText`, copied, or included in OCR-only history export. That code fact is scoped to the reviewed implementation; it does not establish behavior for every camera or model route. Draw a lifecycle: capture or picker import, temporary URI or camera frame, preprocessing, inference input, structured text/result, history database, thumbnail, clipboard/share, backup, and deletion. At each step record owner, storage, lifetime, and whether it can cross an app or device boundary. CameraX ImageAnalysis may deliver frames via ImageProxy; its documentation requires applications to close each proxy after processing, including error handling. That is a resource-lifecycle rule, not an assurance that the frame was never copied elsewhere. Trace all conversions and retain only what the user-facing task needs. Make retention choices explicit. A user might expect a one-time camera question to discard the source after the result, while a history feature may intentionally keep selected output. These are separate modes and should not silently share a broad “save analysis” toggle. If OCR text persists while the original image is discarded, disclose that text may still reveal sensitive information. If a thumbnail is generated for history, treat it as content—not disposable visual chrome. Clipboard copying and system sharing create a user-directed boundary; show what is copied or exported and avoid background transfers. Test each data path using synthetic fixture images with unique visible canary text. Capture, analyze, navigate away, force-stop or recreate the process where relevant, reopen history, copy text, export, and delete. Inspect app-specific storage and database records through supported developer tools. Verify that temporary files and buffers are released on success, cancellation, and exception. Review backup rules separately because app data can be included in Android backup depending on configuration. Do not promise deletion from backup, secure physical erasure, or absence of remote requests unless that exact behavior is tested and documented. Separate OCR from image understanding. Structured text extraction and a generated image description have different content and review boundaries. Do not infer object identity, ingredients, or sensitive attributes from an image when the system only needs visible text. Show extracted text as editable output, preserve uncertainty, and avoid auto-correcting identifiers without review. A content retention matrix can specify whether source image, detected text, interpretation, and user correction are saved independently. Before release, reconcile actual paths with the privacy notice and settings. Test denial of camera permission, picker import, capture cancellation, failed inference, history disabled/enabled, copy/share, deletion, backup/restore, and offline operation. The resulting statement should say which specific items are retained, for how long only when the duration is configured and verified, where deletion applies, and what actions send data elsewhere. Do not extrapolate a single app's implementation to a category of “on-device AI camera apps.”

A receipt scan saves text but not the source image

A user photographs a receipt, asks a local feature to identify visible fields, and later sees the result in history. The product intends to keep the extracted text but discard the original image after processing.

Decision

Represent source pixels, recognized text, interpretation, thumbnail, and user corrections as separate retention items and test each storage path.

Expected outcome

The history view and privacy copy accurately describe what remains; deleting the record removes all app-owned derivatives covered by the operation.

Evidence to collect

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

• Data inventory
• Retention setting
• Deletion cascade

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

Implementation workflow

1. Map capture and import entry points. Document camera frames, ImageProxy ownership, picker URI grants, temporary copies, preprocessing outputs, and any image sent to a model. Identify each component that can persist bytes.
2. Classify every output and derivative. Separate raw image, detected text, generated interpretation, thumbnail, cache, clipboard value, export, and backup. Assign owner, purpose, lifetime, and deletion behavior to each.
3. Implement cleanup on every exit. Release ImageProxy, bitmaps, file handles, and temporary files on success, cancellation, parse failure, and exception. Keep history persistence behind an explicit user/product state.
4. Exercise history and boundary actions. With synthetic canary images, test navigation, process recreation, history, copy, share, backup configuration, and delete. Inspect storage and prove expected items are absent or present.
5. Align disclosure with actual behavior. Review permission rationale and privacy copy against capture, import, network, backup, and export code. State verified retention; do not claim universal deletion or no network from local inference alone.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The data map separately identifies pixels, text, interpretation, thumbnail, cache, clipboard/export, and backup for every supported image entry path.
• ImageProxy and temporary resources close on success and all failure/cancellation paths; synthetic tests verify history and deletion behavior.
• User-facing disclosure distinguishes image retention from text/result retention and avoids unsupported secure-erasure or no-network guarantees.

Decision table

Failure patterns to prevent

• Saying processed locally without retention details
• Leaving thumbnails after deletion

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

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
• CameraX image analysis
• Android app-specific storage
• Android security and privacy overview

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

Frequently asked questions