Of course, they could have just meme'd hard about the fact that they're moving away from evil Oracle technology and we'd have already all been on board.
Google has a variety of initiatives, and they really like reinventing things (which can sometimes yield great outcomes). This is a kernel that is in contrast with Linux.
From the article, the OS allows for full compatibility with all Android apps. Furthermore, it notes that Google is going out of its way to avoid mentioning Android anymore.
Of course, if I were Google and trying to sell the public on my new OS, I'd want them all to think that I'm not scrapping the old OS so that they feel they have a choice.
The article does not say that. The article mentions an ART target for Fuscia -- you have to build from something. That is approximately 0.1% of the way towards full compatibility. And for that matter you can run Android apps on a load of targets (although far from full compatibility), but that doesn't mean that they're replacing Android.
Google may absolutely replace Android -- they've made loads and loads of mistakes along the way -- but the way people keep arguing it doesn't make sense, using examples that jettison the parts that work well and somehow keep the parts that don't work well (which includes ART, as an aside). And indeed I'm falling into this same trap while talking about Fuscia like it's a kernel, when really the kernel is a small part and they're, at a very small scale, spit-boarding a new take on virtually every part of the system.
Regarding Google distancing itself from the Android name, that's just branding. To quote one analysis -- "Android sounds technical, has baggage, and might be stale". They've had enough missteps that it's an anchor more than a lift, so it makes sense that they stop highlighting it.
Haha, honestly now. If my Android didn't cost $700 I would long since have smashed it to bits. It's scheduler is totally garbage, to the point where Google's own media apps like YouTube and Music drop samples while the screen is redrawing. Who "loves" Android? To me it is the Win98 of mobile operating systems.
I've never had a higher-end phone, so I'm not missing anything with the mid-range. Web works great, as do most apps.
Also though, I do love it. Different strokes and all
ART is already being ported into Fuchsia and Linuxisms are not part of NDK stable APIs.
So managed Android apps will just work, and NDK libraries only need to be recompiled.
Not having to care about the permanent breaking of internal kernel APIs is not "nothing".
Every single problem that Android has had, from low-latency audio issues (they've rebuilt that a dozen times in a dozen cartoonish ways) to driver stagnancy, is completely and directly a result of Google choices and implementations (and they do the same thing again and again! It's remarkable). The notion that Google is going to fix all of their own self-sabotage by starting anew is comedic in a sense, and is the folly of countless foolish projects. "We keep fucking up again and again...let's start from scratch and this time we'll surely do it right!"
This time, however, it'll be different...
But they didn't. They kept keeping it in sync. They probably had a reason for doing that.
It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications are seemingly very minor. Android's many issues have never been at the kernel level.
Vendors still make generally minor changes to the kernel, but these are not unique or special or some competitive edge. They've just nuisance necessities.
That reasoning doesn't apply to most kernel drivers, and those vendors are just openly in conflict with the GPL.
On top of that, GPUs generally have to have a kernel component, even under systems that put as much as possible under user mode like sel4, because they have their own MMUs that can subvert kernel integrity.
Nothing of that prevents that all new drivers, except for the ones marked as legacy, are required to be Binderized.
The kernel code of a driver from OEMs allergic to GPL, is hardly different from a signal handler, implementing the minimal set of kernel code and deferring everything else to userspace.
I'm going to go out on a limb here and guess that you don't actually write kernel drivers like I do professionally.
Nice.
Now, as someone who has spent a decade in that domain, I'm down to continue having a conversation about it and helping overcome a few of those hurdles, but you need to be willing to hear something that isn't your own conclusions.
As for systems programming experience, you would be surprised, but I am not here to justify myself with appeals to authority.
You hinted that this transgresses the GPL, and there are those that argue that virtually anything transgresses the GPL. But a lot of very large corporations say otherwise, and there have been zero successful challenges against it.
The kernel is designed to have a stable binary interface for drivers. This has been a problem with Linux-based Android devices (all of them so far), because the OEMs (or more properly the chipset vendors like Qualcomm) will only support a particular chipset for a short amount of time (maybe a couple years, it depends).
After that, it becomes hard to bring new kernels to the platform, so we all end up with phones stuck at whatever major release was out at the time, with low prospects of upgrades.
If you can make a stable binary API, and furthermore keep to the micro-kernel model, then most of the OS can be easily upgraded, because you don't need (and aren't going to get) new versions of the device drivers for the chipset.
Also, there's an effort towards better low-latency real-time support. This is critical for AR/VR applications with tight rendering deadlines.
Can you point me to anything that demonstrates that intention?