Unsupported Operation Errors in On-Device AI

Direct answer

Treat an unsupported-operation error as a specific boundary failure, not a synonym for “the phone cannot run this model.” Start with the exact error text and the operation or subgraph named by the runtime, if it provides one. Record the artifact identity, format, conversion provenance, runtime version, requested backend, and the stage where the failure occurred. A model converted for one runtime or delegated path can contain operations that another backend does not execute; a request for an accelerator is not evidence that it ran. Preserve the failed configuration before trying a fallback, or the original cause may be lost. Keep model container and delegate concepts separate. LiteRT-LM uses its own packaging and APIs; LiteRT converter documentation for TensorFlow operators applies to that conversion workflow and must not be copied blindly into a LiteRT-LM setup. If the error appears while opening an artifact, classify it as a format or load boundary first. If the container loads but an operation fails during execution, capture the operation, graph stage, and backend path. If initialization fails before a task begins, investigate the runtime or native-library setup separately. Do not add an unrelated dependency just because a similarly worded issue elsewhere mentioned it. Use a controlled reproduction: pin the artifact, input fixture, prompt, app build, runtime, and backend request; run once on the failing path and once on a documented diagnostic path only when that path is supported. Compare stages and outputs without calling a different backend equivalent. If CPU succeeds while another path reports an operation problem, that narrows the path-specific difference; it does not prove the accelerator is universally unsupported or that CPU is faster. If every path fails before inference, operation coverage may not be the cause. Write a recovery decision only after classifying the error. Options may include choosing a compatible artifact, using a supported execution path, rebuilding or reconverting through the documented toolchain, or returning a clear unsupported-state result. The application should not silently fall back while its UI continues to claim the requested backend. Do not publish an operator support list unless it is tied to a versioned artifact, runtime, backend, and real test evidence. The repository lacks a complete device benchmark dataset, so this page describes an error workflow and not model coverage or performance. The useful deliverable is an error record containing the raw redacted message, operation name when available, artifact and conversion identifiers, runtime and backend facts, task stage, recovery attempt, and outcome. Keep private prompts and generated text out of ordinary diagnostics. If the runtime hides the operation name, state that it was not observable instead of inferring it from a stack trace alone. That discipline separates a concrete unsupported operation from backend initialization, artifact corruption, JNI failure, tokenizer mismatch, and a task-level quality issue.

A converted model opens but fails on one execution path

A team imports a candidate model into an Android app. The container appears readable, but one backend path reports an unsupported operation during a fixed task. A second configuration has not yet been tested, and the team must avoid turning the first error into a broad compatibility statement.

Decision

Capture the exact operation, artifact/conversion identity, runtime, backend request, and failure stage, then compare only documented diagnostic paths with the same fixture.

Expected outcome

The team can tell whether the operation failure is path-specific or appears earlier in load, while keeping any recovery choice and public claim within observed evidence.

Evidence to collect

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

• Artifact and converter identity
• Runtime and backend diagnostics
• Fallback and task outcome

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

Implementation workflow

1. Preserve the first failure. Save a redacted copy of the exact error message, stack stage, app build, artifact reference, runtime revision, backend request, and fixed input identifier. Do not replace the model or change several settings before the original configuration is captured.
2. Locate the stage and operation. Determine whether the failure occurred while opening the container, initializing the engine, preparing a graph, or executing a task. Record an operation name only when the runtime explicitly provides it; a native frame or generic error is not enough to invent an operator diagnosis.
3. Verify the artifact and conversion path. Record source model, conversion tool and revision, output format, quantization or delegate-target metadata when present, and any trusted digest that actually exists. Keep LiteRT converter operator documentation separate from LiteRT-LM container assumptions.
4. Run a controlled comparison. Use the identical artifact and fixture with a documented diagnostic backend only if the artifact/runtime supports that path. Change one variable, preserve the original error, and compare load stage, task completion, and output assertions separately.
5. Choose a transparent recovery. Select a compatible documented artifact/path, rebuild through the applicable toolchain, or surface a classified unsupported state. If the app changes execution paths, show the observed path when known and never label a requested backend as the one that executed.

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

Acceptance criteria

• The record distinguishes container-open, engine-initialization, graph/operation, and task stages instead of grouping all failures as unsupported device.
• Artifact, conversion, runtime, backend request, and fixture identity are frozen for the reproduction.
• A fallback is an explicit, tested decision and does not silently change the backend shown to the user.
• Any public conclusion is limited to the exact tested artifact/runtime/path and does not invent a universal operator or device-support list.

Decision table

Failure patterns to prevent

• Guessing from chipset labels
• Hiding silent fallback

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

• Google LiteRT overview
• Cove benchmark method
• LiteRT-LM Kotlin API and runtime setup
• LiteRT Select TensorFlow operators conversion guide

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

Frequently asked questions