AIUI, the situation until now has been that essentially, every Android device released has its own fork of Android. Which is absurd, and explains why the Android security update situation is such a mess. Glad Google are trying to fix this.
The situation is the same for all embedded Linux devices. All have non-mainlined (and non-sidelined) changes to device tree, startup code, pin muxing code, special kernel parameters, special drivers, specially adjusted drivers, special vendor drivers that are C wrappers around binary blobs etc..
Out-of-tree maintenance is possible, but this still often needs to build against the kernel sources, not some more generic kernel library (or ABI, if you want). Other embedded platforms are worse (eCos), some are better (QNX, MQX) in separating device driver code into units that do not depend on the whole world.
Kernel maintainers are very vocal in saying "it's not me, it's you" and laughing in your face, but if every vendor has the same issues with managing in a sane way customization of your operating system since a decade and a half, it becomes a bit of a running joke.
Except every vendor doesn't. By some magic voodoo witchcraft, x86 remains consistently capable of producing a single kernel that can run on anything from Intel or AMD.
Because they upstream their platform support.
That is literally it. No, it is not a technical impossibility of the ARM world to support common hardware abstractions like IBM-PC platforms. They choose not to.
The "magic voodoo witchcraft" is Microsoft's "Hardware Compatibility Specifications for Windows".
https://docs.microsoft.com/en-us/windows-hardware/design/com...
Linux and the other free OSes run on commodity x86 hardware by targeting the same Microsoft-issued specification. There is no standards body or other neutral organization that defines what an x86 PC is.
It went the other direction: anything new from Intel or AMD had to run the same proprietary, binary-only kernels and applications (since MS-DOS was more of a loader, applications could and did access the hardware directly).
Later, Microsoft started specifying exactly what would be required so that their proprietary, binary-only kernel would run (https://en.wikipedia.org/wiki/PC_System_Design_Guide). It was not the vendors upstreaming their platform support; it was Microsoft dictating what the platform support would be. Even today, Linux's ACPI support mimics Windows', since that's what vendors test against.
ARM systems never had a dominant vendor which could dictate its terms, and new systems were not expected to be backwards-compatible with older kernels.
It's a bit easier to upstream when the gatekeeper sits on the next chair and is paid out of the same pocket as you are.