Termux Launcher

An Android home launcher that is a terminal. Install it, set it as your home app, and the screen you return to when you press Home is a Termux shell with panes, workspaces and an app drawer, instead of a grid of icons. GPL-3.0-only, Java, a fork of termux-app and termux-monet with the layout ideas taken from TEL — which is itself a termux-app fork, and has been dormant since 2021.

239★ / 17 forks / 3 open issues / 6 watchers, created 2026-01-30, last pushed 2026-08-31. Figures read 2026-09-01 from the GitHub API; the source was re-sent by the curator a week after the first read, and the re-read is recorded below rather than overwriting it. T1: the project's own repository and documentation.

First read 2026-08-25: 190★ / 14 forks / 2 open issues. +49 stars in seven days, a quarter again on top of what it had, on a project with no store listing and one distribution channel. Still under daily work — the last push was yesterday.

The author's own framing, in a warning box at the top of the README:

This project is entirely vibe-coded. I've been daily-driving it as a launcher on a Nothing Phone (2), and it has been stable so far, does not appear to have any noticeable impact on battery life, and uses about ~350 MB of RAM at idle (for reference, something like smart launcher uses about 250 on fresh install).

The wording moved between reads (2026-09-01). On 2026-08-25 that sentence ended at "it has been rock-solid so far" and claimed nothing measurable. It now says stable, adds no noticeable battery impact, and puts a number on memory: ~350 MB at idle against ~250 MB for Smart Launcher on a fresh install. Both readings are kept here. The claim got weaker in adjective and stronger in evidence, which is the direction this corpus almost never sees a first-party claim travel — and it is still one device, one user, with no stated method for either figure.

Three editions, and the one that overwrites Termux

The same source builds three APKs that differ only in Android package identity and in which package ecosystem they use.

The recommended build ships as com.termux, the official app's own package name. Android treats the package name as the app's identity, so installing this one removes official Termux from the device — the README says so plainly — and in exchange it inherits the upstream package repositories and stays compatible with the ecosystem a Termux user already has.

Nothing in the corpus has done this before. proton-wine-andrevto repackages Valve's work under its own name; tuios and omniwm compete for a job on their own identity. This fork reaches its users by occupying the identity of the project it forked, while a bold-type disclaimer says it is "not affiliated with, endorsed by, or supported by the official Termux project" and asks people not to file bugs upstream. Both things are true at once, and the disclaimer exists because the package name makes the confusion likely.

There is a practical consequence the README states from the other end: the companion apps must be this project's forks of Termux:API and Termux:Styling, because "official F-Droid add-ons will not pair with any edition." Termux add-ons pair by shared package family and signing key. The plain reading is that this fork signs with its own key — the README does not say so in those words, so treat it as inference — which is also why a device running official Termux cannot upgrade into this one in place. Android refuses a same-package install under a different key. Somebody switching has to uninstall first, and uninstalling an Android app takes its $HOME with it.

Control the platform hands over

The spoke's running question is who grants the control (compatibility-layer), and this source adds a position the corpus did not have.

• omniwm takes it — macOS accessibility and private APIs, against a vendor that never intended window management to be replaceable, and one point release from breaking.
• tuios needs nobody's permission because it draws inside a terminal rectangle its own process already owns.
• proot-distro works around the kernel, intercepting syscalls with ptrace so no privilege is required.
• Termux Launcher is simply given it. Android has always let any app declare itself the home screen, and the user picks. No entitlement, no interception, no fight.

That makes it the cheapest control position in the corpus and the most invasive result: it replaces the single most-used surface on the phone. The pattern the spoke keeps finding — that the surface decides the price, not the ambition — holds again, and here the surface was deliberately left open by the platform vendor. Android's launcher slot is the counter-example to every other entry: a locked-down platform that is not locked down in this one place.

Optional Shizuku integration sits beside it for the parts Android does not hand over — screen lock and privileged status helpers — which is the fence line drawn in the same source.

One channel, no store

Distribution is GitHub Releases APKs and nothing else. No f-droid, no Play listing, no package manager entry, so no automatic updates and no repository review; each new version is a manual download and a side-load.

Set against the rest of the corpus that is the far end of a scale. tuios sits in six channels because nobody polices terminal programs. anysoftkeyboard and termux treat f-droid as their real channel because the vendor store degrades them or won't have them. This project has neither route: an app whose entire purpose is to replace the home screen, distributed as a bare APK from a personal repository. The friction is real but it is self-imposed rather than platform-imposed, and the project is seven months old, which is the simplest explanation.

