Standalone Android app for TurboLLM: install, open, chat — no Termux, no pkg install,
no visible terminal. WebView shell + an embedded Node runtime (nodejs-mobile) + the same
daemon and NDK-cross-compiled llama-server already proven working end-to-end on a real
phone in the main repo's R&D session (2026-09).
Built as Kotlin Multiplatform + Compose Multiplatform (composeApp/), not plain
Android, so an iOS target can be added later without restructuring — see
BLUEPRINT.md §0 ("Kotlin Multiplatform, for future iOS"). iOS itself is
not implemented — only the module shape is ready for it.
Spike A passed (BLUEPRINT.md §4) — built, installed on a real emulator, and verified
live: the embedded nodejs-mobile runtime boots and its HTTP server on :6996 answers
real requests (spike-a-emulator-screenshot.png). The vendored nodejs-mobile binaries it
links against have their provenance documented (what's confirmed vs. not) in
PROVENANCE.md.
This folder is intentionally gitignored in the main llama-turbo repo — it's going to
become its own git repository (git init already done here) so the Android app has a
clean, independent history separate from the daemon/desktop product repo. Copy or clone
this folder out wherever the standalone app work should actually live; the daemon and
llama-server binary it depends on are consumed as external artifacts (npm-published
turbollm build output + a Hugging Face-hosted binary), not vendored source.
Read BLUEPRINT.md — the full end-to-end step-by-step plan, phased, with an explicit spike list (Phase 0) before any real app code gets written. Nothing here has been executed yet; this is the plan for a new chat to work through, spike by spike, phase by phase.
This plan is the direct continuation of R&D done in the main repo (not duplicated here in full — see the main repo for the underlying evidence):
docs/decisions/decision-log.md— ADR-390 (guided Termux build), ADR-391 (NDK cross-compile + hosting), ADR-395 (live end-to-end verification on a real phone: daemon boots, engine loads, real inference, real UI render).docs/specs/28-android-native-app.md— the original standalone-app design (Termux-fork shell). Superseded by this plan's approach (nodejs-mobileinstead of forking Termux) — see BLUEPRINT.md §0 for why.turbollm/src/engines/{download.ts,catalog.ts,compat.ts,build-runner.ts,probe.ts}— the real, shipped Android platform support (Termux-path) this plan reuses pieces of (the NDK build recipe, theprobe.tsLD_LIBRARY_PATHfix, the catalog Android entry)..github/workflows/android-llama-build.yml— the CI recipe for the NDK cross-compile; this plan runs the same commands locally in WSL instead (founder direction: no CI for now).
This repo does not vendor turbollm's source. It's a separate product repo, consumed
as an external dependency (build output bundled into the APK's assets, per BLUEPRINT.md
§7) — a fresh chat working only inside this repo needs to be pointed at it explicitly:
- Read/edit it directly on disk at
D:\llama-turbo(branchmain) — that's the real, already-checked-out working copy on this machine. Don't clone a fresh copy ofmohitsoni48/TurboLLM(private) into this folder or anywhere else; there is exactly one checkout to work from. - Node version:
turbollm/package.json'senginesfield pins>=22.13.0— this is the floor Spike B (BLUEPRINT.md §4) checks the embeddednodejs-mobileruntime against. - Status as of 2026-09-03: the Android platform support this blueprint builds on
(ADR-390/391 —
download.ts's Android backend resolution, the NDK-cross-compile CI workflow, theprobe.tsfix, the catalog entry) is merged intoD:\llama-turbo'smainalready (PR #203, merge commitb54a370) — nothing further to fetch before starting a spike that touchesturbollm/src/engines/. - Files BLUEPRINT.md names directly:
turbollm/src/engines/download.ts(§3.2'savailableBackends()/provisionBackend()change),turbollm/src/hf/hf.ts(the existingfileUrl()HF client §3.2 reuses),turbollm/src/engines/{catalog,compat, probe,build-runner,build-prereqs}.ts(already-shipped Android support, §7 reuses as-is),turbollm/package.json(thenode-pty/node:sqlitedependencies behind Spike C/D's risk).