Your local AI harness for Android. Run and manage local LLMs once, then expose them to Android apps through one controlled boundary.
WHY HARNEX
The goal is not another llama.cpp wrapper. It is a governed Android runtime that keeps product code separate from model, trust and lifecycle concerns.
Model selection, residency, sessions, generation and cleanup live in Harnex instead of being reimplemented per app.
Access is authorized from caller UID, package and signing identity, not from what a client claims to be.
Latency, TTFT, throughput, memory, thermal state and inference Activity are part of the system, not an afterthought.
WHAT WORKS TODAY
The shared runtime, cross-app boundary and engineering control plane are already integrated on the current development line.
Consumer apps use the versioned SDK and Binder instead of embedding the native inference stack themselves.
Authorization starts from Binder UID, installed package and signer, then applies Harnex policy and enabled use cases.
Accepted inference can be inspected through a durable, encrypted local audit trail without leaking content into normal telemetry.
Models, applications, use cases, runtime state, performance, diagnostics and Activity stay visible in one engineering console.
One console to operate and inspect the shared runtime.
ARCHITECTURE
Consumer app → Consumer Android SDK → Binder → Harnex control plane/runtime → backend-neutral SPI → llama.cpp → local GGUF. Model storage, observability, evaluation and inference Activity stay Harnex-owned around that execution path.
Four boundaries are enough to understand the system.
Owns the product workflow, UI state and application data.
Owns the typed contract, transport and caller boundary between the app and Harnex.
Owns identity, authorization, model policy, residency, lifecycle, scheduling and inference audit.
Owns local execution. llama.cpp is the current backend, not the architecture.
The runtime core keeps policy and lifecycle separate from the execution engine through a backend-neutral boundary.
HOW APPS CONNECT
Add the Consumer Android SDK and call Harnex over Binder. The app owns the workflow; Harnex keeps model selection, residency and execution lifecycle behind the boundary.
The consumer owns UI, product state and application data.
Typed contracts cross the Binder boundary without exposing Harnex internals.
Authorization, model policy, residency, lifecycle and audit stay host-owned.
implementation("io.github.daniele21.localllm:consumer-android:<version>")
val job = client.submitLogicalGeneration(
ConsumerLogicalJobSubmitRequest(
clientRequestId = ConsumerLogicalJobRequestId("analysis-42"),
useCaseId = prepared.useCaseId,
preparedId = prepared.preparedId,
expectedExecution = prepared.toExecutionIdentity(),
input = ConsumerGenerationInput.Text(input),
),
)Scroll to inspect code
EVIDENCE
The shared runtime and cross-app boundary are real. Physical-device and release evidence remain separate gates for stronger production claims.
EVIDENCE BOUNDARY
Keep implementation and release evidence separate.
Harnex already has meaningful cross-application evidence. The remaining gap is representative real-device and release validation, not the core architecture.
Supported today
Not claimed here
STATUS
The shared runtime, SDK, control plane and cross-app trust boundary are implemented. The next confidence step is representative hardware and release evidence.
CURRENT DECISION
Architecture stable. Evidence hardening next.
Keep the host/Consumer boundary stable and close the remaining physical-device, Play identity, OEM and selected release gates.
CONNECTED SYSTEM
Harnex is the Android infrastructure experiment behind a simple question: can Local AI become a shared capability instead of a native stack rebuilt inside every app?