Rust in Android: More Memory Safety, Fewer Revisions, Fewer Rollbacks, Shorter Reviews (googleblog.com) 32
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...
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 (Score:1)
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:C/C++ code covers more complex legacy code (Score:4, Interesting)
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 when it comes to memory.
Re: C/C++ code covers more complex legacy code (Score:3)
Few people, even here, understand why rust will help you write better code before even looking at the memory safety aspect. It mostly comes down to the enum system and pattern matching ensuring you've covered all of your bases. Can it crash? Sure, but you, the developer, explicitly told it to.
Re: (Score:2)
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: (Score:3)
What "Rust fan boy stuff"?
Rust devs are perfectly well aware that type safety and memory safety cannot save your from making logical errors in your code. I have never heard anyone make such claims. Why do you tink that would be that stupid?
For myself, I prefer to use Rust because of too many years having. to use that ever growing nightmare of complexity that is C++.
All that type and memory safety Rust has saves a lot of time having to do all that tedious work of checking ones work manually for such errors,
Re: C/C++ code covers more complex legacy code (Score:2)
I think it's more likely the detractors are being fanatical. Fluffernutter is hilariously so, he called the cloudflare developers inept because they rewrote their network stack in rust. Seriously. This is a guy who, not long before that, was telling me how he writes code four times faster than me (which I seriously doubt) and proceeds to talk about the way he writes code, which introduced potential semantic errors, then talks about how he relies on his code crashing at runtime to know when there's a bug in
Re: C/C++ code covers more complex legacy code (Score:2)
Which dependencies are you even talking about? And which ones aren't compete? Be specific. With rare exception, rust binaries are statically compiled, and when there's any dynamic linking involved, it's almost always into a c library. Nobody, anywhere, ever dynamically links rust code into other rust code, so there's no way you're going to have a rust dependency that needs another rust dependency. You know why that is? Because rust doesn't have a stable ABI. So you'll have to excuse me if I call bullshit.
,
A
Re: (Score:2)
the overwhelming majority of defects are not related to memory safety.
Citation needed. My first search showed that in C++ some 70% of bugs are related to memory safety, which is also why it's so significant that Rust reduced (but not eliminated) it.
It doesn't write bug free code, but it makes a whole lot of bugs a bit more difficult. A careless dev is not expected to be perfect with Rust, just to be unable to cause as much damage.
Re: (Score:2)
in fact, the overwhelming majority of defects are not related to memory safety
When looking at defects that constitute security vulnerabilities, this is false. In typical C/C++ code about 75% of security vulnerabilities are due to memory safety bugs.
Re:C/C++ code covers more complex legacy code (Score:4, Insightful)
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 probably some manager somewhere with a bonus tied to the number of projects using Rust which also might cause a bias in the reporting.
Google might have the scale to do a randomized experiment - for example assigning at random 10 new projects to use C++ and 10 with Rust and follow it for 3 years (the maximum length of time Google supports any product ;) ), but I doubt they did that.
Note: I am not suggesting that what Google reported is necessarily wrong... just that it is very easy to accidentally get wrong answers from statistics.
Re: (Score:2)
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")?
I can answer this, at least for Android (which is the topic of TFA): Android requires all new native code to be written in Rust, unless there is some specific reason to use C++. And, really, the only valid reason for using C++ is that the new code is a small addition to an existing C++ binary. So, effectively everyone on the Android team that works on native code and isn't just making small maintenance changes to existing code is "recruited" to write Rust.
One thing to keep in mind, though, is that softw
Re: (Score:2)
Unsurprising. (Score:3)
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 (Score:2)
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 (Score:3)
In part because nobody wants to reveal that they don't actually know much about Rust.
Re: (Score:2)
In part because nobody wants to reveal that they don't actually know much about Rust.
Quite the opposite (until a couple of months ago I worked at Google, on Android, and wrote a lot of Rust): Much Rust code requires more reviews. This is because if the reviewer you'd normally go to as a subject-matter expert in the area isn't also an experienced Rust developer (common), what you do is get two reviews, one from the reviewer who knows the area, and one from an experienced Rust engineer.
The reviews still tend to go faster, though, because there are a whole lot of things reviewers don't have
Rust is not magic, but it helps (Score:2)
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: (Score:3)
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
Memory safe C is hard (Score:2)
It's so hard, the world's self-declared experts in everything over on HN even think Rust is a better choice most of the time.
Re: (Score:2)
I agree. To do C well you have to be very disciplined and add a lot of design patterns that are unnecessary if your main going is just making something work. It's exactly the same with JS (hence why Typescript and endless libraries are so popular).
As you move into application level code it all becomes quite tiresome. Doing basic things requires dealing with clunky designed object models which slow you down at best, and can trip up the inexperienced at worst.
C++ at least provides better tools for structuring
Re: (Score:2)
The history of bugs and security vulnerabilities in C shows that those people are probably mostly not correct.
The interesting thing is more productivity (Score:2)
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? (Score:2)
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? (Score:2)
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.
Re: (Score:2)
I think there is a learning / unlearning curve since the language can be very frustrating for people used to throwing around pointers or references without regard to their lifetimes but once you're over that it becomes a lot simpler. I think also,
Hardly surprising (Score:3)
The compiler has certainly kicked my ass plenty of times for doing things I shouldn't but if it compiles I'm pretty confident that any bugs there are caused by application logic issues, not language issues. Rust will not help if I meant to spin the motor clockwise and sent it spinning anti-clockwise, or if I forgot to check if someone was permitted to do the thing before doing the thing. For that I need to do testing but fortunately I can also write unit tests with the code it's testing which also cuts down on issues later.
So all in all I'm not surprised developers report higher quality code which goes out the door and doesn't come back because it's broken.
I dunno... (Score:2)
Feels a little bit like moving away from legacy environments and starting fresh with [ insert more modern, secure, pattern-focused paradigm/language ] is a somehow more accurate summary to me.
Breathless, much? (Score:2)
Rust in Android: More Memory Safety, Fewer Revisions, Fewer Rollbacks, Shorter Reviews
IANAP so my impressions may be way off base. That said, I've read a lot of, er... let's call it "enthusing" about Rust lately. And all of it seems to be of the "ZOMG! Rust!" variety that somehow makes me think of ponies.
I have no doubt that Rust is a decent language that solves real problems, and anything that disarms memory-usage footguns is worth looking at. But is it really worthy of the hype I keep reading? Or is it just a lot of programmers who don't know much of anything other than Rust and are pushin
Historically, security improvements often came at (Score:1)