There was internal turf warfare going on over whether tablets should remain Android devices or Chrome OS should take over that form factor. Rumors were that the Pixel C tablet was originally meant to run Chrome OS but it ended up shipping on Android.
I would say that turf warfare is still going on, e.g ChromeOS vs Android vs Fuchsia, or PWAs vs Java vs Kotlin vs Dart.
If you want to have a glimpse how Android team feels about Flutter, just check this year's Android Fireside and how they react to questions about JetPack Composer vs Flutter, or what should be the way to develop on Android.
Mostly political correct answers with some pauses trying to think how to best state them, and facial expressions revealing how they rather not answer it at all.
Let me make one thing very clear: nobody gives a flying fuck about Fuchsia. Nobody. It was and remains a project that people who want to do something fun go to when google thinks that they are valuable enough to keep around.
It is not the future of anything. It is not even remotely capable of doing anything serious. For fuck's sake, go look at the code - it is all out in the open! The scheduler is a JOKE. SMP support too. Power management is nonexistent. Driver support? HAHA!
The most important part about message-passing microkernels? The tuning for the message-passing. None of that is anywhere to be seen either...
Oh, and app support.. Where is that? Yeah, one could go the chromeos way and try to make an android compatibility layer - it is very hard and never 100% compatible, and relies on having a linux kernel. And then why bother with a new OS? Or one could go the microsoft way and pay app developers to write apps for the new SDK. How did that go for windows phone? Or one could make a VM and run android in it, but then why bother with a new kernel anyways, if everything will be in a linux vm? Linux runs just fine on hardware as is.
Basically a group of people did all the fun parts of writing an OS and did not do all of the boring hard-to-get-right pieces.
I have no idea why the whole world keeps thinking Fuchsia is serious, when they can see the code all along and note that it is a joke.
But yeah my impression is that it isn't meant to replace Andrdoid, but that they want to use it in places where a full Android doesn't make sense, like in their smart display devices or other future categories. Or maybe it's really just a retainer project for engineers.
Another reason people think it's real is that there was a lot of press a couple of years ago about something called "Andromeda" that was meant to combine Android and ChromeOS into one project. This was then supposedly shelved in favor of Fuchsia:
Speaking as someone who used to use a Google-branded chat app to keep in touch with people daily and now doesn't use one at all: I am not sure that the ability to look at something and go, "That looks like it won't work" is a guarantee that Google will not go out and do it.
It's not that bad to have internal teams competing, for example I doubt we'd have seen compose without flutter.
It seems to me they're trying to not fall into the same trap as Microsoft did trying to protect their dominance with one OS over all other innovation.
That said, the Android team really seems to hate the flutter team ( Jake Wharton lol) also the main flutter guys all come from chrome like Ian Hickson so if there was bad blood from chromeOs that will stay.
Personally I hope Flutter succeeds because I really hate the Android sdk. Fuchsia just seems like something they're experimenting with and putting into smart clocks or whatever.
Microsoft suffers from other problem, DevTools vs WinDev.
I believe, that if they were both going into the same direction, maybe Longhorn would have successes, instead of having the detour of rebuilding its ideas in COM, going through multiple iterations of it (WinRT, UAP, UWP) and then complaining that most devs use the .NET projections anyway.
What I dislike in Flutter is its dependency in Dart, yet another eco-system starting from scratch, just to save a programming language, kind of.
As an Android developer I am kind of wary of how they push Kotlin for Android. I'm sure it is good, and I enjoy learning a new languages, but I already have a code base that I am worried they are going to make me rewrite.
Kotlin once compiled is (for practical purposes) indistinguishable from Java. Even if new APIs will be Kotlin only (Jetpack Compose), you can write new Kotlin code alongside your legacy Java with no issues.
Not really, because Kotlin uses concepts that aren't exposed in Java the same way, let alone the clunky J++ used by Android.
For example extension methods or suspend functions.
Hence why there is a guide on how to write Java friendly APIs from Kotlin.
Jetpack Compose is an interesting story, looks like it sprung into existence as response to Flutter, without any concrete ideas on how tooling should look like and total disregard for the ongoing efforts to sell constraint and motion layout editing on the graphical tooling to android devs still using the old layouts.
Having watched all SwiftUI tooling related talks, and from experience how Android Studio has evolved, I don't have great hopes that by Google IO 2020 we will see demos at the same level as WWDC 2019 SwiftUI ones.
