Let me ask a (potentially) very stupid question here:
What prevents doing the same on phones?
What would make a phone hardware able to install anything that compiles to its CPU architecture the same way a PC can?
What would make a phone hardware able to install anything that compiles to its CPU architecture the same way a PC can?
Stable binary driver ABI. Hardware monoculture. Expensive driver certification program. Letting hardware vendors release binary drivers without releasing the corresponding sources. An opt-out automatic update mechanism.
(Disclaimer: I work at Google, but not on the Android team.)
But the reason I brought it up is that Fuchsia OS will have a stable driver ABI.
IMO the key point out of the things you mentioned is the hardware monoculture, because that definitely does help people get Linux running (and keep it running) on new hardware. I'm skeptical about most of the others.
With PCI and later the OS can ask each device on the bus to ID itself and thus figure out if it is a known device type or not (and if not, ask the admin to install drivers).
On ARM You have things sitting off various buses that expect the kernel to know what they are and how to talk to them from the word go.
It has gotten better as now there exist something known as a device tree that can be read by the kernel at boot. But not every SoC provide support.
However, to say that HW interfaces on the PC have been stable since the age of IBM PC clones is a joke. In the DOS days, users manually had to manually set IO memory addresses and IRQ levels. Early Windows sat on top of DOS, so still had to do it there. Plug'n'Play didn't show up until Windows 95, and even then it was hit and miss. Some devices worked, others required manual configuration. RTM Win95 didn't support USB, either. That took the equivalent of a service pack (although, IIRC, they went by a different name back then. I want to say OSR1 added USB 1.1 support). Windows drivers didn't really get friendlier until the push to the NT kernel & it's HAL. Win2k had limited, but good support. WinXP got better. Vista was a step backwards. Win7, 8 and 10 have incrementally improved on Vista. Even on Windows 10, though, I have updates that "forget" a subset of my USB controllers. Windows doesn't know about drivers for my HOTAS. Most recent windows updates cause it to forget about my secondary monitor. Half the time after an update, my USB keyboard doesn't work (I have to login on my desktop using an on-screen keyboard to correct settings). I'm probably one of the only (or a small handful) of people that have a Geforce 690 & 1080 in the same system. Sure, PC might be better in that most peripherals go over USB. But, not all USB devices work with a generic driver, and Windows often doesn't include non-generic drivers for all but the most popular devices.
The core system of PC is highly compatible with OSes in pretty much all directions. (Well now even if I don't ignore the non-PNP ISA configurations stuffs, it does not really change the situation: those were not for core system stuffs)
Then you have drivers for various bus controllers and peripheral, some of which are crucial for using your PC in practice, but as soon as the necessary driver exists, loaded by the kernel way after the core boot, and highly abstracted on all modern OSes (it only access the HW through functions abstracted by the OS)
For non-ancient PC, you even have with ACPI some abstracted functions, provided by the HW, and used at the runtime by the OS. It's to be considered as part of the core plateform, as if it was a pure HW interface, given what we are discussing about. The NT HAL, btw, is a vestigial of early NT years, and is of zero interest for the purpose of PC compatibility today (there is only one HAL that is in use on modern PCs, and IIRC switching the HAL was not even enough when multiple were in use IIRC, other MS binaries still needed to be recompiled -- so the NT HAL is merely an internal detail that bring no consequence in backward or fw compat as far as decoupling of binaries and their update of a partial subset in a system is concerned)
Now the situation for ARM SoC for Android is NOT the same. You just don't boot a generic ARM Linux kernel to driver your random ARM SoC of your random phone. Because even what could constitute an equivalent core system as what exists for PC, follows no standard.
The kids today don't know how easy things are with unified drivers for audio on Mac OS etc. I mean, even USB coming out was amazing instead of serial devices and guessing the COM port? Which LPT1?? And dial up etc etc so easy now.
Heck, if you crack open the ARM based Windows RT tablets you will find quite the odd duck of an ARM SoC inside. One more reminiscent of a x86 PC than what you find in your average Android device.
I get Windows security updates on every damn computer I buy. Yes, the computer is pre-loaded with bloat, but I still get updates like everyone else.
Meanwhile, on Android, I mostly get nothing. What is so fundamentally different between PC and phone? Why is it so hard on mobile phones?
But it's still Windows.
I just wonder why that is. Maybe Microsoft has stricter licensing?
The reason your question is "stupid" is because you think your phone is just one computer.
In fact, you can do just what you describe - and it wouldn't be that difficult - but it would only be for the application processor and you would end up with a nice PDA.
In order to make phone calls you would also need to control the other two, fully functional, general purpose computers inside of your phone: the baseband processor and the SIM card.
Currently, there is no way for you to control either of those in any meaningful way.[1]
There are deeply entrenched economic and technical forces standing in the way of controlling your own baseband processor and we are nowhere near to doing it.
[1] Osmocom on 2G phones is not meaningful, no matter how impressive and interesting it is.
- Android breaks compat with old drivers every update - HW makers only ship (often vulnerable) binary blobs.
They update just fine, sometimes even on the major versions. E.g. my phone initially had windows phone 8.1 and now it’s windows mobile 10. And despite the phone is 3 years old, I'm still regularly getting OS updates.
That’s why I don’t believe ARM hardware is responsible.
Then they mandated secure boot with keys that cannot be controlled by the user, so that other systems can not leverage the platform on W10M hw :p . (That's in the spirit of what BG wanted for ACPI: something somehow incompatible with other OSes -- MS eventually managed to do this with a sidestep, but well, this did not really help their market share :P )
The The PocketPC and Windows Mobile situation was not much different from the Android situation today, i believe.
This is why things like SBSA (https://en.wikipedia.org/wiki/Server_Base_System_Architectur...) were needed before ARM servers could even be talked about, and why things like Rasberry PI's are not directly compatible with BeagleBones, etc, at least for the low-level stuff..
Nothing to do with ARM itself; just lack of ARM standards.
This was similar in the early PC days and had similar headaches - compare the various CP/M machines with what became the 'standard' MS-DOS/IBM-PC 'platform'..
(And device manufacturers do this too, but it's a ton easier to, say, fix flash with a shim than it is to fix networking.)
Qualcomm (by far the most popular hardware vendor for Android devices) doesn't care about supporting their released hardware.
Quite often these days when a part is initialized, the driver uploads firmware as part of that.
If you look at most Linux distros they have a package of firmwares that various companies have allowed to be distributed with the kernel.
Meaning there is a small part of the Qualcomm blob that needs to interface with the kernel to upload the firmware.
And the interface changes as the kernel changes. This because Linux devs don't want the hassle of trying to debug a kernel panic only to find that it is happening inside a third party blob, and thus they can't fix it. Instead they want companies to either work with them to maintain drivers or hand them the information needed to maintain a open driver within the kernel source.