We have plenty of open software.

What we need next is open hardware.

Hardware specifications are still mostly secret, and the lowest level code that interacts with the hardware is still mostly distributed as an unreadable binary file.

As long as our hardware is full of secrets, running our own software on it will be like exploring a cave without a light.

PC architecture is very standardized. ARM is like the wild West where nothing is standard. Everything needs specialized drivers that need to be compiled along with the operating system in order to even work.

Long answer short:

CPU Architecture.

With ARM the drivers need to be compiled with the entire OS, they can't just be installed later.

The tl;dr is: Control. Vendors want it, making it easy to run open software would make that control harder to keep.

Because of lack of standardised firmware on smartphone. PCs uses UEFI + ACPI to give information about devices to OS, on smartphone world different chip manufacturer have different bootloader and they load linux kernel and pass DT(device tree) which explains what devices are present and also smartphone were used to be less powerful, contains less storage (in past) so what they do is to compile linux with only the drivers which are actually present on that particular devices to save space. Thats why a smartphone rom is not a generics image which will run on all phone. But android/linux can be compiled like a generics image, look androidx86 project for example.

The hardware is generally not open source, and it's technically illegal in a lot of jurisdictions to redistribute the binary blobs that make it work without permission from the manufacturer (basically never has happened). Because there is minimal focus on forward and backward compatibility, different chips from the same product line are very often incompatible with each other, let alone from different manufacturers.

So phone ROM maintainers have the job of stripping out those binary bits from a recovery image for a given phone or something and then getting them working with an open source build of android. All the while taking a (albeit kinda low) legal risk. Take a look at most of the long running open source Android projects and you'll see they have had to structure their projects to mitigate legal exposure.

In Linux most of the hardware support is just straight up open source, the bits that aren't (typically GPU or specialist hardware drivers) are manufactured by people that want you to use their hardware on Linux, so they release prepackaged drivers for you to use.

Phone manufacturers are motivated to try and ensure everyone uses their stock ROM because ultimately they have to support the device if a user breaks something, and that's easier for them when they eliminate as many variables as they can. Even if they can charge the user out of warranty, it's still tying up support resources from their perspective.

There are 2-3 major roadblocks. Like others mentioned we simply lack drivers. But in my opinion the biggest issue is the lack of a BIOS equivalent for ARM systems.

Most PCs use x86 processors while most phones use ARM processors. And most x86 systems come with a BIOS (nowadays UEFI). That is a very simple operating system that runs when the computer starts and it gives a standard way for other operating systems like Windows and Linux to start up. That way the same x86 operating system can start on just about every x86 computer.

ARM lacks this standardisation. Although there do exist some projects to fix this they are not in use on most phones. So you actually have to make a custom way to just start up for each and every phone.

On top of that and the general lack of drivers many manufacturers lock their phones down so that only their own operating system may start.

Because a PC tells the OS what hardware is present. Phones do not, that's why there is no hardware detection.

Nobody forces phone makers to support the standard that would just do that: https://www.arm.com/architecture/system-architectures/systemready-compliance-program

Mainly two reasons, one about architecture, and one about vendors

In the PC world, the entire ecosystem is designed to be modular, and people expect to be able to put windows/Linux on any pc and have it work despite the manufacturer. The kernel just wakes up on one of the cores, figures out the CPU, wakes the rest of the cores, and from there it figures out the rest of the computer. By contrast arm systems are tightly integrated, each SoC is unique and there's no way to figure out the rest of the system, the kernel wakes up on one of the cores, reads out what SoC this is, and mostly has to already know the chip and any additional hardware connected to it.

But, sure, there are only so many SoCs (kinda), and displays, cameras, and touchscreens are mostly similar, you are bound to find a way to tell the kernel what hardware is running on and have it work, right? Except a lot of phone hardware is proprietary (duh) and requires bespoke proprietary drivers, google pretends to encourage vendors to submit their drivers upstream, but this doesn't really happen. Now, if you are familiar with running external drivers on Linux, you probably know how picky the kernel is in what to load, but android's kernel is specifically modified to be less picky, to allow vendors more slack. Mind you, the API is not more stable, the kernel is just less picky.

Bonus: running Linux on arm laptops is indeed proving kind of a challenge (nothing impossible, but resources are limited), that's because they are built like a mobile phone.

Hardware incompatibility between phones. The PC world is much better standardized.