Google is (not) bringing Fuchsia OS to Android devices | Hacker News Reader

Google is (not) bringing Fuchsia OS to Android devices

androidauthority.com

50 pointschildintime58 comments

I find that writing which speaks of Google as a single "it" misses the mark. I say this because the Googlers who write here show many disparate views and pressures to deliverable.

Sure, we think "there is one vision" but I suspect, there will be people inside the tent who still think this is a good idea, or a variation of it, and so (not) is mostly conjectural, because nobody who CAN say with authority what is or is not being done, is going to want to commit until they understand how it affects their KPIs.

Considering why Google acquired Android in the first place, Some of this is a bit bizarre. You would think by now, there was a roadmap which made sense across the generations. We're at Android 15. Thats an awful lot of time in that model of the world and Fuschia is on what release trajectory?

I find that writing which speaks of Google as a single "it" misses the mark. I say this because the Googlers who write here show many disparate views and pressures to deliverable.

That doesn't matter if you're talking about a boolean outcome or the actions of the company as a whole. There could be 50%+1 person on one side of the internal debate and 50%-1 person on the other, and everyone outside of the company would still say "Google" to refer to the collective outcomes and actions of everyone there. The subtleties of what happens behind closed doors doesn't matter.

Individually Googlers are a disparate bunch. Collectively, they are "Google".

This is the case for every company, not just Google. I've been the one internally trying to stop us from making a bad decision which ended up being made anyway. I can't distance myself from that. For everybody outside, there's only the company. My dissent as an individual doesn't exist out there.

Right. And Google isn't a democracy either (nor should it be). The numbers on the winning side might be small. But as you say, “it” is what it does.

It might explain an apparently erratic behaviour. Continuously alternating priorities, indecision, that sort of thing. Multiple actions, some aligned with "still promoting Fuchsia", others with "we're abandoning it".

The "Stadia isn't going anywhere" announcement weeks before killing it comes to mind.

There's a pattern here of not invented here and Google forever obsessing about injecting their own versions of things. Android brought in a lot of technology not controlled by Google. Java, mobile Linux, stuff like that. It rejected Java for systems programming and came up with Go. And of course with Go they built their own compiler instead of building on the llvm ecosystem as well (unlike what Apple did with Swift).

