Android Process Recreation for Local AI Apps

Direct answer

An Android process recreation destroys in-memory engines, conversations, coroutine jobs, and activity objects. Restore the user’s task from small durable inputs and explicit task state, then create a new runtime instance only when the screen or worker is ready. Android distinguishes configuration-driven recreation from system process death and user-initiated dismissal. Compose saveable state can restore lightweight UI state, while larger or durable data belongs in a repository or local database. A native model handle cannot be serialized into saved instance state and should be recreated from a pinned artifact and runtime configuration. Separate what the user needs to resume from what the process happened to hold in memory. A draft prompt, selected file identifier, language pair, and task stage may be recoverable. A partially generated token stream, open AudioRecord, engine pointer, native conversation object, or file descriptor generally needs explicit runtime recovery or should be considered lost. Do not persist large media or private raw output into an instance-state bundle; use appropriately scoped storage and follow the app’s retention policy. Assign task identity and an execution owner. When the activity is recreated, the new ViewModel should read the current task record and observe its state rather than launch a duplicate request immediately. If the task was in-process work and the process died, mark it interrupted and offer a user-controlled restart. If durable background work was intentionally scheduled, attach to its unique WorkManager request and display its actual state. Do not infer that a coroutine persisted because it was in a ViewModel; coroutines stop with the process. For a model runtime, define a restart protocol: validate that the artifact remains available, initialize a fresh engine off the main thread, recreate a conversation from permitted durable context, and clearly identify which input will be resubmitted. Avoid replaying a side-effecting tool call just because the UI returned. Use an idempotency key or a host-side execution record for actions. If a user must repeat a consent or permission step, ask again rather than restoring a stale authorization state. Test rotation separately from process death. Rotation usually recreates an Activity while the process remains; system memory pressure can destroy the entire process after the app is backgrounded. A test that only rotates does not prove recovery after process death. Cover task states before initialization, during load, during streaming, after partial output, after cancellation, after completion but before display, and after a tool action. For every case, define whether to resume, restart, show partial work, or discard it. A user-facing status should explain the actual outcome. If the process died during an unrepeatable action, do not show “completed” from an old loading flag. If the task can be safely restarted, preserve the prompt and ask the user or show a clear retry. If source data was temporary and no longer available, state that the user must reselect it. Recovery sequence: 1. Define a durable task record containing only necessary inputs, artifact identity, selected options, and a stage marker; exclude native handles and unnecessary raw content. 2. On new process start, read that record and classify the prior state as resumable background work, interrupted in-process work, completed output, or unavailable input. 3. Recreate the runtime from pinned configuration, check artifact access, and verify permissions or consent needed for the next stage. 4. Prevent duplicate execution with request identity and host-side state; do not replay completed side effects during UI restoration. 5. Test configuration change, system process death, user dismissal, navigation, cancellation, and app restoration independently. The goal is not to keep a model engine alive forever. It is to restore the user’s task honestly and recreate native resources safely when needed.

The app is evicted during a long analysis task

A user submits a local document summary, switches to another app, and later returns. The original Android process has been destroyed. The screen had shown a spinner, but the engine and partial response no longer exist in memory.

Decision

Reconstruct task state from durable metadata, determine whether work was actually persistent, and avoid duplicating inference or side effects when restoring the screen.

Expected outcome

The user sees one of three truthful states—safe resume, interrupted with retry, or input unavailable—rather than a stale loading screen or false completion.

Evidence to collect

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

• Saved-state contract
• Runtime reinitialization trace
• Interrupted-task recovery

A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.

Implementation workflow

1. Model durable state explicitly. Persist the minimum task identifier, source reference, user options, artifact revision, and stage needed to restore. Keep engine pointers, active streams, recorder handles, and large transient UI state out of saved instance bundles.
2. Classify the previous execution. On process start, distinguish WorkManager work that still exists from an in-process coroutine that ended with the old process. Detect completed output, interrupted execution, missing temporary input, and stale task records.
3. Recreate resources and recheck authorization. Initialize a fresh runtime only after confirming artifact access and required permissions. Ask again for consent when the next action requires it; do not restore an old boolean as current authorization.
4. Guard against duplicate requests. Use task IDs and host-side execution state to avoid launching the same request twice. Do not repeat tool calls or other side effects because the UI resumed from an old spinner state.

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

Acceptance criteria

• Rotation and system process death are tested as different recovery events.
• No native engine handle or large private payload is restored from an instance-state bundle.
• The user sees a truthful resumable, interrupted, completed, or unavailable state without duplicate work.

Decision table

Failure patterns to prevent

• Persisting native handles
• Assuming singleton survival

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 persistent background work
• Android Developers — activity lifecycle and process death
• Android Developers — save UI state in Compose
• Android Developers — persistent background work

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

Frequently asked questions