Validate Android NPU Support Without Guessing

Direct answer

NPU verification is a test of a complete model-runtime-device path, not a lookup of a phone’s marketing specification. First identify the runtime and delegate that can request an NPU path, then record the exact model artifact and operation set, test initialization and execution on the target configuration, and preserve evidence of the backend actually used or the fallback that occurred. A device can contain an NPU while a particular model, runtime, operation, driver, or delegate combination does not execute there. Conversely, the presence of a library dependency or a successful task result does not prove which processor performed the work. Keep four claims separate: hardware presence, runtime path exposed by the framework, delegation coverage for the graph, and observed execution for a recorded workload. Vendor delegates are often tied to vendor runtimes and support constraints. The official LiteRT NPU overview describes vendor-specific delegate paths; that documentation is not a universal list of supported phones or every model operation. LiteRT-LM’s current guide exposes backend configuration, but configuration is only an input to a run. Treat unsupported operations, delegate initialization errors, model conversion constraints, driver failures, and silent or explicit fallback as data, not as reasons to rewrite the test as “NPU supported.” A useful test begins by pinning the model file and runtime, recording OS build and device identity, and capturing the model’s input and output contract. Make a CPU or other known path an explicitly labeled comparison only if the same artifact and task can run there. Then request the NPU path, run the same deterministic fixture, and collect runtime logs or diagnostics that actually identify the selected backend. If the library does not expose reliable backend confirmation, record that limitation and describe the path as “NPU requested; execution unconfirmed.” Do not infer execution from faster output, lower battery use, a device family, or a UI setting. The test should separate delegate creation, model load, first invocation, repeated invocation, and close. Backend setup can fail before inference, while individual operations may fall back or remain on another delegate. Record whether the run completed, which outputs passed the same acceptance criteria, and what fallback occurred. If the only successful outcome is a CPU fallback, the task may still work, but it is not an NPU result. If the task fails, keep the failure in the evidence set; do not remove unsupported operator cases from the denominator without explaining the scope change. Do not publish named-phone compatibility claims without a device-specific evidence record. Do not translate benchmark numbers from a vendor sample into Cove performance. NPU availability and actual product behavior can change with the library, model, operating system, driver, and artifact. A responsible summary says which exact combination was tested, whether backend execution was explicitly observed, which workload ran, and what remains unknown. Use this verification sequence: 1. Freeze the configuration: device model, OS build, runtime and delegate versions, artifact revision, conversion settings if any, backend request, and workload revision. Keep a copy of the model metadata and checksum where policy allows. 2. Validate the graph contract: list required operations, shapes, data types, and preprocessing. Check the delegate’s official documentation for supported formats and restrictions; do not infer coverage from a product family name. 3. Run one path at a time: initialize the selected delegate, load the exact artifact, invoke a fixed sample, and record initialization, execution, fallback, and output acceptance separately. 4. Repeat and close: execute the same workload more than once, test cancellation or error cleanup, then close the interpreter or engine. Preserve both successful and failed attempts. 5. Write the conclusion at the narrowest scope: state “requested,” “observed,” or “not confirmed” for backend use and identify the exact device/runtime/artifact; leave every unmeasured device unclassified. This method prevents a capability label from turning into an unsupported speed or compatibility promise.

A delegate flag does not settle the NPU question

A team enables an accelerator option in an Android build and sees one successful inference on a recent handset. The runtime does not clearly report the selected backend, and the team has not tested unsupported operations, fallback, or another device.

Decision

Run a pinned, backend-specific test and record execution as unconfirmed unless the runtime provides reliable evidence. Keep marketing claims out of the result.

Expected outcome

The team knows whether the particular workload completed, what backend evidence exists, and which additional configurations remain unknown.

Evidence to collect

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

• Observed backend evidence
• Unsupported-operation behavior
• Fallback record

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

Implementation workflow

1. Freeze artifact, device, and runtime. Record exact device model, OS build, model revision, input contract, runtime and delegate version, conversion settings, and requested backend. A model-family name or device name alone is not a test configuration.
2. Check official operation coverage. Compare required graph operations, data types, shapes, and preprocessing to the chosen vendor delegate documentation. Separate a documented hardware path from proof that every operation in this graph is covered.
3. Collect backend and fallback evidence. Run a fixed fixture and capture initialization, load, first invocation, repeated invocation, output acceptance, delegate diagnostics, and fallback. If the runtime cannot confirm execution, preserve that uncertainty explicitly.
4. Repeat, close, and scope the conclusion. Repeat the same workload, exercise cancellation and cleanup, close the engine, and then state only the recorded configuration. A CPU fallback may be a valid product path, but it is not proof of NPU execution.

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

Acceptance criteria

• The record contains artifact, runtime, delegate, device, OS, and workload identity.
• Backend use is labeled requested, observed, or unconfirmed based on runtime evidence, not inference speed or handset branding.
• Fallback and failed runs remain visible and do not become a universal device-support verdict.

Decision table

Failure patterns to prevent

• Assuming an NPU runs every model
• Publishing TOPS as product latency

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
• Gemma run guide
• Google AI Edge LiteRT delegate for NPUs
• Google AI for Developers Gemma run guide
• Google AI Edge LiteRT-LM Kotlin API

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

Frequently asked questions