forkbomb_

>So the way I see it (coming from a dev, though not a ROM dev): Android has multiple layers. It has hardware-dependent code (such as the kernel) and hardware-independent code (such as bionic or Java), sort of like in Desktop Linux you have the kernel and X, and there's bash, gnome and Firefox.

Yeah, that's pretty much it.

>So why can't (I know how that sounds coming from the outside ... ) you take their hardware code (the kernel and whatever the Android equivalent of X is) and build on top of that? Is the whole system that integrated?

We could - and it would definitely be a good start - but there would be changes necessary because e.g. our extra bits are implemented differently, maybe our "device-independent" bits are missing some commits that Omni has that fix support for some OEM driver - before treble, Android's hardware-dependent code and hardware-independent code were often both modified by OEMs/SoC manufacturers in order to fix issues on their platforms/add extra features. So Omni might have some fixes that we don't have, and vice versa.

>But does every Debian maintainer (of a userspace program like, say, MySQL) have every combination of hardware? You just assume that the kernel and libc are a reliable abstraction and go from there. Is that impossible on Android?

It's much harder on Android, because there's so many blobs built against previous platform releases (often with extra ABI changes from the OEM added on top). That means we can't assume that the ABI is consistent: for instance, we've had nasty bugs in proprietary binaries caused by AOSP adding fields to structs. Whereas on Debian, everything's kept in-step, so they don't end up with ABI mismatches all over the place.

Hopefully with Treble, a lot of this will change - so the idea of a "universal Lineage image" might be possible.

I'm another "project lead" at LineageOS:

Despite being based on AOSP, omni/lineage/etc all have pretty different features, so usually it takes a nontrivial amount of effort to go between the two (although it's definitely less effort than starting from scratch)

Most devices within the project are maintained by single developers - the difference is that official devices have been submitted to us and have everything working.

We don't blindly support devices (even as "beta") because we have no way of verifying that everything actually works (e.g. blobs that depend on an old C library ABI can't really be detected before runtime, afaik). Shipping stuff that's broken is something we'd like to avoid. The idea is that when you download a LineageOS build from lineageos.org you know that it'll work flawlessly (that may not always be the case, but it's the goal :P)

The kernel you get is entirely up to the SoC vendor.

Snapdragon 820/821 ships with 3.18. Snapdragon 830 ships with 4.4. Snapdragon 830+1 will ship with 4.9

There's a huge amount of work involved in porting a chipset from one kernel version to another. While I'm sure Google _could_ do it, it's ultimately not worth their while - they'd probably lose support from Qualcomm, and if they hit any weird bugs they'd be on their own.

Probably not - Lineage can only patch issues that are present in the open source code. Since this issue exists in the firmware, it's up to device manufacturers to release an update including the fixed firmware, which Lineage can then incorporate.