# Rust in Android: Google's 1,000x Memory-Safety Claim, and What Can Be Checked

URL: https://edufabtech.com/blog/rust-android-memory-safety-google-claims-verified  
Section: Blog · Computing & Software  
Published: 2026-11-04  
Publisher: EduFabTech (https://edufabtech.com)

> Google's own tracking puts Android's Rust vulnerability density at about 0.2 per million lines versus roughly 1,000 for C/C++. Here is what that number covers, what it doesn't, and what outside researchers have actually checked.

In November 2025, Google's Android security team published a number that is unusual in software engineering: a precise, ten-year trend line for how many memory-safety bugs per million lines of code its two main programming languages produce. The claim, laid out by Android engineer Jeff Vander Stoep on the Google Security Blog, is that Rust code written for Android carries a vulnerability density roughly 1,000 times lower than the platform's C and C++ code. It is one of the largest industrial datasets anyone has published on memory-safe language adoption, and it is also entirely self-reported. Both things are worth taking seriously at once.

The headline figures, as Google states them: Android's Rust code, now roughly 5 million lines by the third quarter of 2025, has produced an estimated 0.2 memory-safety vulnerabilities per million lines of code, against a historical density closer to 1,000 vulnerabilities per million lines for the platform's C and C++ code. Across the whole operating system, memory-safety flaws accounted for fewer than 20% of Android's disclosed vulnerabilities in 2025, down from more than 75% four years earlier, according to the same post. Those are two different measurements — a density figure for new Rust code specifically, and a share-of-total figure for the whole platform — and the piece is explicit that both have moved together since Android began writing new memory-unsafe code sparingly from around 2021.

What makes the post more than a marketing note is that Google ties the safety numbers to delivery metrics tracked the same way engineering organizations track DORA metrics — change failure rate and review time. Rust changes, the post says, have a 4x lower rollback rate than comparably sized C++ changes and spend 25% less time in code review. If accurate, that undercuts the common argument that memory safety is traded for velocity. But "if accurate" is the operative phrase, because every number in the post comes from Google's internal bug-tracking and code-review systems, not from an outside audit.

![Two charts: the log-scale density gap between Rust and C/C++, and the share of Android's disclosed bugs that were memory-safety flaws falling from over 75% in 2021 to under 20% in 2025.](https://edufabtech.com/uploads/2026/11/rust-android-memory-safety-google-claims-verified-2.png)
*Two charts: the log-scale density gap between Rust and C/C++, and the share of Android's disclosed bugs that were memory-safety flaws falling from over 75% in 2021 to under 20% in 2025. — EduFabTech · Own work*

## What the Numbers Actually Cover

The 0.2-versus-1,000-per-million-lines comparison is doing more work than it looks. The Rust figure is drawn from a relatively young, relatively small corpus — about 5 million lines, written mostly since 2021, in code paths Android's own developers chose to rewrite. The C/C++ figure is historical: it reflects decades of code, written under different review standards, different tooling, and in some cases before Android had a dedicated security bulletin process at all. Comparing a freshly written, carefully reviewed Rust codebase against the accumulated debt of an older C/C++ codebase is a real comparison, but it is not a controlled experiment — nothing here holds the age, size, or review rigor of the two codebases constant.

Google's post does supply one case that reads like a stress test of its own claim. In CrabbyAVIF, Android's Rust-based AVIF image decoder, engineers found a linear buffer overflow inside an `unsafe` block, later assigned CVE-2025-48530 with a CVSS score of 8.1. The bug could have allowed remote code execution. It never shipped in a public release, and Google credits Scudo, Android's hardened heap allocator, with making the flaw non-exploitable even inside the vulnerability window. The post treats this as evidence the layered defense works — Rust plus Scudo caught what Rust alone did not — rather than evidence against the broader trend.

The `unsafe` keyword is the seam in Rust's safety argument, and it is worth pausing on how much of Android's Rust is behind that seam. Google's post does not give a percentage for Android specifically, but two independent academic studies of the broader Rust ecosystem give a sense of scale. Ana Nora Evans, Bradford Campbell and Mary Lou Soffa, in a paper presented at ICSE 2020, found that developers use the `unsafe` keyword directly in fewer than 30% of published Rust libraries — but that more than half of libraries cannot be fully checked by Rust's compiler anyway, because an `unsafe` block exists somewhere further down their dependency chain. Safety in Rust, in other words, is a property of a whole call graph, not of the lines a given team happens to write.

A second study digs into why developers reach for `unsafe` at all. Researchers at Carnegie Mellon University — Ian McCormack, Tomas Dougan, Sam Estep, Hanan Hibshi, Jonathan Aldrich and Joshua Sunshine — interviewed 19 Rust developers and then surveyed 160 more, reported in a preprint on arXiv most recently updated in February 2026. Most participants said they used `unsafe` only when they believed there was no safe alternative, and most tried to avoid it. But they also described concrete gaps: tooling for foreign-function boundaries left them uncertain about their own design choices, and certain patterns of aliasing and concurrency across a foreign-function boundary were, in the authors' words, difficult to encapsulate safely. That is the technical reason Rust's compile-time guarantees stop being guarantees exactly at the point where Rust code calls into, or is called from, C or C++ — which is precisely the boundary Android's migration has to cross everywhere it keeps legacy C/C++ components alongside new Rust ones.

![A diagram of the safe-Rust/C++-FFI boundary where the "unsafe" keyword sits, tracing the CrabbyAVIF buffer-overflow CVE through to Scudo, the allocator that stopped it from being exploitable.](https://edufabtech.com/uploads/2026/11/rust-android-memory-safety-google-claims-verified-3.png)
*A diagram of the safe-Rust/C++-FFI boundary where the "unsafe" keyword sits, tracing the CrabbyAVIF buffer-overflow CVE through to Scudo, the allocator that stopped it from being exploitable. — EduFabTech · Own work*

## A Concrete Case: The Pixel Modem

Google's clearest recent example of that boundary is the Pixel baseband. In an April 2026 post, Google Pixel software engineer Jiacheng Lu described moving DNS parsing in the Pixel 10 series' cellular modem firmware to Rust — "the first Pixel device to integrate a memory-safe language into its modem," in the post's own description. The motivation was concrete: Google's Project Zero had previously demonstrated remote code execution on Pixel modems over the internet, through a DNS-related memory-safety flaw tracked as CVE-2024-27227. The team chose an existing Rust DNS library, hickory-proto, reporting it carried more than 75% test coverage and depended on more than 30 other crates even with optional features disabled. The compiled footprint they shipped was small and itemized: a 4KB Rust shim, 17KB of core runtime and compiler-builtin code, and 350KB for the library and its dependencies — 371KB in total, built with Fuchsia's cargo-gnaw tool and integrated into Google's Pigweed embedded build system, with memory allocation routed through FFI calls to the existing C allocator.

The baseband case is useful precisely because it is narrow and documented, in contrast to the platform-wide density figures. It names an exact predecessor vulnerability, an exact library, and an exact code size, which makes it easier for an outside reader to judge the engineering decisions than it is to judge an aggregate "1,000x" figure drawn from internal bug tracking across millions of lines of code.

## What Counts as Independently Checked, and What Doesn't

It is worth being plain about what has — and has not — been independently verified here. Google's vulnerability-density figures, rollback-rate comparison, and code-review-time comparison all come from Google's own internal engineering systems; the company has not published the underlying bug counts, the denominator lines-of-code snapshot methodology, or a breakdown by subsystem that would let an outside party recompute the ratio. Coverage of the November 2025 post by other outlets, including a brief writeup on LWN.net, restates Google's figures without adding independent measurement of its own. That is not a criticism of Google's engineering — large-scale, longitudinal vulnerability-density studies are hard for anyone outside a codebase's own security team to run — but it means the "1,000x" figure should be read as a vendor's internal metric, not as a number replicated by a third party.

The academic literature cited above measures something different and narrower: not Android's vulnerability history, but how the `unsafe` keyword is used across the broader Rust ecosystem, and how developers reason about it. Those findings are independently peer-reviewed, but they are not a check on Google's specific Android numbers — they describe the general mechanism (unsafe code, FFI boundaries) that would explain why a Rust migration reduces but does not eliminate memory-safety risk, without confirming or disputing Google's magnitude.

## The Policy Backdrop

Google's migration is happening alongside a policy push toward memory-safe languages generally. The Cybersecurity and Infrastructure Security Agency, jointly with the FBI, lists developing new product lines in memory-unsafe languages such as C or C++ — when memory-safe alternatives are readily available — as a "bad practice" for software used in critical infrastructure or national critical functions. The guidance calls on manufacturers to publish a memory-safety roadmap by the end of 2025 for existing products written in memory-unsafe languages, with an exception for products that already have an announced end-of-support date before 1 January 2030. It names several memory-safe languages as acceptable options, including Rust, Go, Java, C#, Swift, Python, Ruby, Ada and Delphi/Object Pascal — a reminder that Rust is one option among several, chosen by Google and others mainly where C/C++-level performance also matters.

## What This Means in Practice

For a developer or researcher deciding how much weight to put on "memory-safe migration reduces vulnerabilities," the Android case supports a specific, bounded claim rather than a universal one: inside Google's own measurement of its own codebase, new code written in Rust since roughly 2021 has shown a much lower rate of memory-safety bugs than the C/C++ code it replaced, and that has coincided with a falling share of memory-safety bugs platform-wide. It does not yet support a precise, externally verified multiplier, because no external party has recomputed one. It also does not mean memory safety is solved once a codebase switches languages — the CrabbyAVIF bug happened inside Rust's own `unsafe` escape hatch, and the academic literature on unsafe Rust usage says that escape hatch is used deliberately, often where it is hardest to tool and audit, especially at foreign-function boundaries where a memory-safe language has to call into, or be called by, code that is not memory-safe at all. Readers evaluating a vendor's migration numbers, in Android's case or any other, should look for exactly those seams: what fraction of the "safe" codebase still touches `unsafe` or an FFI boundary, and whether the vendor's own bug count there is going up or down.

## Sources

1. Jeff Vander Stoep. (2025). Rust in Android: move fast and fix things. Google Security Blog https://blog.google/security/rust-in-android-move-fast-fix-things/
2. Jiacheng Lu. (2026). Bringing Rust to the Pixel baseband. Google Security Blog https://blog.google/security/bringing-rust-to-the-pixel-baseband/
3. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation. (2025). Product Security Bad Practices. CISA https://www.cisa.gov/resources-tools/resources/product-security-bad-practices
4. Ana Nora Evans, Bradford Campbell, Mary Lou Soffa. (2020). Is Rust Used Safely by Software Developers?. ICSE 2020 (arXiv preprint) https://doi.org/10.1145/3377811.3380413
5. Ian McCormack, Tomas Dougan, Sam Estep, Hanan Hibshi, Jonathan Aldrich, Joshua Sunshine. (2024). A Mixed-Methods Study on the Implications of Unsafe Rust for Interoperation, Encapsulation, and Tooling. arXiv preprint https://arxiv.org/abs/2404.02230

---
Source page: https://edufabtech.com/blog/rust-android-memory-safety-google-claims-verified  
Quote with a link to the source page. © EduFabTech.