QNN HTP fails to initialize on Snapdragon 8 Elite (SM8750P) — native “No Snapdragon SOC detected” / transport error 4000, reproduced across two independent frameworks

[ivaylo681-dev]

Hello!
I am opening a new topic as the one that I added my question at the end probaly would not be checked as it has been marked as closed 4 days before my question.
#16465
The failure that I have is with identical failure signature as the topic above(QnnDsp: No Snapdragon SOC detected → error 4000), but on a different sun-platform device (my soc_id=639 confirmed via /sys/devices/soc0/soc_id).
In the thread that I have found @INHA-SW has replied that the issue for soc_id=705 will be fixed in qnn-runtime 2.43.0. I am already with the newest version 2.48.0, but as my soc is different version of 7850 seems the problem is not solved for it.
Adding here the full description and I will be really gratefull for any help!

Summary

On a Snapdragon 8 Elite (SM8750P) Android device, the Hexagon HTP backend fails to initialize via QNN, regardless of which framework or SDK version is used to reach it. The failure occurs deep inside Qualcomm’s native QNN libraries — at DSP SoC-detection / transport-initialization — not in any application-level or third-party framework code. This has been reproduced identically through two independent, unrelated frameworks (ONNX Runtime’s QNN Execution Provider, and TensorFlow Lite’s QNN delegate), both calling into the same underlying QAIRT native libraries, both failing at the same point with the same error codes.

Device

• SoC model: SM8750P (adb shell getprop ro.soc.model)

• Board platform: sun (adb shell getprop ro.board.platform)

• Hardware: qcom

• OS: Android 16, MIUI/HyperOS (Xiaomi)

• Native QNN libs present on device (confirmed via run-as ls -la on installed APK): libQnnHtp.so, libQnnHtpV68/V69/V73/V75/V79/V81Skel.so + matching Stub.so, libQnnSystem.so — all present, correctly loaded (confirmed via nativeloader log: Load .../libqnn_delegate_jni.so ... ok)

Reproduction 1 — ONNX Runtime QNN Execution Provider

Using onnxruntime-android-qnn (tested versions 1.27.0 and 1.28.0, identical result on both):

val qnnOptions = OrtSession.SessionOptions().apply {

addQnn(mapOf(

"backend_path" to "libQnnHtp.so",

"profiling_level" to "detailed"

))

}

createdSession = ortEnv!!.createSession(modelBytes, qnnOptions)

Result — session creation does not throw, but GetCapability() silently assigns 100% of graph nodes to CPU:

W onnxruntime: [qnn_backend_manager.cc:1680 SetupBackend] Failed to setup so cleaning up

E onnxruntime: [qnn_execution_provider.cc:1046 GetCapability] QNN SetupBackend failed Failed to create device. Error: QNN_DEVICE_ERROR_INVALID_CONFIG: Invalid config values

Confirmed via enableProfiling() trace inspection: every node across multiple full inference passes shows "provider": "CPUExecutionProvider"; zero occurrences of “QNN” in the raw trace JSON.

Reproduction 2 — TensorFlow Lite QNN delegate (independent framework, same device, same app process)

Using com.qualcomm.qti:qnn-litert-delegate:

val options = QnnDelegate.Options()

options.setBackendType(QnnDelegate.Options.BackendType.HTP_BACKEND)

options.setSkelLibraryDir(context.applicationInfo.nativeLibraryDir)

val qnnDelegate = QnnDelegate(options)

val tfliteOptions = Interpreter.Options().apply { addDelegate(qnnDelegate) }

val interpreter = Interpreter(tfliteModel, tfliteOptions)

Result — this surfaces the real native failure, at the QnnDsp layer, independent of ORT entirely:

E QnnDsp: QnnDsp loadRemoteSymbols failed with err 4000

E QnnDsp: QnnDsp Failed to create transport for device, error: 4000

E QnnDsp: QnnDsp Failed to load skel, error: 4000

E QnnDsp: QnnDsp Transport layer setup failed: 14001

E QnnDsp: QnnDsp Failed to parse default platform info: 14001

E QnnDsp: QnnDsp Failed to load default platform info: 14001

E QnnDsp: QnnDsp Failed to parse platform config: 14001

This is a native-level failure inside libQnnHtp.so / the skel loading path — not a Java/Kotlin exception, not framework-specific code. Two different frameworks, two different SDK entry points, same underlying native failure.

Matches a known, previously-reported issue on the same platform

This closely matches #16465 (“QNN HTP init fails on CQ8750S (soc_id=705): ‘No Snapdragon SOC detected’”), filed against the same ro.board.platform=sun device family and already labeled partner: qualcomm by the ExecuTorch maintainers. That issue’s log shows the same error code surfacing at a slightly earlier stage of initialization:

QnnDsp No Snapdragon SOC detected

QnnDsp No Snapdragon SOC detected

QnnDsp Failed to init router

QnnDsp failed sg_htpSingletonProvider initialize: 4000

Same error code (4000), same platform family, consistent with a SoC-identification failure early in QNN’s device-detection path that cascades into transport/skel-load failure. My device reports a clean ro.soc.model=SM8750P (not the garbled CQ8750S string in that report), so this may be a related but distinct SoC-ID/SKU variant not recognized by the current QAIRT SoC lookup table.

Ruled out (not the cause)

Exhaustively tested and eliminated before concluding this is an SDK-level issue:

Variable

Tested

Result

htp_arch provider option

unset, 81, 79 (invalid — not in ORT enum), 69

No change

soc_model provider option

69

No change

Model precision

fp32, native fp16

No change — fails before model is evaluated

onnxruntime-android-qnn version

1.27.0, 1.28.0

Identical failure both versions

qnn-runtime native library version

bundled vs. explicit override to 2.48.0 (confirmed via file-size diff on installed APK: 2,642,248 ? 3,760,632 bytes — genuinely a different binary)

No change

Manual ADSP_LIBRARY_PATH override

present vs. removed entirely

No change

vtcm_mb config

unset vs. 8

No change

Op-level HTP support

checked all model ops against published QNN operator table — all supported

Not the cause; failure occurs before op-level partitioning

App-level DSP device-node permissions (disproven as the cause, included for completeness)

Initially suspected the app’s read-only access to /dev/fastrpc-cdsp (owner/group system:system) as the cause. This is disproven: a third-party benchmarking app (Geekbench AI), running with no elevated privileges, achieves genuine HTP acceleration on this exact device via its own TFLite QNN backend — confirmed via a large FP16/INT8 score differential versus its NNAPI backend on the same device (QNN: 21,627/55,112 vs. NNAPI: 485/1,111 for half-precision/quantized workloads respectively) — https://browser.geekbench.com/ai/v1/542278. This proves third-party app-level HTP access is possible on this device in principle. I do not know what QAIRT/QNN SDK version Geekbench bundles; it’s possible they have a vendor-provided or newer build with correct SoC recognition for this chip that isn’t yet available via the public qnn-runtime Maven releases I tested (through 2.48.0).