Rust Takes Over Android Binder: 11,470 Lines of C Removed from Linux
The swap means future Binder security fixes are written in a language that catches a class of memory-corruption bugs at compile time, reducing the risk of use-after-free and buffer overflows in Android's IPC layer. It also signals that a mature Rust implementation can take over a core kernel subsystem without sacrificing performance or compatibility.
Android's Binder driver, the kernel mechanism that handles inter-process communication between apps and system services, is moving from C to Rust. The Linux 7.4 development cycle has merged a patch that deletes the 11,470-line C implementation and switches the kernel build to the Rust version. Google plans to focus all future Binder development on the Rust code.
The Rust driver spent years reaching functional parity with C. In tests it matches or sometimes beats the C implementation on performance, and it has been in the mainline kernel since before the C driver was retired. Google engineer Carlos Llamas cited the growing difficulty of maintaining the C code without introducing bugs as the reason for the removal. The change eliminates the need to maintain two parallel implementations, so fixes and new features go into a single codebase.
The switch does not turn Android into a Rust system. Android still runs enormous amounts of C and C++, and Linux remains a multi-language project. Binder is one important component, and its move to Rust is a concrete sign that Rust has crossed from experimental to production in a security-sensitive, performance-critical kernel driver.
Replacing a long-lived C driver in a widely deployed kernel component is a stronger endorsement of Rust than any feature announcement, because the Rust version had to prove parity, performance, and maintainability over years.
The performance claim is workload-specific: it says Rust matches or beats C in the tests used, not that Rust is universally faster.
Android will not become a Rust project; the move applies to Binder only, and other subsystems will be judged on their own requirements and maintainer capacity.
The removal patch is a practical argument for evaluating language changes based on maintenance costs and feature requirements, not language popularity.