Recover a Local AI App from a Crash Loop

Direct answer

A crash-loop recovery flow is about repeated startup failure across launches, not a single inference error. Persist a small, privacy-safe startup attempt record with app build, selected artifact identity, startup phase, and terminal reason where available. On the next launch, compare recent failures using a conservative policy; if repeated failure is tied to model initialization, avoid loading the same candidate before the user can reach a repair screen. Offer safe actions such as inspect status, switch to a known available variant, remove only an identified candidate with consent, or open support diagnostics. Never make “clear all app data” the first recovery step. The current ModelManager provides explicit model states and its loadModel path handles an initialization failure by releasing state and deleting the current model file before returning to a not-downloaded state. That behavior is a local code fact and a reason to audit recovery boundaries; it does not establish a production crash-loop detector, safe mode, or actual repeated user crash reports. A process crash may occur before the code catches a failure, so an exception handler alone is not a loop detector. Do not claim the app presently offers a safe-start mode unless implementation evidence exists. On supported Android versions, ApplicationExitInfo can provide information about prior process deaths and a reason category. It does not always identify the model as a cause, and support/reporting varies by platform. Combine available process-exit evidence with an app-owned startup marker and phase transitions, while preserving uncertainty. Avoid treating any single low-memory or crash reason as proof that a model artifact is defective. A bad config, incompatible runtime, missing storage path, or unrelated startup crash can produce similar user-visible symptoms. Keep the detector conservative. Write an attempt marker before expensive model startup and clear or advance it only after the app reaches a defined stable point. If the process dies during startup, the next launch can see an incomplete attempt, but it should not immediately count every force-stop or upgrade as an application crash. Record app version, runtime version, artifact revision, and phase; if one of these changed after the failure, do not compare it as the same attempt. Use a threshold policy that is explicit and tested, not an invented universal number. Provide a manual recovery route even if the detector has insufficient evidence. Safe-start should avoid the failing component. Delay model load until the user can access settings or recovery; otherwise the app may crash before it can display the repair option. Keep history database opening independent of model initialization where possible. If cleanup is offered, name the exact candidate file and explain whether it can be redownloaded; do not delete conversations, transcripts, images, or preferences as a side effect. If a user changes variant or runtime, keep that as a separate state transition and make sure the previous known-good identity remains available when policy permits. Test launch sequences with injected failures: model file missing, parser rejection, engine initialization failure, low-storage condition, permission/path unavailable, process kill before and after the startup marker, app upgrade between attempts, and successful recovery. Verify that a single failure does not trigger safe mode too early, repeated failures do not create an infinite loop, and a new artifact/build resets or reclassifies prior attempt history. Preserve a minimal diagnostic record without prompts, generated output, personal file paths, or credentials. A successful recovery should record the action and state, not claim a general reliability improvement. ### Procedure 1. Define what counts as startup begun and startup stable. Persist a minimal marker with app/runtime/artifact identity and phase, excluding user task content. 2. On relaunch, reconcile the marker with available ApplicationExitInfo and current versions. Treat missing or ambiguous reason data as unknown, not proof of model failure. 3. Enter a safe-start screen before retrying the same model initialization when a tested threshold policy is met. Keep database/history access available independently where architecture allows. 4. Offer scoped recovery actions. Explain exact artifact removal or variant change, preserve user records, and keep a prior known-good path when available. 5. Inject startup failure and app-update sequences. Verify single failures, repeated failures, changed artifact/build, success after repair, and diagnostic redaction. ### Acceptance criteria - A single ordinary error is not confused with a repeated startup crash loop; attempt identity includes the relevant app/runtime/artifact versions. - Safe-start is reachable before the failing model load repeats and exposes bounded, reversible actions. - Cleanup names and affects only an identified candidate and never silently deletes user-authored history. - Unknown process-exit causes remain unknown, logs are privacy-safe, and loop detection cannot trigger endless retry. ### Comparison | Signal | Useful interpretation | Not enough to conclude | |---|---|---| | One model-load exception | A single initialization attempt failed | The app is in a crash loop | | Repeated incomplete startup markers | A pattern worth a safe-start check | The model alone caused every process exit | | ApplicationExitInfo reason | Platform-reported process-death context when available | Full root cause or universal support across Android versions | ### FAQ **Does one failed model load mean the app is in a crash loop?** No. A loop means repeated startup failures across attempts. Track phases and versions, and keep a manual recovery screen available even when evidence is uncertain. **Can ApplicationExitInfo identify the model as the cause?** Not by itself. It can provide process-death context where supported, but app-level phase records and controlled reproduction are needed to connect the event to model initialization. **Should safe mode clear all app data?** No. Recovery should target a specific failing candidate or setting with consent. Preserve chats, notes, recordings, and other user-created content unless the user explicitly requests deletion. **Should the app retry model loading on every launch?** Not after repeated failures without a change. Use a bounded policy, expose repair actions before repeating the failing path, and reset failure classification only when a relevant version or state changes.

The app restarts and fails at model initialization on successive launches

A user reopens an offline AI app after a prior startup failure. The selected model file may be missing, incompatible, or unrelated to the process exit. If startup immediately repeats the same load path, the user may never reach settings or history.

Decision

Use phase markers and available process-exit evidence to detect a repeated pattern, then expose safe-start and repair before attempting the same candidate again.

Expected outcome

The user can access history and choose a scoped recovery action; uncertain causes remain unknown and unrelated data is preserved.

Evidence to collect

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

• Crash-loop threshold policy
• Safe-start path
• Artifact repair result

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Record a minimal startup attempt. Before model initialization, store app build, runtime revision, selected artifact identity, phase, and a unique attempt token. Do not store prompts or generated content.
2. Reconcile on the next launch. Check whether the prior attempt reached a stable marker, compare versions, and inspect available ApplicationExitInfo data. Unknown or unsupported reasons must not be labeled model corruption.
3. Route to safe-start before retry. When the tested repeated-failure policy is met, defer the same model load and let the user reach settings, history, and recovery controls first.
4. Offer narrow and reversible repair. Identify the exact candidate or setting to repair. Preserve user history, explain whether a model can be re-downloaded, and do not wipe app data as an automatic fallback.
5. Test changed-state recovery. Inject one failure, repeated failures, app upgrade, changed artifact, storage loss, and successful repair. Confirm only relevant changes reset the loop classification.

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

Acceptance criteria

• Attempt state distinguishes one initialization failure from repeated startup failure and records relevant versions.
• The user can reach a safe-start screen before the same failing model path is retried.
• Repair actions are specific, reversible where possible, and never erase unrelated user history.
• Platform-reported unknown exits remain unknown; retry is bounded and diagnostics exclude user content.

Decision table

Failure patterns to prevent

• Retrying model load indefinitely
• Resetting user content

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 ApplicationExitInfo process-death information
• Android Activity lifecycle
• Android process lifecycle and app process state

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

Frequently asked questions