Memory Safe Languages in Android 13 (Google security blog)

[Posted December 2, 2022 by jake]

Over on the Google security blog, Jeffrey Vander Stoep writes about the impact of focusing on using memory-safe languages for new code in Android.

As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.
While correlation doesn’t necessarily mean causation, it’s interesting to note that the percent of vulnerabilities caused by memory safety issues seems to correlate rather closely with the development language that’s used for new code. This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. Of course there may be other contributing factors or alternative explanations. However, the shift is a major departure from industry-wide trends that have persisted for more than a decade (and likely longer) despite substantial investments in improvements to memory unsafe languages.

(Thanks to Rahul Sundaram.)

(Log in to post comments)

"do not represent a majority of Android’s vulnerabilities"

Posted Dec 2, 2022 1:03 UTC (Fri) by gus3 (guest, #61103) [Link]

Sure. And Microsoft finally got Windows right (again).

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 6:24 UTC (Fri) by TheGopher (subscriber, #59256) [Link]

As far as I can see they list Java as a memory safe language - which last time I checked - it isn't. No use-after-free, but plenty of space for accessing the same pointer from multiple threads and bad locking.

I'm surprised there isn't a breakdown of vulnerabilities per language, just an assumption of what's what. This would be more interesting.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 7:40 UTC (Fri) by roc (subscriber, #30627) [Link]

Java is memory safe in the sense that you can't read or write to arbitrary memory even in the presence of data races and bad locking.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 10:48 UTC (Fri) by TheGopher (subscriber, #59256) [Link]

Yes, though for C and C++ I don't think arbitrary memory access is a big problem either, at least not in userspace code. Use after free is a big problem though, so maybe there are great gains there.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 12:13 UTC (Fri) by Sesse (subscriber, #53779) [Link]

Arbitrary memory access typically gives you the equivalent of full code execution, so it's a pretty big deal. It also makes DoS nearly trivial.

Basically, Java and Rust both completely eradicate a certain class of errors that tends to create severe vulnerabilities, no matter what you choose to call that class.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 10:50 UTC (Fri) by TheGopher (subscriber, #59256) [Link]

What I'm really saying is I wish there was more data here - it feels like too much evangelism, too little real deep diving into what issues they're no longer seeing.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 11:59 UTC (Fri) by khim (subscriber, #9252) [Link]

True, but WIkipedia, at least, says race condition is memory safety type of error.

Java clearly doesn't prevent race conditions (not even Rust does that, it only prevents data races, although safe Rust prevents concurrent reads/writes to shared memory which Wikipedia equated to data races), thus more clarification would be great.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 13:23 UTC (Fri) by atnot (subscriber, #124910) [Link]

I think this is just a case of differing terminology.

> Race condition – concurrent reads/writes to shared memory

This definition is equivalent to what the article and rust land calls a "data race". It's not really worth arguing on vocabulary because there's not really any common agreement on what a lot of these terms mean or what their relation is, as the article points out.

The important thing is just that unlike some languages like C or Go, race conditions in safe java and rust can not cause language-level undefined behavior. They can only cause program-level unexpected or undesirable behavior.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 15:46 UTC (Fri) by marcH (subscriber, #57642) [Link]

BTW java.util.concurrent is a pretty good antidote against race conditions.

I believe the work to create java.util.concurrent eventually prompted this:

https://en.wikipedia.org/wiki/Java_memory_model#Impact

> The Java memory model was the first attempt to provide a comprehensive memory model for a popular programming language.[6] It was justified by the increasing prevalence of concurrent and parallel systems, and the need to provide tools and technologies with clear semantics for such systems. Since then, the need for a memory model has been more widely accepted, with similar semantics being provided for languages such as C++.[7]

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 18:41 UTC (Fri) by matthias (subscriber, #94967) [Link]

> ... race conditions in safe java and rust can not cause language-level undefined behavior.

For java this should be true, but in rust, data races are undefined behavior. However, in safe rust, it is not possible to cause data races. Every reference in safe rust is either read only or unique.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 20:43 UTC (Fri) by atnot (subscriber, #124910) [Link]

I think we mean the same thing, just with different words. What I mean is that you can create race conditions in both languages, for example by checking the permissions of a file before writing it, or taking a copy of a shared value and then modifying it and writing it back. But unlike e.g. C and Go, these race conditions can not compromise the integrity of the JVM or abstract machine. So they are undefined only in the higher level sense that the application may misbehave in unpredictable ways.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 22:26 UTC (Fri) by riking (subscriber, #95706) [Link]

Easy way to create a "Race condition" (as distinct from a "Data race") in Rust:

- Create a multi-producer, single consumer channel.
- Create two threads with different identities.
- Each thread sends its identity over the channel after it starts.
- Read the first value received from the channel and do something important with it.

The two threads race to be the first to deliver their value. An identical situation in Java is also easy to accomplish.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 12:02 UTC (Mon) by hmh (subscriber, #3838) [Link]

This is not even a bug when the processing order of the messages for the two threads doesn't matter to program correctness -- and it better not matter in any such design. But yeah, it is definitely undefined which thread will get its message processed first. Note that it might not even be racy, but rather system-dependent (where it *always* works out the same way in a given system, but it might change in a future version).

However, what _atnot_ described is known as "TOCTOU", and it is an extremely common race condition that is behind a lot of security vulnerabilities involving filesystems, for example. In this case, the program would be racing whatever else might be trying to manipulate that same filesystem resource. And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 12:22 UTC (Mon) by khim (subscriber, #9252) [Link]

> And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

No. It's possible to do in Rust, but it's not easy (let alone “extremely easy”). If both producer and consumer are in your program then Rust's type system would, usually, stop you (read here about how it does that).

Of course if you would add communication to external systems (use Unix pipes or network for communication between pieces of one program, for example) then all bets are off, but I wouldn't characterise such design as “extremely easy”. Rather I would characterise it as “elaborately created footgun”.

Yes, they are possible, but you have to work to create them.

P.S. And yes, people often complain bitterly about that property of Rust when they invent clever footguns and Rust says it doesn't want to accept these. Just look on how some people avoid race conditions. And weep.

P.S. Actually read the whole thread. Because guy there treats race condition precisely and exactly like other here treat UB: I tested, it worked in C#, why compiler couple make it work for me in Rust? O_PONIES, O_PONIES, and more O_PONIES.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 16:07 UTC (Mon) by Wol (subscriber, #4433) [Link]

> > And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

> No. It's possible to do in Rust, but it's not easy (let alone “extremely easy”). If both producer and consumer are in your program then Rust's type system would, usually, stop you (read here about how it does that).

Please. Stop. Engage. Brain. Before. Opening. Mouth.

You clearly don't understand what TOCTOU is (or, more likely, you forgot that was what we were discussing).

The problem is not preventing your program screwing it up. The problem is preventing an *external* *hostile* program taking advantage. If there is an easy way to prevent Rust from screwing *that* up, I'm sure many people will be all ears ... (Other than how I did it years ago in Fortran, files were configured NR&1W, everybody could open the file read-only, but to change it, you had to open it r/w, and then run the entire transaction from scratch.) Just because the Rust compiler blocks two threads in the same program messing up, doesn't mean it'll stop an unrelated trojan barging in on the party ...

Cheers,
Wol

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 17:22 UTC (Mon) by khim (subscriber, #9252) [Link]

> You clearly don't understand what TOCTOU is (or, more likely, you forgot that was what we were discussing).

TOCTOU may happen inside of one program, too. In fact if we are talking about things like Linux kernel then most TOCTOUs which caused security problems, happened inside of kernel, not outside of it.

> Other than how I did it years ago in Fortran, files were configured NR&1W, everybody could open the file read-only, but to change it, you had to open it r/w, and then run the entire transaction from scratch.

Today we have Rwlocks for that and you can [try to] upgrade reader lock to writer lock. But yes, Rust ensures more-or-less what you describe. Just on language level.

Yes, of course, by itself it's not a protection against external actors, but it greatly simplifies code which have to deal with external actors, too.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 18:13 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I mostly find TOCTOU to be an API problem with not covering some use case that *appears* to be supported by a sequence of APIs but is actually wanted to be a single operation. *Most* of the time you can ignore things, but when you can't, it's usually pretty deep down where the operation needs to be addressed (e.g., "overwrite file if contents are different" or "delete if current user owns the file").

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 19:15 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

That Wikipedia entry is just wrong, it should identify specifically Data Races, not all Race Conditions. A Data Race is a Race Condition, but most Race Conditions are not Data Races.

Our universe has race conditions, we're used to that. The illustration I like features a cat, we put the cat out the front door, we walk through the house, we close the kitchen door - but the cat might be back inside, because it can run around the house and back inside before we closed the kitchen door. If we don't want that we need to shut all other externals doors (and possibly windows) before putting the cat out.

Data races are much stranger and unlike our normal experience of the universe.

In Java data races are technically safe, but they destroy Sequential Consistency, which means it's very difficult for human programmers to reason correctly about the behaviour of concurrent software with races. Humans expect things to happen in some sort of order, maybe A happens before B, maybe B happens before A. You can write a list of possible orders. But without Sequential Consistency, perhaps A causes B, which then happens before A, very confusing. Better to let the ultra-low level concurrent CPU primitives people think about such things, not us mere mortals. Java offers almost the best possible case with loss of SC. All unaffected variables work as expected, and the raced variables are definitely valid, but their value may be astonishing, including both "before" and "after" the race. The value will always be a value they actually had, or would have at some point, but maybe seems out of place now. e.g. if you only store even numbers in foo, and you race it, foo won't ever be 35 or -7 or something. But it might now be 126 even though you expected the program to print "One Hundred!" before that happened.

In safe Rust data races can't happen.

In languages like C and C++ all data races are immediate Undefined Behaviour, all bets are off, please proceed calmly to the lifeboats

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 4, 2022 5:09 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

> Our universe has race conditions, we're used to that.

Most of us are used to that. Some of us still haven't got the memo: https://bugs.openjdk.org/browse/JDK-4045688

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 1:38 UTC (Mon) by anton.kochkov (subscriber, #161204) [Link]

Java isn't memory safe in terms that it eats all memory to work.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 5:47 UTC (Mon) by Fowl (subscriber, #65667) [Link]

There's no use-after-free if you never free... ;P

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 6:01 UTC (Tue) by TheGopher (subscriber, #59256) [Link]

Brilliant! Thanks for this one.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 20:22 UTC (Fri) by FSMaxB (subscriber, #106415) [Link]

It's really great to have something I've known for years be backed up with empirical data in such a spectacular fashion.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 3, 2022 11:10 UTC (Sat) by pawel44 (guest, #162008) [Link]

'Memory safe languages' means nothing IF you sacrifice performance. I'd like to see performance analysis before and after.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 3, 2022 16:04 UTC (Sat) by raven667 (subscriber, #5198) [Link]

That's a trade off not an absolute and many/most projects probably benefit more from automatic safety than they lose in performance. Checking memory access, locking objects, etc. costs _something_ regardless of whether you do it yourself by hand or whether the language/library/runtime does it for you automatically, and the performance gain from omitting those checks isn't worth it if the program no longer works reliably.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 3, 2022 18:16 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Ah, the old "it I can go 100 mph, it is unconditionally better than 80 mph" argument that ignores the fact that the track is full of potholes and ramps into the abyss and going a *little* bit slower lets you keep to the well-paved sections. Put another way: I don't know what kind of sadist would want to watch (or masochist racer participate in) any race where brakes weren't allowed.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 7:58 UTC (Mon) by pawel44 (guest, #162008) [Link]

"Ah, the old "it I can go 100 mph, it is unconditionally better than 33 mph" argument that ignores the fact that the *driver in faster car is much smarter and more experienced* [...] and going *ways* slower lets you finish last."

Fixed this analogy for you.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 17:57 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

While I certainly don't claim expertise to the level necessary for such things in the languages in question (C and C++), I do work with the day-to-day and I *highly* doubt that there is any team with enough collective attention to not continue hitting problems on a regular basis. Even the Linux kernel doesn't get this right often enough for my tastes (given how prevalent the project is) and I don't think anyone is saying that the (regular) Linux kernel developers are less than excellent on the whole. I suspect the only balancing point that makes sense is:

- narrow scope
- single developer
- easily fits in said developer's head

Of course, that last part tends to fade away with time.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 19:37 UTC (Mon) by pawel44 (guest, #162008) [Link]

Of course, I agree. I believe factors such as developer experience and proper quality control are even more important than the language used. With memory safety languages, it may be easy for some to write a 'secure' application (or any other), but not so reliable. Messenger is a good example in my opinion. It's bloated and very buggy on my Android phone. Had there been proper quality control, it would never have made it to the Google Play Store.

Regards.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 20:09 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

There are a number of Google products that feel very incomplete and half-assed (and not the right half either). My pet theory is that they are on-boarding projects to sink new hire teeth on before they're shuttled off to somewhere more "useful".

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 0:06 UTC (Tue) by atnot (subscriber, #124910) [Link]

It is kind of the opposite. Google has in the past, out of fear of missing out on the next big thing, heavily internally incentivized "launching" new "products". To the point of it being the only real way of receiving promotions.

It's not that they don't have the skills to make good products. It's just that you get further by launching more bad products into the shredder instead.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 2:41 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Unfortunately, one of the worst is now a flagship product in the main lineup (Google Chat). FWIW, I also consider GMail to bottom-of-the-barrel these days. The HTML view for "slow internet" is *way* faster than the standard interface and all I go there to do is change filter settings.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 5:58 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I believe factors such as developer experience and proper quality control are even more important than the language used.

This argument comes up regularly in discussions about memory safety despite overwhelming evidence.

I've always wondered what kind of fantasy workplaces can afford to do this. Does any exist for real?

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 16, 2022 3:31 UTC (Fri) by njs (subscriber, #40338) [Link]

> I believe factors such as developer experience and proper quality control are even more important than the language used. With memory safety languages, it may be easy for some to write a 'secure' application (or any other), but not so reliable.

Of course you can believe what you like, but the facts we have in front of us in this article are:

- Google made absolutely massive investments in C/C++ quality – sanitizers, fuzzing, language extensions, the MiraclePtr effort, ... – and they still shipped apps with lots of security (and other) bugs. All that stuff has benefits for sure, but none of it moved the needle on these metrics

- They started intentionally using Rust/Kotlin/etc in places where they had previously used C/C++, and this *did* reduce security (and presumably other) bugs.

At this point, arguments that C/C++ are fine if you're just careful/skilled enough are like believing that bad things never happen to good people. People only believe it because it makes them feel good, and let their emotions override objective data or rational judgement.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 8, 2022 4:33 UTC (Thu) by flussence (subscriber, #85566) [Link]

To complete the analogy, the driver in the train can go 200mph without racecar driver reflexes *because* it is safe.

Languages performance

Posted Dec 3, 2022 21:33 UTC (Sat) by stephen.pollei (subscriber, #125364) [Link]

I found benchmark that places even slowest language at 25 times slower than c. rust is likely in same ballpark as c and c++. java, c#, go are likely within 3 times slower. At the moment, rust seems like it could be slower to develop in then a few other languages.

for a lot of projects, the performance of java, c#, and go are good enough. If they need faster then they'd have to choose between c, c++, zig, and rust. For rust, likely will be more difficult to find programmers skilled in it and likely will need to budget in more time for development.

There are other benchmarks that give slightly different answers on how much performance is lost. YMMV

Languages performance

Posted Dec 4, 2022 5:22 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

> At the moment, rust seems like it could be slower to develop in then a few other languages.

This may be true. Beware of people making stronger statements than that. It is inherently difficult to empirically validate general claims about development time or effort. This is because of a combination of the Hawthorne effect (when people know they are being studied, they work harder), and various software-specific issues identified by Fred Brooks, most importantly the non-fungibility of developers and software projects.

Rust might be slower than other languages, ceteris paribus, or it might not, but real life is not ceteris paribus, and other confounding variables should also be considered. Use the language that best fits your requirements.

Languages performance

Posted Dec 4, 2022 7:22 UTC (Sun) by stephen.pollei (subscriber, #125364) [Link]

Yes, I'm conjecturing based on limited data. Using Rust at a startup: A cautionary tale by Matt Welsh and a few second-hand sources. Rust seems like an interesting language and I'm very ignorant about what it is like to actually use it. Even if it is slower to develop in and remains slower for certain projects, it still might make a lot of sense for many projects. Things certainly are not ceteris paribus; As developers gain experience with this new language, libraries and documentation mature then it will be a more even test.

Languages performance

Posted Dec 5, 2022 18:03 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I'd say it's something like this:

- Rust is faster out of the gate (cargo beats autoconf, meson, CMake, etc. at getting the basics in order).
- C and C++ allow for quicker initial iteration because the compiler lets you get away with stuff while Rust requests more up-front design work.
- Once established (MVP or similar), the Rust project is likely to be faster as there is not a gamut of instrumented CI builds to wait on for every MR (to paper over gaps the compiler can't notify about).
- Maintenance is *way* better in Rust because I'm not tracking down memory problems in `gdb` or `valgrind` and instead dealing with (usually) structured errors and messages instead of random memory corruption.

So where Rust falls behind is a place that would help C and C++ projects *anyways* if it were done: a little more planning ahead about the overall terrain the project will apply to.

Languages performance

Posted Dec 4, 2022 7:47 UTC (Sun) by d4no0 (guest, #115694) [Link]

I totally agree, a language is just a tool to accomplish your task, each language has ecosystems best suited for their areas. When I hear people wanting to use rust for developing web servers, motivating that on language popularity and "performance" it makes me question their skills as an engineer. At the end of the day an engineer is supposed to solve a problem, but not write code for the sake of writing more code.

Languages performance

Posted Dec 4, 2022 13:14 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

I guess this depends what you think "web servers" means. If we want to correctly serve maybe 100 simultaneous users of this site that's mostly calling database procedures as they click on stuff I agree that Java and C# makes lots of sense, but I'm just not sure I'd call that a "web server". I spend a lot of my working hours doing this stuff, in C#, it's not exactly thrilling but it works, so why change it?

On the other hand Rust might very well be the correct choice to write a replacement for Apache httpd / nginx / IIS / etc. which are what I think about as a web server.

Languages performance

Posted Dec 4, 2022 20:29 UTC (Sun) by stephen.pollei (subscriber, #125364) [Link]

Yes, I read recently that CloudFlare is replacing many uses of nginx with something they are writing in rust.How we built Pingora, the proxy that connects Cloudflare to the Internet ; Cloudflare is moving away from NGINX | The Backend Engineering Show .

CloudFlare claims, "Having a developer friendly interface engineers are familiar with while eliminating the previous constraints allows us to develop more features, more quickly." . This is different than the other project that I referred to. They also seem to claim that it allowed them to do better multiprocessor optimizations realistically and thus be more performant in practice than other languages. It seems like there are a lot of interesting project happening with rust

Languages performance

Posted Dec 5, 2022 6:01 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

If it's the same engineer, with roughly equal skill in both rust, and an interpreted language like java or javascript, it's likely rust will go faster. It's not totally unreasonable.

Hotspot claims notwithstanding, interpretation imposes a noticeable overhead, and GC, even the latest ones in java 17, still gets you with tail latencies. And in k8s, I've even seen the overhead from java running (relatively speaking) like molasses until most of the classes are loaded, impact how you provision autoscaling.

If it's two different engineers, with different skills (particularly if the first is gone, and the new one has less experience in the given domain), then, yeah, making a blanket statement like "rust will be faster" is questionable.

As far as maintainable, yeah, it's a curate's egg, that one. I love the Rust language, the language itself is reasonably mature, but the existing libraries / frameworks for web serving are very immature.

I like Java (although people abusing Optionals and Streams is getting tiresome, basically autocomplete encourages people to stop making methods, and just chain a bunch of fugly lambdas together, and Spring *sigh* I use it, but *sigh*, known bad practices, per the Spring engineers, are still endemic to Spring code), but the frameworks & libs are better than what Rust has.

Javascript is alright. Particularly in terms of ExpressJS being at pretty much the perfect level of abstraction for how I think. But even with async / await, callback hell persists. And nodejs can have impressive performance.. until it doesn't, and it's still overhead you won't have in Rust.

So, without context, if someone says "Rust will be faster".. hey, they might be right.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 15:31 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

I think this is a crazy attitude. There are plenty of applications where performance is absolutely not everything, especially on mobile platforms that are the topic of the original blog post. It makes no sense at all to program in a low-level, memory unsafe language like C or C++ if the program is doing something so simple it can work fast enough using a memory safe language, or if it will limited by network latency even if written in something slower but safer.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 19:38 UTC (Mon) by pawel44 (guest, #162008) [Link]

The problem is that mobile apps are still annoyingly buggy. Moreover, their latencies (including core Android apps) are too high. Sometimes I miss a call when I accidentally turn on the camera. However, this is probably a more complex issue than the language itself. IMHO it's quantity over quality and 'inclusiveness' over skills.