Android has been trying to fix this with treble[0], which will make many more phones get OS updates going forward. So Android has attempted to work around one of linux major problems.

Another large problem is that Linux was designed for desktop architectures. It's design and focus continues to go that way. This has impact across an entire range of functionality that an OS is supposed to bring.

Fuschia seems to be a research project with a focus on mobile/laptop type devices. It could care less about server type environments, which lets it make different tradeoffs in design.

[0] https://source.android.com/devices/architecture/

Android changed Linux kernels with every single release, from 2.6.27 to 4.10 by core release, and vendors often update kernels incrementally in between. Any driver issues are trivial to change presuming they didn't come in a binary blob and the source refused any further changes, which is supposedly the case with Qualcomm hardware in the Nexus 6, for instance.

"Android has been trying to fix this with treble[0]"

Treble is about the intra-Android interfaces, not Linux device interfaces. This is about Google doing large scale, breaking changes that made vendors just throw up their hands.

"Another large problem is that Linux was designed for desktop architectures"

Nope.

The reality is that everyone always thinks they can rebuild it better. Second (Third, Fourth, etc) system effect. It the very basis of NIH syndrome. So some small group at Google wants to research OS'. Whatever. The likelihood that this replaces Android, or that it is in anyone's imaginations that it actually will besides content writers outside of Google, seems very low.

This is why all of the Google's code sits in one big repo (reportedly). It allows them to refactor all dependent code at once when changing interfaces.

The problems they are likely trying to solve are business and legal, not technical. Pesky things like not having to release keys bits of code under a 'free' license (i.e. they have no choice but to release any changes to the Linux kernel under GPL as that's what it requires.) Sure, they'll probably still release large chunks of source code (possibly under MIT/BSD, possibly under a less liberal license) but keep strategic bits closed source. Right now they have to do this via the clunky and somewhat obvious Google Play services layer. And then there's the constant potential exposure to lawsuits. etc.

By being able to decide on what pieces would be released under what licenses, it would allow them to prevent competitors from following in their footsteps as Amazon and various Chinese companies have done with Android. Things like this are the reason Samsung (one of Google's largest problems) keep pushing forward with their Tizen platform so that when the shift comes they have the ability to sidestep it if they want to.

There is a ton of cruft in the APIs, like any large project would have.

One of the engineer in the Android framework team described creating APIs as generating future regrets.

Some of the mistakes are pretty small. Like internally the system reuse drawable instances in order to save memory, but instead of making this process entirely automatic, before calling let's say `setTint(color)`, you need to call `mutate()` so the UI framework spins a copy of the drawable for you. it would have been easy to integrate this behavior by default without having you know about mutate but since it was done differently, this behavior has been preserved in order to do not break retrocompatibility.

There are many small API issues like this. Big issues of course are corrected but often preserve the old behavior in case you are targetting an old version of the OS.

The View system is incredibly complex. Some of it is due to the inherent complexity of the problem, but some of it is due to the constraints of the time and some decisions that could have been better.

So there are many things you can improve by restarting from scratch and it is often easier than having to deal with the legacy APIs too.

I don't know if Linux/Fuchsia meets those criteria, but given that there are extremely smart people at Google working on it, I would think that it's at least plausible.

IF you consider that there are some fundamental flaws in the Android Framework at the surface level, either oversights or just based on what the landscape looked like 10 years ago, then we have to reach a tipping point where it makes more sense to do a full rewrite than to continue building on this codebase.

FWIW, there are major incremental improvements made at each release, most of them with very few changes to the high level APIs.

The VM itself evolves at each release and has even been completely replaced from Dalvik to ART. The permission system has moved from install time (designed by engineers .. ) to iOS-like incremental runtime permissions.

Not everything can be updated that way though. So it might be worth redesigning the OS with better assumption about its usage and by totally rewriting the APIs from scratch in order to avoid the mistakes made by Android (of course Fuchsia will also make some mistakes in its APIs .. all immense projects do, it does not mean that it can't improve on Android)

And I don't think the OP article applies very neatly here. Android is still being worked on and is constantly improved. We are not in a situation where Android's development is going to freeze for 5 years while Fuchsia is being worked on. Completely different teams work on the 2 projects.

If anything, Fuchsia has a lot of pressure in order to catch up with Android. And it might want to start supporting kotlin so that the dev experience gap is not too wide and to add an Android VM for retrocompat before starting to consider competing with Android.

I doubt this is really a big deal for Google, but a capabilities based OS lends itself a bit better to the mobile OS security model.

There's basically nothing new in the Bloomberg article.