Android Low-Memory Recovery for Local AI

Direct answer

“Out of memory” is not one diagnosis. A managed-heap allocation exception, native buffer allocation failure, the operating system killing a background process, a runtime refusing an artifact, and a task timeout can all look like the app disappeared or stopped responding. Start by identifying the observed failure stage and preserving the input configuration. Android Studio’s Memory Profiler and heap-dump tooling can show managed objects retained at a capture point, while process and native-memory evidence may require different tools. A heap dump alone is not a complete record of GPU, native, or system memory. Separate artifact storage from runtime working memory. A model file’s byte length does not predict peak application memory; runtime buffers, caches, token context, decoded image or audio inputs, Compose state, and operating-system headroom contribute. Do not publish a generic RAM threshold without test evidence for the exact app, artifact, runtime, backend, and task. A successful model load with a short text prompt does not prove an image task or long session fits. Record cold start and representative workload separately. Recovery starts with non-destructive steps. Save the current task’s minimal resumable state before releasing resources, cancel inference if the runtime supports it, close sessions in their documented order, and show whether the result was saved, partial, or lost. If the app’s model manager deletes an artifact after a load failure, disclose that behavior and verify that it does not delete user content. Do not automatically erase notes, recordings, images, or unrelated files to make room. If the user must remove or download a large model, ask for confirmation in the product and describe storage consequences. Reproduce with the same artifact and task, changing one memory factor at a time: prompt/context size, image dimensions, audio segment length, concurrent requests, repeated runs, or whether a previous engine was closed. Capture baseline, post-load, task peak, post-cancel, and post-close observations. Keep the same metric definition across runs. If the process was killed rather than throwing an exception, record the system evidence and lifecycle state instead of inventing an application exception string. The user experience should provide a recovery path that does not hide uncertainty: retry with a smaller supported task only if that behavior is implemented, keep an incomplete result labeled incomplete, allow a deliberate model unload, and provide a way to report a privacy-safe diagnostic summary. Do not claim a smaller input guarantees success. Preserve a fallback that is honest about what it can do, such as manual entry or a non-AI task path, rather than silently routing private content to a cloud service. This guide describes diagnosis and recovery design, not Cove’s performance limit. Cove has no raw device benchmark record for a universal memory budget. A release claim requires a versioned test record. Recovery workflow: 1. Classify the stop: capture exception, native error, runtime load failure, system process death, app-not-responding, or user cancellation. Save timestamps, device/OS, app build, model identity, backend request, task size, and log category without storing sensitive content. 2. Reproduce the smallest failing task and capture baseline, loaded, peak-task, post-cancel, and post-close memory using the metric appropriate to the question. Keep heap and process RSS distinct. 3. Release owned sessions in order, preserve durable user inputs and completed results, and verify the state machine returns to a retryable or clearly blocked state. 4. Change only one workload variable, rerun, and compare to the acceptance rule. Mark a smaller task as a mitigation only if the app offers and tests that option. A safe recovery is measured by user data preservation, resource release, visible status, and a verified next action—not merely by whether the screen opens again.

A photo-analysis task closes the app after model load

A reviewer can open a local AI app and complete a short text prompt, but a representative image task is followed by a process restart. The team has no trace tying the restart to a managed-heap exception, native allocation, operating-system process kill, or an unrelated crash.

Decision

Preserve the test configuration, classify the failure before changing model size or deleting data, and repeat one controlled workload using the appropriate memory evidence.

Expected outcome

The app either completes the task or exposes a truthful failure state while preserving user input and safe recovery controls.

Evidence to collect

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

• Process recreation test
• Artifact integrity after restart
• User-task recovery

A device badge must come from an exact device, OS, artifact, runtime, backend, and workload record, not parameter-count intuition.

Implementation workflow

1. Classify failure before recovery. Capture app and OS versions, artifact and backend, task inputs by size rather than private content, last visible state, exception category, and process lifecycle. Distinguish a thrown allocation error from a process that was removed without a managed exception.
2. Measure the correct memory layer. Use heap snapshots for retained managed objects and the relevant profiler or system diagnostics for process memory. Record baseline, post-load, representative task peak, post-cancel, and post-close; do not compare heap bytes with RSS as if they were the same metric.
3. Release resources and preserve user work. Cancel supported work, close conversation and engine through their owners, save only resumable task metadata and completed output, and keep raw user material under its normal retention policy. Never delete unrelated user data to free model space.
4. Change one workload variable. Reduce or isolate one factor such as image dimensions, context, audio segment, concurrency, or repeated-session count. Rerun the fixed test and state whether the change is a tested mitigation, a temporary diagnostic, or an unverified suggestion.

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

Acceptance criteria

• The failure is labeled by observed stage and evidence rather than a guessed exception or phone compatibility claim.
• Cancellation or failure releases engine-owned resources and preserves durable user inputs and completed outputs.
• The next user action is explicit and does not silently upload private content or delete unrelated data.

Decision table

Failure patterns to prevent

• Assuming singleton survival
• Deleting user content with model repair

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 Memory Profiler
• Android Developers — capture a heap dump
• Android Developers — activity lifecycle and process death
• Android Developers — memory profiler

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

Frequently asked questions