SKaiNET engine 0.39.0 ships a new Android backend, sk.ainet.core:skainet-backend-jni-cpu (an AAR with NEON kernels for Q8_0 / Q4_0 / Q4_K / Q5_K / Q6_K, runtime dotprod dispatch, and ServiceLoader self-registration on ART). Measured on a Pixel 8a, it lifts SmolLM2-135M Q8_0 decode-kernel throughput from ~3.8 to ~24 tok/s — the difference between "AI off" and "usable" for the on-device use case in SKaiNET#920.
SKaiNET-transformers develop already pins engine 0.39.0, but nothing in this repo depends on the new AAR. An Android app that depends on skainet-transformers-runtime-kllama (or -kgemma) therefore still silently falls back to the scalar Kotlin matmul unless the app author independently discovers the backend artifact and adds it themselves — exactly the silent-slow-path failure mode the mobile field report complained about.
Proposal:
- Add
sk.ainet.core:skainet-backend-jni-cpu as a runtimeOnly dependency of the androidMain source set in llm-runtime/kllama and llm-runtime/kgemma. The backend is ServiceLoader-discovered, so being on the runtime classpath is all it needs; there is no compile-time API surface to expose. The engine BOM (re-exported by :llm-bom) already carries the 0.39.0 version constraint.
- Note in the README target matrix that Android gets native NEON kernels through the runtime facades out of the box, and that apps driving
inference-llama + transformer-core directly (the documented iOS-style path) should add the AAR explicitly.
Cost: the AAR adds four small .so files (two ABIs × two dispatch tiers) to consuming apps. Apps that want to opt out can exclude the artifact.
SKaiNET engine 0.39.0 ships a new Android backend,
sk.ainet.core:skainet-backend-jni-cpu(an AAR with NEON kernels for Q8_0 / Q4_0 / Q4_K / Q5_K / Q6_K, runtime dotprod dispatch, and ServiceLoader self-registration on ART). Measured on a Pixel 8a, it lifts SmolLM2-135M Q8_0 decode-kernel throughput from ~3.8 to ~24 tok/s — the difference between "AI off" and "usable" for the on-device use case in SKaiNET#920.SKaiNET-transformers
developalready pins engine 0.39.0, but nothing in this repo depends on the new AAR. An Android app that depends onskainet-transformers-runtime-kllama(or-kgemma) therefore still silently falls back to the scalar Kotlin matmul unless the app author independently discovers the backend artifact and adds it themselves — exactly the silent-slow-path failure mode the mobile field report complained about.Proposal:
sk.ainet.core:skainet-backend-jni-cpuas aruntimeOnlydependency of theandroidMainsource set inllm-runtime/kllamaandllm-runtime/kgemma. The backend is ServiceLoader-discovered, so being on the runtime classpath is all it needs; there is no compile-time API surface to expose. The engine BOM (re-exported by:llm-bom) already carries the 0.39.0 version constraint.inference-llama+transformer-coredirectly (the documented iOS-style path) should add the AAR explicitly.Cost: the AAR adds four small
.sofiles (two ABIs × two dispatch tiers) to consuming apps. Apps that want to opt out can exclude the artifact.