The conventional wisdom in software security has long held that safety inevitably slows you down. More security meant more process, slower performance, or delayed features, forcing organizations to choose between shipping quickly and shipping securely. Google’s Android team is systematically dismantling that assumption.
Across 5 million lines of Rust code now running in Android, Google reports a 1000x reduction in memory safety vulnerability density compared to C and C++ code. But the bigger surprise: Rust changes demonstrate a 4x lower rollback rate and spend 25% less time in code review. The safer path has become the faster one.
The Productivity Paradox: Safety That Accelerates Development
Historically, security improvements came at a cost to velocity. Android’s data reveals a paradigm shift that’s fundamentally changing how we approach systems programming at scale.
The Android team tracks development velocity using the DORA framework, the industry standard for evaluating software engineering performance. Their findings challenge conventional assumptions about safety versus speed:
Code Review Efficiency:
Rust changes require 20% fewer revisions than comparable C++ changes and spend 25% less time in review. This trend has remained consistent since 2023, with the improvement accelerating as team Rust expertise grew.
Stability Advantages:
Rust’s rollback rate continues decreasing even as adoption surpasses C++, settling at 4x lower than C++ for medium and large changes. Rollbacks create organizational friction that mobilizes resources far beyond the original developer, making this stability improvement particularly valuable.
The data validates what Google engineers reported in a 2022 survey: Rust code is both easier to review and more likely to be correct from the start.
How Android Measures the Rust Advantage
Cross-language comparisons require careful methodology. The Android team ensures reliability through:
- Similar change sizes: Rust and C++ have comparable functionality density
- Common developer pools: First-party changes from Android platform developers
- Longitudinal tracking: Measuring trends over multiple years
The result is unambiguous: when developers aren’t fighting memory safety issues, they can focus on delivering robust functionality. An operating system with 3 billion active devices can’t afford to move slowly, but neither can it afford the security vulnerabilities that historically plagued C and C++ development.
Beyond Platform Code: Rust’s Expanding Reach
With Rust support mature for Android system services and libraries, Google is extending its memory safety advantages throughout the stack:
Linux Kernel: Android’s 6.12 Linux kernel includes production Rust drivers, with a Rust-based kernel-mode GPU driver in development through collaboration with Arm and Collabora.
Firmware: Combining high privilege and performance constraints makes firmware both high-risk and challenging to secure. Google has been deploying Rust in firmware for years, releasing tutorials, training materials, and reference code for the broader community.
Applications: Critical Google applications now leverage Rust for foundational security:
* Google Messages uses Rust-implemented MLS protocol for secure RCS messaging
* Nearby Presence relies on Rust for Bluetooth device discovery security
* Chromium replaced parsers for PNG, JSON, and web fonts with memory-safe Rust implementations
The Near-Miss That Validates the Strategy
Google recently avoided shipping its first Rust-based memory safety vulnerability, a linear buffer overflow in CrabbyAVIF. This near-miss offers critical insights about defensive programming at scale.
Though the vulnerability never reached public release, Android’s Scudo hardened allocator rendered it non-exploitable due to guard pages surrounding secondary allocations. This demonstrates why memory-safe languages represent just one component of a comprehensive memory safety strategy.
The incident revealed an important gap: Android’s crash reporting initially failed to clearly identify overflow-related crashes, delaying triage. This has since been addressed, providing clearer signals when overflows occur.
The Unsafe Reality: When 4% Matters
Operating system development requires unsafe code for foreign function interfaces and hardware interaction. Simply banning unsafe code isn’t practical. Google’s data indicates even unsafe Rust is dramatically safer than assumed:
“Our empirical evidence shows unsafe Rust is actually quite safe”, Android’s team reports. They speculate several factors contribute:
* unsafe{} doesn’t disable all Rust safety checks
* Encapsulation enables local reasoning about safety invariants
* unsafe blocks receive additional scrutiny during review
Google is developing new training modules specifically covering unsafe code best practices, recognizing that even within Rust’s safety boundaries, defense-in-depth remains essential.
The Numbers Don’t Lie: Quantitative Safety Improvements
With approximately 5 million lines of Rust in Android and one potential memory safety vulnerability found (and fixed pre-release), the estimated vulnerability density for Rust stands at 0.2 vuln per million lines. Compare this to Android’s historical C and C++ data showing approximately 1,000 memory safety vulnerabilities per million lines.
This represents a more than 1000x reduction in vulnerability density, a fundamental shift in security posture that dramatically boosts the effectiveness of Android’s entire security architecture.
The Future: Expanding the Memory Safety Footprint
Google’s approach focuses on strategic adoption rather than wholesale rewrites. The current priority areas include:
- High-risk components: Parsers and network-facing code where memory safety provides immediate security benefits
- New development: All new systems-level code defaults to Rust where feasible
- Incremental replacement: Components being replaced or substantially modified become Rust migration candidates
The strategy acknowledges that C and C++ will persist while recognizing that every line of Rust represents exponential safety improvement.
What makes Android’s Rust adoption compelling isn’t just the security improvements, it’s the productivity gains that come with them. When safety enhancements actually accelerate development velocity, the calculus for legacy systems migration fundamentally changes. Google’s data suggests we’re entering an era where memory safety isn’t just about preventing exploits, it’s about building better software faster.
The Android team’s experience demonstrates that in systems programming, the safer path can indeed be the faster one. As the industry grapples with memory safety crises, Google’s methodical, data-driven approach provides a blueprint for organizations facing similar challenges at scale.
