Direct answer
Use StrictMode as a development-time tripwire around realistic local-AI flows, not as proof that the app is fully offline, fast, or free of threading defects. Android describes StrictMode as a developer tool that detects operations such as accidental disk or network access on the main thread. That makes it useful when opening model files, reading configuration, importing an artifact, preparing media, updating a database, or writing diagnostics could happen inside a UI callback. Configure a narrow policy in a debug or test build, execute the paths users actually take, and inspect each violation in context. Then move the work behind the correct owner, add a regression test where possible, and decide whether any remaining violation is intentional and documented. StrictMode is not a network inventory. The absence of a logged cleartext or main-thread network violation cannot establish that no request was sent from a worker thread, an SDK, a background service, or an operating-system component. The repository’s privacy fact explicitly separates local inference from other application network requests. A network audit therefore needs endpoint and payload evidence, not just a StrictMode run. Likewise, zero StrictMode warnings on one fixture set does not prove the absence of all main-thread blocking: detector coverage, platform version, policy settings, and execution paths matter. Make the policy actionable. Include a stable build identifier, task name, operation stage, thread, and exception/violation class, but do not include prompts, transcripts, images, account identifiers, or private file paths. A redacted stack trace can still identify the call site; store any symbol or diagnostic artifacts under controlled access. Keep policies targeted so a large collection of unrelated warnings does not train the team to ignore them. Some checks are process-wide or virtual-machine-wide; assign one test owner and avoid competing policy installation by different screens. The current Cove ModelManager serializes model loading and exposes explicit model lifecycle states. StrictMode can help reveal accidental I/O around a task, but it does not test that state machine’s correctness or prove the native inference engine is thread-safe. Test state transitions separately: missing artifact, load start, success, failure, cancellation, cleanup, and next attempt. Treat a successful load as only that stage; a representative feature task still needs its own acceptance conditions. Finally, verify the build boundary. Debug policies should not unexpectedly crash or disclose information in a release variant. Use an explicit build-type guard or dedicated test harness, inspect the merged manifest and code path where appropriate, and add a release test proving verbose diagnostics are absent. StrictMode is most valuable when every report turns into a narrow fix or an evidence-backed exception—not when warnings are merely silenced globally.
Opening a downloaded model freezes the first screen
A local AI app checks model storage and reads configuration from a button callback. The screen sometimes stutters on first launch, but there is no reproducible timing dataset. A developer wants to find accidental main-thread I/O without publishing unsupported performance claims.
Decision
Enable a targeted debug StrictMode policy, reproduce the exact load-entry flow, fix violations at their owning layer, and keep network-privacy verification separate.
Expected outcome
The team gets call-site evidence and regression coverage while the release build remains free of verbose developer diagnostics.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Debug policy and build identity
- Representative lifecycle fixtures
- Violation, fix, and regression record
A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.
Implementation workflow
- Scope policy to a testable build. Install the policy only in a debug or instrumentation harness and name the exact application build. Select detectors relevant to the investigation, such as disk reads/writes or network on the main thread, and choose a reporting action that preserves useful stack context without logging user content.
- Exercise representative paths. Run cold app launch, model inventory, import, load, one fixed inference fixture, cancellation, failure recovery, and screen recreation. Record which scenario ran and whether the path was cold or warm; do not treat one path as coverage for all app components.
- Classify and assign each report. For every violation, identify the thread, call site, owner, user action, and whether the work is expected. Move blocking work to an application-owned worker boundary; avoid merely wrapping a UI callback in an ad hoc thread that loses cancellation and lifecycle control.
- Separate threading diagnostics from privacy proof. Use traffic capture or an endpoint inventory to answer whether the app or its SDKs make requests. StrictMode’s main-thread network detector cannot observe every request. Keep the event schema redacted, and do not log prompt or media payloads while reproducing.
- Retest and protect the release boundary. Repeat the fixture after the fix, assert expected operation ownership, and add a regression check for the call site or architectural boundary. Build a release variant and confirm the debug policy, verbose traces, and sensitive paths are not exposed to users.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The policy is confined to an explicitly identified debug/test path and does not silently alter release behavior.
- Each reported violation maps to a user scenario, owning component, thread, and disposition; unexplained warnings are not globally suppressed.
- No claim of complete offline operation is based on an empty StrictMode log; network behavior is checked with separate endpoint evidence.
- Diagnostics contain no prompt, transcript, image payload, account identifier, or unredacted private path.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| StrictMode run | Detect selected classes of accidental operations in exercised paths | Good for locating specific violations; not a complete performance or network audit. |
| Traffic / endpoint audit | Observe destinations and request fields across app and SDK paths | Needed for network claims; does not by itself identify every UI-thread I/O site. |
| Release acceptance suite | Re-run task and lifecycle behavior in the release configuration | Checks shipped behavior and debug-policy exclusion; must be scoped to tested paths. |
Failure patterns to prevent
- Enabling checks without task coverage
- Shipping private paths in reports
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does zero StrictMode output prove the app never contacts a server?
No. StrictMode is not a complete network inventory. It detects selected operations in exercised paths, and a request may occur on a worker, through an SDK, or outside the tested flow. Use endpoint and traffic evidence for network claims.
Should StrictMode be enabled in every release build?
Use it primarily as a development and test diagnostic. If a project intentionally retains a policy, document its behavior, reporting cost, privacy implications, and release rationale; do not ship verbose user-content logs.
Can I suppress all disk warnings because model loading needs file access?
Avoid blanket suppression. Inventory or model I/O may be necessary, but the question is whether it blocks a user-facing thread and whether it has a clear owner. Fix accidental blocking and document only narrowly justified exceptions.