They've already replaced Dalvik with ART for bytecode and it was mostly transparent from what I understood.
But popping up with a completely new platform API without any backwards compatibility would be very bold and risky. There would have to be a good compatibility story there.
Also there is talk in the article about a POSIX layer. Now that's easier said than done. But it is Google we are talking about so they certainly have the manpower and resources to try.
It isn't too hard to do Linux ABI emulation. The interface there has mostly been stable for the last several years. That would enable just using the same userspace as Linux distributions like Android.
They did not. ART is here on-device architecture-specific and version-specific; Dalvik bytecode is still the portable bytecode used in all APKs. If they had replaced it, we wouldn't still be dealing with the 65k methods limit for example.
A new runtime is very different then a new framework/API/OS. The former doesn't necessarily require code changes (dalvik -> ART did not), the latter requires new everything.
Exactly. This sort of switch seems for me also a good way to increase the amount of bugs by a large scale. It may only work for very specific hardware I think.
Job security and Apple-ish custom OS may long-term reduce support burden because Linux is like OpenSSL: a giant refrigerator, stove, oven, typewriter, glass kiln, laundromat kitchen-sink. It will take a very long time to reinvent the wheel and also deliver a PG "quantum of improvement," but there are plenty of Alphabet employees to do it. Also, similar Apple, it's an OS they control so there's less rejection / ignorning of Google's desired direction as with FLOSS.
You grossly overestimate Googles ability to support an OS on multiple platforms. Do you remember the why Samsung Galaxy Nexus was abandoned?
Apple supports iOS on two platforms (32-bit and 64-bit A-series). Microsoft who has been in the OS business much longer than than Google only have resources to support Windows 10 Mobile on a handful of carefully chosen Qualcomm chips.
So basically the only way this could work is if Google would create their own SoC and mandate Android vendors to only use that SoC. I don't think Samsung would like that too much.
That's a given. Google also needs to control the hw platform to be successful. Open platform equals shoddy service/product because it would require adding a Microsoft-sized operation.
You wouldn't have to do it all at once. You'd emulate the Linux user space, and do everything incredibly gradually. Both APIs would be supported for many, many years. But they could stop advancing the Android API within a shorter timeframe.
I'm not sure the API can ever really be phased out due to the vast amount of legacy apps and libraries.
Besides I'm sure a lot of developers wouldn't be happy that their domain knowledge just went flying through the window. Even if that is a risk inherent in the job.
If this ever happens, it would probably be an extremely slow, well thought out (hopefully), well documented (also hopefully) rollout.