Direct answer
A model-load failure is a stage label that needs more detail. First determine whether the application can locate and read the configured file, whether the file is the format expected by the selected runtime, whether the native library is packaged and loadable for the installed ABI, and whether engine initialization reached completion. A successful file check does not prove that the container is valid; an initialized native library does not prove that the model loaded; a load error is not the same as an inference task returning an error. Record each transition and the first failing boundary. For LiteRT-LM, use the official Kotlin guide for its Android package, EngineConfig, initialization, and resource close behavior. Do not treat GGUF, TensorFlow Lite flatbuffer, or a file with a familiar model-family name as an interchangeable LiteRT-LM artifact. Keep a trusted artifact revision and format record; if the configuration lacks a digest, state that the hash is unavailable. The current Cove Gemma 4 E2B SHA-256 field is empty, so the site must not describe its configured artifact as hash-verified. That fact does not by itself explain any specific load failure. Classify failures by point in the sequence: path not found or permission denied; incomplete or unexpected container; native library load/link error; engine initialization exception; model-specific capability/operation error; or failure after a task begins. Preserve the complete redacted exception type and stage. Native errors may indicate an absent library or dependency problem; inspect installed package contents and ABI before changing model assets. If the engine initialized and a task then fails, follow the narrower task/runtime diagnostic instead of repeatedly re-running a load procedure. Before any destructive cleanup, record artifact identity and determine whether the failure indicates corrupt bytes, a missing library, or a runtime stage unrelated to the file. If the application removes a candidate after a load error, document that policy and ensure retry has an explicit asset-recovery path; do not assume every runtime or manager behaves the same way. Use a fixed artifact and small known task after load succeeds. Validate initialization, conversation creation, a representative request, output parsing, and close separately. Keep sensitive input out of logs. A report should identify device and OS only for tested runs and should not become a device compatibility or performance statement. The project has no complete benchmark dataset; this page provides a fault-isolation sequence and not a guaranteed recovery recipe.
Engine initialization fails after the model file appears downloaded
An Android application reports that the model is present, then the native engine throws during startup. The team is considering deleting the file, although it has not distinguished a format problem from ABI packaging or runtime initialization.
Decision
Record file identity and failure stage, verify access and installed native libraries independently, then retry only after a classified repair.
Expected outcome
Support can distinguish artifact delivery from runtime loading and task execution, avoiding repeated downloads when the issue is elsewhere.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Exact artifact digest
- Runtime and backend logs
- CPU fallback result
A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.
Implementation workflow
- Capture the configured artifact and install identity. Record model path, source/revision, declared container format, trusted length/digest if present, app build, runtime version, device ABI, and OS. Mark a missing digest as unavailable; do not use filename as integrity proof.
- Verify file access and container expectation. Check that the installed app can read the exact file and that the selected runtime documentation expects that format. Separate missing, permission, partial, and parse/container outcomes.
- Inspect native package loading. For a native load/link error, inspect the installed APK or split set and dependencies for the device ABI. Do not infer packaged libraries from a source checkout or a different debug artifact.
- Separate engine initialization from task execution. Record whether Engine initialization completed, whether a conversation was created, and whether the failure began only after sending a fixture. Preserve each exception stage and do not call a task failure a model-load failure.
- Repair only the classified boundary. Redownload only when evidence points to missing or corrupt artifact bytes. Fix package/ABI or runtime configuration when those are implicated, then rerun load and a known task separately. Retain redacted error evidence and a bounded retry policy.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Artifact presence, container parse, native library load, engine initialization, and inference task completion are separately recorded.
- The current empty Cove digest field is not presented as proof of artifact integrity or as the proven cause of failure.
- A destructive cleanup or redownload follows a classified artifact problem, not a generic exception.
- Recovery claims are scoped to the tested build, ABI, runtime, artifact, and task; no universal compatibility result is inferred.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| File missing or unreadable | Repair delivery/path/permission boundary | The runtime may not have received bytes; changing backend or prompt is premature. |
| Native library or ABI error | Inspect installed package and dependency linkage | The model file may be intact while runtime code cannot load. |
| Engine loaded, task failed | Move to operation/task/parser diagnostics | Re-running file download does not address a later inference stage by itself. |
Failure patterns to prevent
- Redownloading without classifying failure
- Calling every load error low memory
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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
- Google LiteRT overview
- LiteRT-LM official Kotlin Engine initialization guide
- Android NDK native library and JNI debugging guide
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
If a progress screen says downloaded, is the model load guaranteed?
No. Download state, file readability, container format, native library loading, engine initialization, and task execution are separate checks. Each stage needs its own result; record the install artifact separately from initialization.
Should every initialization exception trigger a redownload?
No. First classify file access, container, native dependency, ABI, and runtime stages. Redownload only when evidence points to missing or corrupt bytes; preserve the original error to avoid repeating unrelated delivery work.
Does Cove currently have a verified SHA-256 for its configured Gemma artifact?
The current fact card says that SHA-256 field is empty. Do not claim the configured artifact hash is verified or use the missing field as proof of a specific failure; check the fact record and preserve the digest as unavailable.