OK so the good news is your GPU is being used (OpenCL with Adreno-optimized kernels). The bad news is 0.8 tok/s is way too slow even for an unoptimized path — that points to something more fundamental than just "OpenCL vs Vulkan."

Check your thread count first. Run with -t 4 or -t 6 explicitly. In Termux, llama.cpp might default to 1 thread which would explain the CPU-bound bottleneck. On an S23 (Snapdragon 8 Gen 2) with 1 performance core + 4 mid cores, -t 4 targeting the mid cores is usually the sweet spot.

The Google app gap is expected though — it's a completely different execution stack. Google's demo app uses LiteRT (formerly TFLite) with a purpose-built GPU delegate for Adreno. The model isn't even in GGUF format — it's converted to a mobile-optimized representation with INT4 quantization specifically tuned for mobile GPU memory layouts. That's why their GPU path hits 1116 tok/s prefill — it's doing INT4 matmuls directly on the GPU shader cores with zero CPU-GPU copy overhead.

llama.cpp's OpenCL backend is more general-purpose. It wasn't built specifically for Adreno, so there's likely a lot of memory transfer overhead between CPU and GPU that Google's stack avoids entirely.

Realistically, for phone inference, I'd expect llama.cpp via OpenCL/Adreno to land somewhere in the 5-15 tok/s decode range once you fix the thread count issue — not matching Google's 31 tok/s GPU path, but much better than 0.8. If you're still stuck at <2 tok/s after fixing threads, check if your build has ARM NEON enabled (-DGGML_CPU_AARCH64=ON) — without NEON, you're leaving all the SIMD performance on the table.