Rust in Android: More Memory Safety, Fewer Revisions, Fewer Rollbacks, Shorter Reviews

Android's security team published a blog post this week about their experience using Rust. Its title? "Move fast and fix things." Last year, we wrote about why a memory safety strategy that focuses on vulnerability prevention in new code quickly yields durable and compounding gains. This year we look at how this approach isn't just fixing things, but helping us move faster.

The 2025 data continues to validate the approach, with memory safety vulnerabilities falling below 20% of total vulnerabilities for the first time. We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android's C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one... Data shows that Rust code requires fewer revisions. This trend has been consistent since 2023. Rust changes of a similar size need about 20% fewer revisions than their C++ counterparts... In a self-reported survey from 2022, Google software engineers reported that Rust is both easier to review and more likely to be correct. The hard data on rollback rates and review times validates those impressions.

Historically, security improvements often came at a cost. More security meant more process, slower performance, or delayed features, forcing trade-offs between security and other product goals. The shift to Rust is different: we are significantly improving security and key development efficiency and product stability metrics.

With Rust support now mature for building Android system services and libraries, we are focused on bringing its security and productivity advantages elsewhere. Android's 6.12 Linux kernel is our first kernel with Rust support enabled and our first production Rust driver. More exciting projects are underway, such as our ongoing collaboration with Arm and Collabora on a Rust-based kernel-mode GPU driver. [They've also been deploying Rust in firmware for years, and Rust "is ensuring memory safety from the ground up in several security-critical Google applications," including Chromium's parsers for PNG, JSON, and web fonts.]
2025 was the first year more lines of Rust code were added to Android than lines of C++ code...

C/C++ code covers more complex legacy code

[Anonymous Coward]

So it would only be natural to have more unforeseen issues with C/C++ code than with Rust.
Personally I expect more Rust issues over time as the code base complexity increases.

Re:

[molarmass192]

I'm not a die-hard fan of C++, I do prefer Rust to it if forced to choose, but my greenfield choice is C-like options. However, this Rust fanboy stuff is super off-putting. There is much more to programming than memory safety, in fact, the overwhelming majority of defects are not related to memory safety. Rust isn't a magic bullet that writes bug-free code, careless devs can write bad code in Rust. Rust can and does crash, it's not bulletproof, it just makes it harder for you to work around the compiler whe

Re:

[Jeremi]

Rust [...] makes it harder for you to work around the compiler when it comes to memory.

... which, to be clear, is a good thing. Working around the compiler is dangerous and a code smell, so it shouldn't be something that is easy to do. It usually indicates that either the compiler's capabilities aren't sufficient to meet your needs (in which case, a better solution would be either a better compiler, or to re-evaluate the wisdom of your approach), or that you are doing something the wrong way and should find a way to do it that works with the compiler, rather than around it, so that you get

Re:

[Mr. Barky]

Any study on differences between Rust and C++ is likely to be filled with biases. Older code versus newer code, as you point out, is one. Type of project that gets selected is another. I suspect that there is likely a team selection bias as well - what profile is going to be recruited for doing the Rust project? Is it randomly assigning developers or is it something developers seek out ("to be on the Rust team")? If the latter, are more competent developers going to be the ones that volunteer? There is prob

Re:

[arglebargle_xiv]

That was my reaction too, if you've got legacy code with 20 years of accumulated cruft and start again with a clean sheet it's going to get better no matter what language you write it in.

Unsurprising.

[sg_oneill]

This shouldn't surprise anyone. The thing that makes rust a "hard" language is its punishing borrow checker step that simply refuses to compile if you've got code smells that hint at page violations or other memory goonery. Rust punishes you, but in doing so it makes you a better programmer.

Its something I fell in love with Crystal over (which, btw does NOT do a borrow checker), its static analysis step that refuses to compile if your doing things with variables that introduces un-handled nulls. I could feel myself becoming a better coder (which is a hard thing to achieve for someone with 20y experience) simply because it was pointing out anti-patterns in my coding and requiring me to fix them. Its a shame crystal never really took off, its a genuinely good and speedy little language. Who knows, maybe some day. Python sat in obscurity for two decades (Python, for the youngsters in the audience, is OLDER than JS, Java and so on. Y'all only hearing of it recently doesnt make it a recent language) before finally exploding in popularity

curious to know

[ZipNada]

I found their blog a bit short of details. Their metrics apparently show that Rust has fewer "Revisions per Change". I guess this means they had to tweak the Rust code a little less in order implement something? Why is this the case? And then the review time is a little less too? Why would that be?

Very quick code reviews

[OrangeTide]

In part because nobody wants to reveal that they don't actually know much about Rust.

Rust is not magic, but it helps

[CommunityMember]

Rust cannot address some fundamental logic errors (having code to allow "evil doer" to do nasty things), but eliminating the low hanging fruit of memory safety helps avoid an entire class of issues that are far too easy to not notice in initial coding and review. And the more guardrails that are enforced during development the better.

There are some people who suggest that C can be safe, as long as the developers are reliably and consistently careful in their design and codes. And those people are proba

Re:

[Mr. Barky]

The arguments about C being better seem to me similar to the arguments people use about using strongly typed languages vs. weakly typed languages. Javascript proponents often advocate that the flexibility of not having to worry about types is an advantage. C proponents will use similar arguments with direct memory access. (And then you'll have languages like C# and Java that have evolved to use reflection a bit everywhere... which weakens the type safety in those languages - and turns compile-time errors in

The interesting thing is more productivity

[t_hunger]

The interesting thing is more productivity while reducing the number of bugs. Normally reducing bugs requires stricter processes, which typically reduces productivity.

Programming language o programmer?

[paugq]

Is this improvement due to Rust being so much better than Java, C++ or others?
Or is it due to early adopters of Rust on Android are more senior and savvy developers? What will happen when the juniors come on board?

Re: Programming language o programmer?

[t_hunger]

There was a paper about rust use in open source projects, looking at vulnerabilities introduced by developers with different contribution histories. They suggest that you need to spend working several years in a C++ codebase to get down to the same defect rate as a new contributor in a rust project.

https://cypherpunks.ca/~iang/p... [cypherpunks.ca]

If that is true, then there is probably little reason to worry.