Rust on Termux: What Works and What Kills Your Build

You can run Rust on Termux, but not the way the official docs tell you to. rustup refuses to install, because aarch64-linux-android is not a supported host triple and the stable channel has no binaries for it. The route that works is Termux's own package: pkg install rust. That package is not the outdated thing the forums claim, either. It tracked upstream at 1.97.1 when we checked on 2026-07-21. The thing that actually defeats people is not the toolchain version. It is the compile.

This guide was written by the Cosyra team. We build a mobile cloud development environment, so we have a stake in the last section, and we have tried to be direct about where our answer does not apply. Every claim below is checked against a primary source on 2026-07-21: the Termux package recipes on GitHub, the rustup issue tracker, and the proot-distro README. Where we give a number, we measured it ourselves rather than repeating it.

Why rustup does not work on Termux

Rust distinguishes between a target (the platform you are building for) and a host (the platform the compiler itself runs on). Android is a well supported target. Android is not a supported host.

So when you pipe sh.rustup.rs into a shell inside Termux, the installer detects your triple as aarch64-linux-android, queries the stable channel for a matching toolchain, and finds nothing:

On a 32-bit device the triple changes and the message reads armv7-linux-androideabi instead, but the cause is identical. Both reports are on the rustup tracker and both are closed. The 64-bit one was closed as not planned and tagged not-rustup, a label whose description reads: "Whatever is described in this issue isn't Rustup's fault." That is the maintainers saying this is a distribution question rather than a bug they intend to fix. Read them at rustup issue #2872 and issue #3420.

This trips people up because every Rust tutorial on the internet opens with the rustup one-liner. On Termux it is the one command guaranteed not to work, and the error text does not explain why.

What does work: pkg install rust

Two commands, no root, no workaround:

Termux maintains its own build of the compiler, linked against Android's Bionic libc rather than glibc, which is exactly why it works where the upstream binaries do not. The package pulls in clang, lld, openssl and LLVM as dependencies, so a fair amount arrives with it.

Now the correction. The single most repeated claim about Rust on Termux is that the packaged version is too old to be useful. The Rust user forum thread that surfaces first for this question opens with exactly that complaint: "Install from pkg install rust can works, but the version is too low." That thread is old, and the advice outlived the condition it described.

We read the package recipe on 2026-07-21. It pins TERMUX_PKG_VERSION="1.97.1", and it sets TERMUX_PKG_AUTO_UPDATE=true, so it follows upstream releases automatically rather than waiting for a maintainer to notice. In the same session, rustup in an ordinary x86_64 Linux container gave us rustc 1.97.1. Identical. You can check the recipe yourself at termux-packages/packages/rust.

If you skipped Termux's Rust because a 2020 forum post said it was stale, that reason is gone. Test the real constraint instead of the remembered one.

The real ceiling is the build, not the version

Here is where people actually get stuck, and it has nothing to do with Rust. You start a release build, put the phone in your pocket, walk to the platform, pull it out again, and find this:

That is Android's phantom process killer. The Termux README carries a standing notice about it: Android will kill any phantom processes beyond 32, and will kill processes using excessive CPU. A Rust release build is close to the worst possible case for that policy, because cargo spawns a separate rustc per crate in parallel and then holds the CPU pinned for minutes at a stretch. A Node install or a Python script slips under the threshold. A dependency graph of 200 crates does not.

On Android 14 and later there is a real fix: Developer Options, then Disable child process restrictions. On earlier versions it takes an ADB command or root. We wrote the full procedure up separately in fixing the Termux signal 9 error, because it affects far more than Rust.

The second constraint is thermal, and no setting fixes it. Sustained all-core compilation is the workload phones are least equipped to hold. A laptop fan spins up; a phone has nowhere to move the heat, so the governor reduces clocks and the build stretches. Our ripgrep build consumed 2 minutes 50 seconds of CPU time. On a machine that can hold ten cores at full clock that landed in 30 seconds of wall time. On silicon that throttles after 90 seconds, the same work takes far longer than the core count would suggest.

