Verify Offline Translator Readiness After Reboot

Direct answer

An offline-ready claim after reboot needs a fresh task on the rebooted device, not a screen that remembers the last successful session. Separate the pre-reboot state, device restart, app cold launch, asset check, runtime initialization, language selection, translation request, result display, and recovery. `ARCH-01` defines on-device AI by where inference executes, while `COVE-LIFECYCLE-01` describes explicit model states and storage lookup in the checked project code. `ANDROID-PROCESS-RESTORE-2026-01` distinguishes lightweight UI saved state from durable task data and native runtime handles. These facts support a restart test but do not guarantee any app retains assets or runs after reboot. Record what was true before restarting: app build, installed asset identity and path, selected language direction, user history, app permission state, and connectivity. Do not use a warm process as baseline evidence. Reboot the device under a controlled test procedure, then cold-launch the app. Verify whether the expected file remains accessible and whether the runtime actually opens it. A stored language preference is not proof that its asset remains; a file’s name or non-zero length is not proof of identity or valid format. If digest metadata is absent, report that gap rather than claiming cryptographic verification. Test a new input that cannot be satisfied by a prior cached answer. Keep the network disabled from launch through result display and record the requested route. Verify each stage separately: language selection, required asset lookup, runtime readiness, task execution, output validation, and any optional speech playback. If the app shows a previous transcript, distinguish history display from a new inference. If a task queues until connectivity returns, capture that state and do not call it offline completion. Include state and failure cases that a reboot can expose: asset path unavailable, storage volume not mounted, database migration pending, permission state changed, runtime not initialized, account or entitlement check unavailable, and a previous task left incomplete. Reboot should not cause the app to silently delete user records or label a missing model ready. Give each outcome a clear next action: retry local initialization, request the asset, restore permission, or explain that the current task cannot run. Do not promise background completion or universal persistence. Run at least two different controlled configurations only if the product intends to make a claim covering them; otherwise scope the report to the one tested setup. Preserve all failed runs and identify Android version, device configuration without turning it into a support verdict, build, artifact, storage location, network controls, and test fixture. This is a readiness procedure, not a speed or reliability benchmark. The repository fact card does not contain real-device benchmark results, so do not add startup time, supported-device, battery, or success-rate figures. Finally, distinguish reboot from reinstall. Reboot normally restarts processes while leaving application storage in place; reinstall or clearing data changes a different set of state and may remove app-private assets. Android backup and transfer behavior is separate again. A report should state which operation was performed rather than using “restart” loosely. If the task only succeeds after downloading an asset again, say that the post-reboot path required setup. The user should see an accurate ready, loading, missing, or failed state, and any claim must describe exactly the tested sequence.

A traveler restarts a phone before entering a no-connectivity area

The required translation asset was installed earlier and a language direction was selected. After a device reboot, the owner wants to confirm a fresh translation works without a network, not merely reopen an old conversation or cached result.

Decision

Cold-launch after reboot, verify the actual asset and runtime state, submit a new harmless fixture with connectivity blocked, and record every stage.

Expected outcome

The test identifies whether the task was genuinely rerun, needed setup, or failed; it does not imply universal persistence or device support.

Evidence to collect

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

• Pre-reboot asset and app state
• Cold-start task fixture
• Network-denied completion and recovery trace

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Freeze the pre-reboot inventory. Record build, asset identity/path, selected language direction, permission state, history state, and network configuration. Label any missing digest or revision as unknown.
2. Reboot and cold-launch. Use a controlled device restart, then start the app without restoring a warm activity. Record which screens and stored preferences return, without treating UI state as model readiness.
3. Check asset access and runtime open. Verify the configured file path, available identity evidence, and actual runtime initialization. Do not infer validity from filename, file presence, or old successful output.
4. Run a fresh task with connectivity denied. Use a new synthetic phrase and keep the network blocked through the result. Record language selection, asset lookup, runtime, output, and optional playback separately.
5. Exercise recovery and scope the report. Test missing storage, incomplete previous task, changed permission, unavailable account check, and initialization failure. Preserve user records and state exactly which configuration was tested.

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

Acceptance criteria

• The run distinguishes device reboot and cold start from warm-process resume, reinstall, clear-data, and backup restore.
• A newly supplied fixture completes or reaches a classified failure with network blocked; cached history is not counted as new inference.
• The report records asset/runtime evidence and unresolved gaps without inventing startup, reliability, battery, compatibility, or success-rate results.

Decision table

Failure patterns to prevent

• Testing only a warm process
• Equating downloaded with ready

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

• On-device AI architecture overview
• Android Activity lifecycle
• Android Compose state saving
• Android app-specific storage

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

Frequently asked questions