[LG G5 ROMs, Kernels, Recoveries, & Other Developme] fonix232:
A PC/laptop is slightly different. There, manufacturers had YEARS to establish a standard (BIOS, and now UEFI). On smartphones, everything is a rush job, to beat the market. Your phone, with it's OS, is a complete product, while the desktop/laptop/tablet market offers more flexibility in the choice of OS.

It is also because there are more manufacturers for phones, and simply, more (undocumented, non-standard) parts. A laptop builds from a CPU (made by either Intel or AMD, with a common standard), memory, storage, graphics hardware (either integrated, dedicated, discrete, etc.), and a display. These are the core parts.

On the other hand, a phone is built up as a unit, from a SoC (which mostly incorporates CPU, North Bridge, etc. from a simple laptop's motherboard, also the GPU, audio, and so on), which does not obey to any standard even within one generation of a manufacturer (the pinouts differ, etc. - like if you needed a different motherboard, nb, etc., for switching from a gen6 i3 to a gen6 i5). Drivers are written VERY specifically for the use cases, and are, in majority, not "universal". Exception might be Sony.

Also, drivers ARE open sourced. The issue is not with the drivers... Let me simplify it for you. There's the OS, that expects input in a certain way, and ouputs things in a certain way. It is called an API. It is hardware independent. E.g. no matter what, Android will output the screen brightness as an integer between 0 (off) and 255 (max brightness), no matter the underlying hardware.

Then there's the driver. It expects input in a certain way, but each display driver works differently, has differently named calls, and so on. Hell, your display might only support 25 levels of brightness. And that's where HAL comes in (Hardware Access Layer). A HAL is a standardized library, which is used by Android, to communicate with drivers. Android can call the HAL with a specific function and tell it that okay, I want display brightness at 180. Now, the HAL is written specifically for the hardware, but uses the Android API. This makes it a translation layer. So this very call, the "set brightness to 180" will translate to something different, something the driver understands. E.g. in our example, our display supports 25 levels of brightness, but the API tells it numbers between 0 and 255. So if the HAL did no conversion here, the brightness would be maximum when the user reaches 10% on the slider. So what it does is it divides the incoming number (in our case, 180) by 10, making it compatible with the driver (we're working with integers here, so e.g. 185/10 would not equal 18.5 but 18).

Now, these HAL drivers are not open source, and the manufacturers are not required to release them. And most importantly... They are seldom as simple as "divide input by ten then pass over to driver". They do complex calculations to make the hardware compatible with Android itself.

The problem happens when either the manufacturer modifies too much of the OS, implementing their stuff with e.g. telephony, NFC, camera, whatnot, or when the HAL API changes - like it did when the Camera API 2 happened. HAL changes are common, as Google expands the OS capabilities of Android to support a wider range of hardware. Until that happens, we can mostly use precompiled HAL libraries (except if the first case stops us).

So that's about it, in layman's terms. And that's why Android is not like "any other" Linux out there.