Redact Crash Reports in a Local AI App

Direct answer

A useful local-AI crash report records the execution boundary, not the user’s private content. Capture app build, OS version, runtime and artifact identifiers, task stage, backend request, cancellation state, exception class, and redacted resource metadata. Do not log the prompt, transcript, image text, model response, auth token, signed URL, database row, or arbitrary exception message without review. Android’s security guidance warns against sensitive Logcat output and recommends sanitizing production logging. “The model ran on-device” does not make diagnostic uploads or shared logs local. Design a small diagnostic schema with allowlisted fields. For user content, prefer a length, content type, or stable synthetic fixture identifier over the content itself. For file paths, remove user names, content URIs, tokens, and query parameters. For exceptions, keep class and a vetted error code; stack traces may include local file paths, SQL fragments, input values, or model paths, so decide which parts are safe before export. Do not rely on masking a substring if the remaining content can still identify a person or secret. Separate developer diagnostics from production telemetry. Detailed local logs can be enabled for a debug build or an explicit user-controlled support session with a clear retention period. Production logs should avoid private variables and use compile-time constants or enumerated categories where possible. If a remote crash reporting service is used, audit what it captures automatically, what custom keys and breadcrumbs are added, where the data is sent, and how long it is retained. The local inference path and the crash reporting path are separate data flows. Give the user a preview before sharing a diagnostic package. Show the included categories, allow removal of optional metadata, and do not include raw prompts or media by default. Provide a cancellation path and delete the temporary export after the send or save operation completes. If a bug report cannot be sent offline, explain that it will not upload until the user initiates the action; do not queue private diagnostics silently and transmit later. Test redaction with seeded sensitive values: names, phone-like strings, email addresses, copied text, prompt contents, file URIs, token-shaped strings, and exception messages containing input. Use synthetic fixtures, not production user records. Inspect Logcat, saved reports, analytics events, and support exports separately. A single redaction pass over the final zip does not prove that earlier logs or breadcrumbs were clean. Failure reports should still support diagnosis. Preserve event order, app version, model revision, runtime version, stage transitions, retry count, and whether a fallback occurred. If a value is omitted, label it unavailable rather than reconstructing it from private content. Keep a schema version so the report parser can distinguish old and new formats. Review checklist: 1. Inventory every log, crash SDK, analytics event, breadcrumb, and user-export path touched by an AI task. 2. Classify fields as needed diagnostics, optional, sensitive, or prohibited; use allowlists instead of free-form bundles. 3. Exercise failure, timeout, cancellation, model-load error, parser error, and network-related setup paths with synthetic sensitive fixtures. 4. Inspect each output surface and verify that redaction holds before and after packaging, restore, and export. 5. Document whether the report remains local, is shared by the user, or can be uploaded; match the privacy notice to that behavior. A report is useful when it explains where a failure occurred without carrying the content that caused it.

A transcript parser crashes on private meeting text

A developer needs to diagnose an exception that occurs after on-device transcription. The default logging statement includes the raw response, and an automated crash reporter can attach breadcrumbs to a remote report.

Decision

Replace content logging with an allowlisted event record and inspect every local and remote diagnostic surface using synthetic text before enabling the reporting path.

Expected outcome

The team retains the failure stage, versions, and error class while avoiding raw transcript or prompt disclosure.

Evidence to collect

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

• Release logging policy
• Failure-path review
• Opt-in diagnostic export

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

Implementation workflow

1. Map diagnostic data flows. List Logcat calls, crash SDK attachments, custom keys, analytics, breadcrumbs, local debug files, and user-created support exports. Mark every destination, trigger, retention period, and default inclusion.
2. Define an allowlisted schema. Keep build, OS, runtime, artifact revision, stage, event order, and vetted error category. Exclude prompts, transcripts, model output, image contents, credentials, user paths, signed URLs, and unreviewed exception text.
3. Run redaction fixtures end to end. Inject synthetic names, email-like strings, prompt contents, URIs, tokens, and exception messages. Inspect Logcat, breadcrumbs, export archives, and remote reports independently after packaging.
4. Make sharing deliberate. Preview optional diagnostics before sharing, allow cancellation, define temporary-file cleanup, and explain network behavior. Do not silently queue private reports for later upload.

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

Acceptance criteria

• AI logs and reports contain enough stage and version metadata to reproduce the path but no raw user content by default.
• Synthetic sensitive fixtures remain absent from every inspected log, breadcrumb, export, and remote report.
• Any external diagnostic transfer is visible, user-controlled, and accurately described in the privacy copy.

Decision table

Failure patterns to prevent

• Dumping full requests
• Calling metadata anonymous without fields

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
• Android Developers — Log information disclosure
• Android Developers — privacy and security overview
• Android Developers — secure data storage

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

Frequently asked questions