The proot-distro route, and what it costs

Some crates will still refuse to build. Anything whose build script assumes glibc, or that links a precompiled native library, can fail against Bionic. The standard answer, and the one the Rust forum thread converges on, is to run a real Linux userland inside Termux with proot-distro. Install Ubuntu or Debian, and inside it rustup works normally, because the host triple is now ordinary Linux.

This genuinely solves the compatibility problem. It is worth being clear about the bill, and the project states it plainly in its own README:

"proot intercepts every system call via ptrace. Filesystem-heavy workloads (compilation, package managers) are noticeably slower than native execution."

Compilation is named in that sentence, and Rust compilation is filesystem heavy in the specific way that hurts most: thousands of small reads and writes across the crate graph and the incremental cache, each one now routed through ptrace. You are trading speed for correctness on a workload where speed was already the binding constraint.

Use it when a specific crate refuses to build natively. It is a poor default for everyday work.

Cross-compiling from a desktop

If what you need is a finished binary running in Termux, rather than a development loop on the phone, cross-compilation is the mature path. On a desktop:

You also need .cargo/config.toml pointing the linker for that target at the matching Android NDK toolchain, which is the step most write-ups spend their length on. A worked example covering arm64, arm and x86 is at How to compile Rust command line tools for Termux.

The catch is structural rather than technical. Cross-compiling means the desktop has to be present for every code change. If your reason for being on the phone was that the desktop was at home, you have solved a different problem than the one you have.

Skip the phone's CPU entirely

Here is the opinion we hold that the Termux community would push back on. We think compiling Rust on the phone's own silicon is the wrong goal. The culture around on-device Linux treats native compilation as the win condition, and there is real craft in it. But the thing you wanted was the binary, and the tests passing, and the commit pushed. Which CPU did the work is an implementation detail, and choosing the most thermally constrained processor you own to do the most sustained-load task in your workflow is a strange place to plant a flag.

That is the reasoning behind what we build. Cosyra gives you a persistent Ubuntu 24.04 x86_64 container on Azure AKS, reached from a native iOS or Android app. We do not pre-install Rust, so you run the same rustup one-liner that fails on Termux. There it works, for the ordinary reason: the host triple is x86_64-unknown-linux-gnu, so you are not asking an unsupported platform to host a compiler. That is the environment our measurements above came from, and the install took under ten seconds.

The practical difference is what happens when you lock the phone. A cargo build in Termux is subject to Android's process policy the moment your screen goes dark. A build running in a container keeps going, because nothing about it depends on your handset staying awake. We do most of our own long builds this way from a train seat, where the phone is a terminal and the compile is happening several hundred miles away.

Where this does not apply: if you are writing something that has to run on Android and touch device hardware, a cloud x86_64 container is the wrong tool and Termux is the right one. Same if you are offline regularly, since a container needs a connection. Termux is genuinely excellent software and we have said so at length in Cosyra vs Termux.

The four paths compared

Which one should you pick

• Pick Termux's rust package if you are writing small tools, learning the language, or building something that has to run on the Android device itself. Turn off child process restrictions first.
• Pick proot-distro if one specific crate will not compile against Bionic and you need it. Do not adopt it as your everyday environment; the syscall overhead lands hardest on exactly the workload you are running.
• Pick cross-compilation if you want a binary to ship into Termux and you already have a desktop in the loop.
• Pick a cloud container if the build is long, the crate graph is large, or you want the compile to survive your screen turning off. Compare the options in the mobile coding terminal guide, and see pricing for what a paid tier includes.

Rust is a harder case than most languages here, which is why the advice differs from what we say about lighter toolchains. If you came to this from another direction, we covered Node.js on a phone and Docker on Termux separately, and the constraints are not the same in either case.

Frequently asked questions