The README also offers a curl -fsSLO … && sh setup-launcher quick-start. It downloads the script before running it rather than piping straight into a shell, and it writes a timestamped .bak over anything it replaces. A reader can inspect the file before it runs and undo what it changed, which is more than most quick-starts of this shape offer.

A maintainer stopping on purpose

The VAJ edition is being deprecated, and the README says exactly why: it runs off "my manually maintained custom APT repo," which carries "only a small fraction of the Termux package set," and "keeping its crucial packages updated is no longer sustainable." The author's own conclusion — "packages that stop receiving security updates are a liability rather than a feature" — is followed by a written migration guide to the Nix edition covering home-directory backup, side-by-side install, restore, and replacing the APT packages from nixpkgs.

This is the first source here that speaks to open question 2 — what happens to a self-hosted or self-installed thing when the maintainer stops. It answers from the supply side rather than the user side, and the answer is that one person hit the limit of maintaining a distribution's worth of security updates alone, said so, and handed users a route out instead of going quiet. The Nix edition is what replaces the effort: pulling prebuilt packages from the official nixpkgs binary cache moves the packaging burden onto an ecosystem that already carries it.

That is a smaller finding than the question deserves — one edition of one project, and the maintainer is still here. What it is not is another abandonment story. Filed as evidence, not as an answer.

The migration is not happening at the speed the plan implies (re-read 2026-09-01). The deprecated edition is still being built. Release v0.2.38+hotfix1 went out on 2026-08-29 in all three flavours at the same minute, and three days later the asset download counts run 126 for the recommended Termux edition, 75 for the deprecated VAJ edition, and 23 for the Nix edition that is supposed to replace it. So the retiring build is being downloaded roughly three times as often as its successor, and the maintainer is still shipping it hotfixes rather than letting it lapse.

Read carefully, because these are downloads on one release over three days and not installs, not users, and not a trend. What they do establish is that announcing a migration and performing one are separate events, and that this maintainer is carrying both editions in the interval. For open question 2 that is the more useful half of the finding: the interesting cost is not the moment someone stops, it is the tail where they have said they will stop and have not yet.

An LLM runtime inside the home screen

The launcher ships on-device inference: a tai shell command, an OpenAI/Ollama-compatible localhost API for model management and completions, and two backends — Google's LiteRT and Alibaba's MNN. launcherctl launch starts Android apps from the shell, and the same local endpoint exposes app launching alongside the model routes.

The README's own caution: these backends are "highly experimental. Be mindful of your device's available RAM and processor capabilities."

Cross-spoke note. The inference machinery is ../llm-inference-wiki's subject — that spoke holds local-llm-stack and pages LiteRT already — and running agents on a phone through Termux is ../agentic-tooling-wiki's, where hermes-agent-termux covers the same platform from the agent side. Per this spoke's boundary, the application a person installs is here; the runtime and the agent belong there. Cross-link, don't duplicate.

What is not established

• The stability, battery and memory claims are one device. The author daily-drives it on a Nothing Phone (2). No second device, no report from anyone else, and no method behind the ~350 MB figure or the Smart Launcher comparison beside it. Re-checked 2026-09-01: still nothing from a second party, and the star count tripling into the hundreds has not produced a published report.
• "Entirely vibe-coded" is an assurance gap, not a bug report. The author discloses that the code is LLM-written and offers no testing or review story to sit beside it. This is a home launcher with a localhost HTTP API and, on the recommended edition, official Termux's package identity. Nothing in the corpus has been audited, but this is the first source where the maintainer's warning is about how the code was written.
• The signing-key inference is not stated in the source. The add-on pairing rule and the replacement behaviour imply it; nobody has written it down.
• AI-assisted app categorization in the drawer is listed as a feature with no account of where it runs — locally on the shipped backends or elsewhere. Unresolved from the README alone.
• Bus factor of one, seven months old, with 239★ and 6 watchers. There is no contributor base to lose yet, and the audience is growing faster than the project's assurance story is.

Related

foss-application · termux · tel-termux-expert-launcher · olauncher · proot-distro · tuios · omniwm · f-droid · compatibility-layer · anysoftkeyboard · proton-wine-andrevto · self-hosting · synthesis