Nah, the kernel isn’t that important for apps - you can replace the kernel and update the massive Android framework to work with the new one relatively easily (you will need some Linux compatibility for native code that does syscalls on its own, but that’s pretty much it - even WSL1 could do that).
It’s all the APIs and system apps provided by Google that have no reasonable alternative in AOSP that are the problem for compatibility. Look how incomplete projects like MicroG (an open-source implementation of Google Play Services) are, and their only goal is to provide Android compatibility for unofficial ROMs without installing the proper Google services.
Sure, but I don’t see how any of that disproves the current “M$ supremacy” for “normies” - the fact is that people who couldn’t care less about how their computers work will have a much easier time using Windows (and probably macOS) than any Linux distro. You don’t have to worry that some software won’t be available to you because of your choice of the OS, and if you ever have a problem it’s easy to find help.
I haven’t used Windows in a decade on my personal computers, but as long as these two things hold true, it will always be my recommended OS for people who simply don’t care - I’m not going to spend my time doing free IT support for everyone I know and then get blamed everytime something doesn’t work.
Annoying warning keeps showing up at boot -> bring the PC to the nearest computer-literate person, and they’ll fix it. Good luck doing the same if you use Linux.
As far as I know, bootloader locks are done by the manufaturer not by the provider.
Verizon requires the phones they sell to NOT have the ability to unlock the bootloader. That’s why there are separate factory images for Verizon Pixels.
That sounds like Xiaomi. The best price to performance ratio of any OEM, but at the cost of terrible software and this… experience… when you want to get rid of it.
Nah, the kernel isn’t that important for apps - you can replace the kernel and update the massive Android framework to work with the new one relatively easily (you will need some Linux compatibility for native code that does syscalls on its own, but that’s pretty much it - even WSL1 could do that).
It’s all the APIs and system apps provided by Google that have no reasonable alternative in AOSP that are the problem for compatibility. Look how incomplete projects like MicroG (an open-source implementation of Google Play Services) are, and their only goal is to provide Android compatibility for unofficial ROMs without installing the proper Google services.