It also rejected Java for frontend programming on the web, and Dart became a thing. Which eventually got repurposed for Flutter so they could get rid of Java on Android too. Early on, it started funding Firefox. But then it partnered with Apple on Webkit only to fork that into Chrome. And of course they then came up with Chrome OS (a linux based OS running their own browser. With Fuchsia the goal was to replace Linux and have a whole Google only stack and replace both Chrome OS and Android.

One thing that keeps on happening to Google is outside innovation making their internal efforts redundant. And because Google is so big, it usually doesn't take long for external stuff to start getting used internally and become more or less strategic. Dart/flutter solved a problem. But they never really got rid of Java. And then Kotlin came along and largely replaced Java on Android largely removing the need for Flutter. Flutter is not dead. But at this point it's also clearly not replacing Kotlin.

And Google's own Jetpack Compose was built on top of Kotlin in parallel to Flutter. Jetbrain's multiplatform version of that, which is now targeting everything that Flutter was targeting (IOS, Web, Desktop, Android), is starting to look pretty solid. Google just endorsed kotlin multiplatform at Google IO as well.

And you'd be wrong to dismiss Kotlin as a frontend only thing because at this point Amazon, Facebook, Google and most other big Java server side users are also deploying Kotlin for that at scale. These companies have many millions of lines of code of Java of course and that's not disappearing overnight. But they are increasingly treating that as legacy code and transitioning to Kotlin for new projects.

On the system programming side, Go has worked really well and it's pretty popular. But it did not really displace Java/Kotlin even inside Google. And now we have Rust popping up everywhere as a better C++. Including places like the Linux kernel. Rust is popular especially for things that need to be fast and secure. So, Go is kind of sandwiched between those ecosystems now.

The pattern here is Google having the right analysis about what needs doing, work on some internal solution, only to then have external solutions popping up that that remove the need for Google's in house thing.

This latest effort to reinvent sandboxing and salvaging some bits of Fuchsia needs to be looked at in the broader trend of people using WASM for that; especially server side. But of course WASM runs great in Chrome too. And thus on Android/Linux.

It was the Plan 9 refugees that rejected C++ and came up with Go, and then they were surprised most C++ folks couldn't care less about Go.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

people write silly comments like this all the time.

Google and Googlers makes lot of dumb choices all the time, but comments like this always miss the mark.

> Google forever obsessing about injecting their own versions of things.

many things Google did their own version of is because it didn't really exist anywhere else. some examples:

- mapreduce - flume - bigtable - spanner, both the mad original one and the new one - borg - fairly secure containerisation - industrial scale monitoring - industrial scale logs processing - industrial scale static analysis for shitty languages like Java and C++ - industrial scale profiling

all of this things were printing money inside Google for many many years before anything equivalent existed outside.

etc

> It rejected Java for systems programming and came up with Go

no, no one uses Java for "systems programming", and Go was some extremely senior engineers deciding to invent a new language/toolchain because they hated writing C++.

> with Go they built their own compiler instead of building on the llvm ecosystem as well (unlike what Apple did with Swift).

who was using LLVM for new, light, fast-compiling languages in 2006?

> It also rejected Java for frontend programming on the web

everybody, at every company in the entire world, including Sun, rejected Java for frontend web programming.

> , and Dart became a thing. Which eventually got repurposed for Flutter so they could get rid of Java on Android too.

that's obviously untrue?

> Early on, it started funding Firefox. But then it partnered with Apple on Webkit only to fork that into Chrome.

it's an advertising company worth a trillion dollars, "ensure web browsers work well on multiple platforms so our ads can be shown" seems like a pretty obviously correct business choice.

> And of course they then came up with Chrome OS (a linux based OS running their own browser.

unsurprisingly, as web browsers became more functional and humans wanted to maintain PCs less, systems like this and iPadOS came to into their own.

> With Fuchsia the goal was to replace Linux and have a whole Google only stack and replace both Chrome OS and Android.

fuschia is/was a project to get a modern security model and to escape from the nightmare of SoC vendors never ever ever ever caring about drivers.

> One thing that keeps on happening to Google is outside innovation making their internal efforts redundant.

for sure things outside later appear. that doesn't mean that Google was wrong to spend person centuries on their internal thing, if they got > person centuries of value in the meantime. it also doesn't mean that just because for example they're both called "distributed KV stores" that migrating from BigTable to HBase would be a good idea. obviously sometimes Google should move to a more successful external thing, but the costs of doing so for anything that was successful internally are comically high.

> And because Google is so big, it usually doesn't take long for external stuff to start getting used internally and become more or less strategic. Dart/flutter solved a problem. But they never really got rid of Java. And then Kotlin came along and largely replaced Java on Android largely removing the need for Flutter. Flutter is not dead. But at this point it's also clearly not replacing Kotlin.

because Google is so big and historically wealthy, it quite deliberately willing to try four vaguely similar things and see if any of them work out. that was not seen as a mistake.

> On the system programming side, Go has worked really well and it's pretty popular. But it did not really displace Java/Kotlin even inside Google.

no one ever intended Go to replace Java or Kotlin - obviously? Java is a higher level and more annoying language, and Kotlin didn't exist at all until 4 years after Go was started. even the creators of Go didn't intend to replace Java, they wanted to write less C++.

> And now we have Rust popping up everywhere as a better C++. Including places like the Linux kernel. Rust is popular especially for things that need to be fast and secure. So, Go is kind of sandwiched between those ecosystems now.

ok? it's great that Rust is doing well. what does that have to do with anything else? Go started in 2007, should no one have invented non-runtime-based languages in 2007 because Graydon had stopped working on Monotone and started writing a toy language in OCaml in 2006? or that Google should stop funding Go now? why would it stop spending a tiny amount of money to sustain a pretty useful (and also quite shitty in some ways) language? it has millions of LOC of Go code internally now, too. telling Go developers they'll only be writing Rust now isn't a way to get more Rust developers, it's a way to get resignations.

Go also avoided one of the other traps Google usually fell in to when solving problems it had and others didn't - opensourcing it instead of just writing a paper and then letting some Apache project take all the mindshare.

> The pattern here is Google having the right analysis about what needs doing, work on some internal solution, only to then have external solutions popping up that that remove the need for Google's in house thing.

lol. I assume you've looked closely at how Go and Rust work in google3? and the different problems they are used to solve, and then determined that the cost of re-writing all in Rust and re-training everyone and re-writing all tooling is worthwhile? that's a fascinating claim.

I think fundamentally, people just like making dumb assertions about big companies that seem - and are - dumb, like Google. all of the above is public domain knowledge that you could have looked up instead of writing 250 words. you got lots of facts wrong, you don't seem to appreciate that big organisations inherently - and deliberately - try multiple things that you feel overlap, you seem to not understand how cost/benfit and RoI work, etc.

just...why? there's so much to criticise Google for, I don't get why people bother to do it but put so little effort in to it.

This project has been a complete cluster f since the beginning. I was excited when it was announced, though it seemed to get more and more relegated to nothingness since.

Now it's going to run in a VM in an already 'slow' os? For what possible reason?

I feel pretty much the same, and I suspect it's not an uncommon take. When it initially became known publicly, it seemed like they might be looking to try to make a legitimate competitor to Linux in the long term, but (and potentially be the first OS to make a compelling case for both desktop and mobile, which I still feel like we haven't seen anyone do yet), but at this point, it seems like they really don't have any concrete plans for it.

In hindsight, Fuschia is a pretty good representation of my opinion of Google as a whole since it first became public in 2016; eight years ago it was a lot easier to believe that they had some sort of big-picture idea of what they wanted to do, but nowadays it feels a lot more like their major products are basically just coasting on inertia, and nothing new they try to do has any sort of coherent long-term plan.

Android is not a "slow" OS. At least not at the kernel/virtualization level.

Not even at userspace level, people keep forgetting since Android 5 most code has been AOT compiled, and additionally with PGO information, alongside a generational moving GC.

What makes Android ‘slow’ OS?

Unironically, Google Play Services

This isn't my simply having a go at Google, either. Google's assumption is that everyone is on a device released in the last 4 years - it's hard to argue with, and must be all but impossible internally, because the XDA Forums-adjacent geeks that root and ROM, re-flash and ditch GApps are a minority. The actually crazy ones that say "Google Play Services aren't worth it" are a minority of a minority, and by definition wouldn't show up in Google's stats of active devices; without Google Play Services, they aren't going to show up at the mothership.

So all the data they have indicates that people don't use slower, older, devices. So Google Play Services is allowed to be heavier, because packing more and more in is both more useful to Google (more data means better traffic predictions, better ad tracking, etc.), and likely easier (I do not need to tell HN that un-optimized software is generally easier and faster to write, and typically preferred by the upper echeleons of management). All this with, as far as Google is concerned, no downside! It chugs on a 6 year old phone, but people don't use those.

But even without rooting my previous phones, uninstalling everything Google via ADB gave them new life. The BlackBerry KeyOne, possibly my favourite Android ever, was binned for being slow on release. Dropping Play Services let me use it till I switched to a Linux-first device last year.

It's not Android - it's Google's add-ins.

I'm not exactly sure, but probably what the sibling comment says. I have been out of the 'scene' for a while, but it used to be possible to go onto XDA and find some Lineage or other debloated image, install it, and the difference was night and day. It felt like you were using a whole new phone, in fact.

Aside from Play Services, I assume most of the slowness comes from all the mfg and carrier bloat. A brand new Samsung comes with something like 32 apps I uninstall/disable, some through ADB.

I guess by now, even its use on Google Nest Hub isn't even certain.

I had high hopes for the project, but it looks like a keeping engineers busy kind of thing, a pure cost center, without any revenue to keep it going besides Google Nest Hub being shipped with it.

It's a wonder how it wasn't axed already.

A new operating system done right gets engineers salivating and a lot of very senior staff have personal attachment to Fuchsia.

Personally I think it's a lost cause; every few years they change direction in hopes of finding a concrete use case that doesn't displace some existing Google project. The Nest was Fuchsia's greatest achievement and even that was held together with strings and glue behind the scenes.

I believe Fuschia and usage of Dart for projects like Flutter grew out this back-and-forth legal rigamarole between Google and Oracle over Java.

Plus, I believe at the time there was some core Chrome developers Google wanted to retain and keep busy with developing Flutter.

These are all cool projects, and there are hardly any companies developing actual operating systems nowadays. It would be sad to see it go, but on the otherhand, I haven't seen folks outside of Google use this OS despite its strengths, and perhaps that's the real problem

> I believe Fuschia and usage of Dart for projects like Flutter grew out this back-and-forth legal rigamarole between Google and Oracle over Java.

I'm guessing nowadays Kotlin plays this role? Its multi-platform nature means that the Android world can eventually be detached from the JVM backend, if I understand correctly.

In the mid to long term I think Kotlin and KMP are likely to be where Google puts its effort. Flutter is likely toast but it will be some time before KMP is polished enough to replace it.

I've used Flutter and Kotlin MP. There's zero reason for me to believe Kotlin MP is superior, so why would it replace Flutter???

Because of flutters lack of success and company politics.

I mean Kotlin has actually been adopted outside of Android. Maybe it's my bubble but I've never come across an actual Dart / Flutter job.

for the simple reason that with dart / flutter you don't need a huge team. 1 - 2 people are enough.

one codebase to cover web, android, iOS and desktop apps.

and for that simple reason, flutter won't go away. no other UI development framework comes close to the productivity of flutter.

I like Flutter a lot and I think right now it's much more capable and mature than KMP is. The problem is Google is in aggressive cost cutting mode and it's not clear how Flutter contributes to their bottom line in a meaningful way. It's not hard to make the business case that they should shift the considerable resources they now invest in Flutter to focus on Kotlin/Compose and let JetBrains do the heavy cross-platform lifting.

I hope this doesn't happen but as long as Google is willing to cut engineering resources even while they're recording record profits it's hard to be confident.

> it's not clear how Flutter contributes to their bottom line in a meaningful way... focus on Kotlin/Compose and let JetBrains do the heavy cross-platform lifting.

Why do you think Kotlin MP would contribute to JetBrains' bottom line when at the same time you think Flutter does NOT contribute enough to Google's?

I get it, Google's bottom line is on another level, but at the same time, if someone can afford to invest on technologies that do not bring in any profit, that's Google if it thinks it increases its reach, which Flutter/Dart do in a way that Kotlin cannot, given Google controls them but not Kotlin (though you could make a case Google effectively controls Kotlin, at least somewhat?).

JetBrains sells very expensive tooling around Kotlin & KMP. If it takes off their path to profit is pretty clear.

That said, building a really good cross platform UI toolkit and framework is really hard. It remains to be seen if JetBrains can pull it off.

The thing is, KMP might make money for JetBrains, but Google has not yet bought them yet, for reasons I still cannot fathom.

Indeed, their little marriage is the only reason Kotlin matters in first place.

No, reimplementation of the Java standard library was the core issue in that lawsuit, and Kotlin akso uses the Java standard library.

Indeed, people keep telling Kotlin was a way out of the lawsuit, while forgetting Kotlin, Gradle, Android Studio, and whole whole Android SDK run on Java / JVM.

Even with ART, Kotlin withouth the richness of the Java ecosystem at Maven Central is worthless, hence why after the whole Kotlin push, now ART is modular and updated to more recent versions, currently Java 17 LTS. Via Play Store updates from Android 12 onwards.

Kotlin was pushed by a couple of folks with managment powers, given the team marriage with JetBrains, and a way to push common interests with Android tooling.

The thing Oracle was suing over is the thing you have to have in order to run any Java code at all. And most of Android's API surface is built in Java - including the APIs Oracle was suing over. Those can't be removed, and if you try, you're going to split the ecosystem ala Python 3.x. Android can't work without Java.

This, BTW, is why the entire FOSS world was shitting itself over the Oracle lawsuit. If they were to win, it'd trigger a cascade of other companies claiming interface copyright over every competing OS and library that has a similar interface but is not entirely a compatible reimplementation[0]. The problem is that programmers thought interfaces weren't copyrightable and thus have been doing the whole "embrace and extend" dance for decades. Think less WINE and more GNU: something that's very explicitly Not UNIX, is sorta-kinda compatible enough with it, but also has a lot of its own weird extensions. That's what Oracle thought shouldn't be allowed.

Fuschia replaces things lower level than the Java APIs - things Oracle doesn't own. That's the Linux kernel and a good chunk of Android userland[1]. If, say, SCO were to somehow come back from the dead with some new bullshit legal claim to the Linux kernel, then yeah, Fuschia could get Google out of that kind of a jam. But that isn't the case right now.

[0] Existing Ninth Circuit[2] precedent regarding, of all things, PS1 emulation, precludes suing over compatible reimplementations of existing interfaces. The problem with Android was that it wasn't compatible; they'd taken some but not all of the Java APIs, which was against Sun policy. Sun didn't want partial implementations or extensions in the wild. In fact, Sun had already successfully sued and won against Microsoft for shipping MSJVM with COM bindings.

[1] Which, funnily enough, contains no GNU code so you can't call it GNU/Android.

[2] Yes, the lawsuit was in the Federal Circuit, not the Ninth Circuit.

Basically Google has the resources to write their own OS and their own alternative to Java, so they did so as an escape hatch.

And Fuschia+Dart+Flutter runs perfectly fine. There's nothing wrong with them. Should Google keep pouring money into them? YES. Absolutely yes. But do they need 500+ people on each project? Probably not. Remember Google has on the order of 100,000 software engineers.

Replacing an already very successful OS with a rewritten one, including a completely new kernel -- that would fundamentally break backward compatibility. And therefore it simply doesn't happen.

Only Apple could perhaps pull that off by forcing it on everyone by way of controlling the hardware base. Google and Microsoft don't have that amount of control.

Agreed. RIP Blackberry and also Palm, who tried and failed to introduce new OSs.

The Fuchsia team is working on a Linux compatibility-layer, named Starnix[1], which is much like WINE on Linux. This would allow Linux applications to run on Fuchsia as-if they were running on a Linux kernel. A massive amount of work, but less work than adapting every single existing application to run on Fuchsia.

Back in 2022, there were signs[2] that Google was working on testing the Android Runtime (ART) on top of Starnix, by trying to get the clock app running on top of it. Most of this work has been done in private though, the tracking-issues mentioned in the article were quickly set to private after they were found.

[1]: https://fuchsia.dev/fuchsia-src/concepts/starnix [2]: https://9to5google.com/2022/07/15/android-removes-fuchsia-co...

Interesting. I guess this isn't so impossible then. Still, it seems they would need a very strong will in the company, up to Sundar Pichai, to really commit to switch over Android to Fuchsia. Which likely requires a large and years-long developer effort until the switch can be made in a reasonably seamless manner. But the management will likely ask whether the advantages (better security?) are worth such an investment.

> testing the Android Runtime (ART) on top of Starnix

It reminds me how early Wayland compositors barely could ran on bare hardware and worked as X11 clients for testing purposes, hehe (many, like Weston or Cage, still can).

I really believe we are not able to ship big new software projects anymore. If there isn't a pile of garbage to build up on...it's going to be vaporware. What a shame I was really excited about fuchsia in the beginning.

Big software projects still get shipped. You're just less likely to hear about them unless they're developed at FAANG.

Are even more one-and-only-corporation-controlled-software did not excited me at all.

Heterogeneous components software may be suboptimal, well it is, but at least is not ramsonware technology.

If you want to be able to run Fuchsia and Fuchsia apps on devices without having to first install a complete new OS - which might require root - this seems like a great advancement.

For me, if there's a Fuchsia app on the Play Store, or one I can easily sideload, I'll definitely try it out.

It could just be a stop-gap, or a low-risk test. They haven't said that it won't properly come to Android devices - if anything, this shows that there is interest for it.

Wouldn't it be a problem for Nest devices running on Fuchsia OS to get the hardware support they need? Most companies building consumer electronics products rely on hardware vendors to provide working kernels, drivers, etc. Speculatively, if you were able to leverage Android/Linux hardware support without the overhead of the rest of the Android OS, that would free up Nest from having to handle that problem.

I translate this to: even google doesn't have enough leverage to force chips vendors to write drivers for fushia when linux is so ubiquitous.

When Fuchsia first came out, I was interested to go deep dive into it and be an early adopter/contributor. Good that I did not put in my time investment. There is always a risk with new projects but with Google there seems to be a longer wait and watch phase before you really double down on the project.

>It’s not clear why

What Google revenue streams would full Fushsia cannabilize? Lack of USB->HDMI also bummer on pixel devices. I could probably convince a lot of people to migrate to chrome/fuschia/google OS if all it took was slapping their old phone to a usb hub. Well I could a few years ago, google kill services / lack of direction have put me off recommending any service by them. Still, seems like Google has a pathway to get into the Apple hardware game but simply chooses not to.

Lack of USB->HDMI also bummer on pixel devices.

Google Pixel 8 supports DP-Alt, including USB-C to HDMI adapters:

https://support.google.com/pixelphone/answer/2865484?hl=en

> Select the Mirror display dialog that appears on your phone.

So you're still completely screwed if your screen breaks.

My pixel 4a screen broke and I found there was absolutely no way at all to access files on it. There are a ton of workarounds that work on some phones (e.g. on Samsung phones you can just connect them to a screen & mouse/keyboard) but nothing works for a Pixel 4:

* Asking Google Assistant to cast your screen to a Chromecast brings up a confirmation dialog you can't use (keyboard doesn't work; mouse is too tricky without being able to see anything - I did try and fail to do it blind.)

