Recover Model Downloads After Android Power Loss

Direct answer

Treat power loss as a reconciliation problem across durable work records, filesystem state, and remote representation—not as proof that an interrupted download can resume. After reboot, inspect the persisted artifact identity and transfer phase, then compare them with the actual temporary file and the server response before appending bytes or promoting a file. Resume only when the range response proves that it continues the same representation at the expected offset. If identity, offset, validator, or required metadata cannot be established, isolate the candidate and restart safely. Preserve any known-good active model and unrelated user data throughout recovery. Power loss differs from an ordinary process death. A process can disappear while the operating system remains running; a power interruption also stops volatile work and may occur between a file write and the application’s next durable state update. Neither a worker database row nor a temporary file alone describes the full truth. The correct procedure reconciles both. Android’s persistent-work APIs can reschedule eligible work, but durable scheduling does not make arbitrary file writes transactional or prove which bytes reached storage. The implementation must define its own checkpoints and recovery policy. The current project downloader writes to a temporary path, tracks transfer progress, uses HTTP Range for continuation, and attempts final promotion after transfer. These facts support a recovery test plan; they do not establish that every interrupted write is durable or that an artifact has a configured cryptographic digest. In the current facts, the configured model SHA-256 field is empty. Therefore a recovery process must not describe length, server status, filename, or a successful rename as cryptographic integrity verification. If the trusted expected digest is absent, state that limit, retain only the trust checks actually available, and do not imply stronger provenance than the system has. Make the artifact identity immutable for the life of a partial file. It should include a model or pack identifier, pinned revision or manifest version, expected length when known, expected digest and its provenance when available, and the URL or source identity under the application’s trust policy. A filename such as model.tmp is not identity. Persist the offset at which the application believes durable bytes end, but on restart independently inspect actual file length. If the file is shorter than recorded state, reduce the recoverable offset or restart according to policy. If it is longer, do not assume the tail is valid; the last write may have been torn or its metadata may not have been committed. Preserve diagnostic facts such as stage and byte counts, but never log authorization headers, signed URLs, prompts, or user content. Before resuming, issue a request that asks the server for bytes after the locally accepted offset, and validate the response. A partial response must start at that exact offset, identify the same representation through a strong validator or an equivalent pinned artifact identity, and have a content range consistent with expected length. A server can ignore a range request and return a complete representation; the client must detect that case rather than append a full body to a partial file. A changed revision, mismatched range, unexpected HTML error page, or unknown length should lead to rejection or a clean restart, not a best-effort append. HTTP semantics define range responses, but application code still has to enforce them. Structure writes so recovery decisions are observable. Write to a candidate file rather than the active model. Persist a state transition only after the corresponding file operation has reached the durability level the application intends to rely on; use platform file APIs deliberately and test the sequence on supported filesystems. On recovery, reconcile worker state with file size and identity, validate remote range headers, append only accepted bytes, then run the available completion checks. Promote the candidate only after all policy-required checks pass. If promotion uses rename, ensure candidate and destination are on a storage location where that operation has the intended semantics; do not assume across-volume moves are atomic. Define safe outcomes instead of forcing every case into retry. A valid matching partial file can resume. A missing temporary file may restart from zero. A changed representation should be quarantined or discarded as model data and fetched as a new candidate. A response that violates expected range rules should stop with a diagnosable error. A full file whose expected digest is available should be checked against it; if no trusted digest exists, do not claim digest verification. Keep the old active artifact until the candidate is verified and loadable, and make an explicit rollback or repair route available if loading fails.

A device restarts during a model transfer

A phone loses power while a large artifact is being written. On reboot, the work record has one offset and the temporary file may show another; the server may also serve a changed representation.

Decision

Reconcile persisted state, actual bytes, immutable artifact identity, and a validated HTTP range response before resuming or promoting anything.

Expected outcome

Matching partial data can continue as a candidate; uncertain data is isolated or restarted, while the previous active model and user data remain untouched.

Evidence to collect

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

• Injected shutdown points
• Partial-file and manifest identity
• Restart, reverify, and rollback results

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

Implementation workflow

1. Define durable checkpoints. Persist artifact identity, state-schema version, source identity, known expected length and digest provenance, temporary path, last confirmed offset, response validator, and transfer phase. Do not treat transient runtime handles or a worker row as a durable file transaction.
2. Reconcile disk and state. After reboot, inspect the actual candidate file, its storage location, and its byte length, then compare those observations with the recorded phase and offset. Treat missing or contradictory metadata and unexpected extra bytes as uncertain rather than silently accepting them.
3. Validate the server range. Request continuation from the accepted offset and verify the response status, exact range start, total length, representation validator, and expected content type. Reject an ignored range, changed revision, or error document instead of appending it to existing bytes.
4. Resume only as a candidate. Keep the active model unchanged while accepted bytes are appended. Order file writes and state checkpoints deliberately, and make cancellation, low storage, and network loss leave an explicitly recoverable or safely restartable candidate.
5. Verify before promotion. Check the complete expected length and any trusted digest, then test runtime loading. If the configured expected digest is absent, state that limitation and do not call length or rename a cryptographic integrity check.
6. Inject restart points. Simulate abrupt restart after scheduling, before and after file writes, between file sync and state persistence, after final bytes, during verification, and during promotion. Compare each observed outcome with the documented recovery state on supported storage.

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

Acceptance criteria

• Bytes are appended only when the response offset, artifact identity, and representation metadata match the accepted partial file.
• A completed-looking work row or expected filename alone cannot make a model verified or ready.
• Uncertain or mismatched candidate bytes cannot replace the known-good artifact, and model cleanup never touches user content.
• When no trusted digest is configured, user-facing copy and diagnostics do not claim cryptographic hash verification.

Decision table

Failure patterns to prevent

• Trusting the worker database alone
• Appending bytes before validating response range

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 persistent background work
• HTTP Semantics: Range Requests
• Android FileDescriptor.sync

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

Frequently asked questions