* TalkBack doesn't work

* Can't access the files over USB because it doesn't default to file access mode.

* Can't even unlock it with a keyboard because I used pattern lock and that doesn't support keyboard input (didn't make this mistake on my new phone).

* There's no longer an option to connect it to a new phone via USB and transfer all your data.

Does nobody drop their phone in Google?

> Does nobody drop their phone in Google?

They obviously want to sell you on google drive/google one as your backup.

Oh no, who could’ve thought that Google won’t replace most popular OS in the world with experimental thing that has nothing behind it but tech journalist hype?

> nothing behind it but tech journalist hype

It's been shipped to millions of devices, quietly.

> It's been shipped to millions of devices, quietly.

yeah...to wide unhappiness and many demands for refunds...

https://www.google.com/search?q=fuchsia+update+nest+broken+s...

The minority of those issues are for the fuchsia update, despite your lame attempts at searching. The simple fact is that they pulled it off, and many millions more are shipping with it without a problem.

So what? Millions of crap has been shipped.

This is pale compared to original of “here’s a killer of Android”.

And here we are, where Android is consuming Chrome OS and will be dominant platform for foreseeable future.

I didn't say it was an Android killer. I just said that it wasn't vaporware hype - since it's shipped and lots of people have been using it. You made the rest of that up in your own head and then got mad about it.

> You made the rest of that up in your own head and then got mad about it.

https://news.google.com/search?for=fuchsia+android+replaceme...

Lmao.

Android is going to eat Chrome, so would not be surprised to see Fuschia team layoffs as well as Chrome OS team layoffs in the next few months. Hard to say but from a revenue perspective the non-Android teams look as redundant as much of Motorola.

https://blog.chromium.org/2024/06/building-faster-smarter-ch...

Reply on news.ycombinator.com