>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.
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.
Google does this already[1]. As far as I know, it's possible to boot Android off a mainline kernel - the main obstacle is the lack of drivers in the upstream kernel. Certainly, a lot of the SoCs (especially in older phones) can _boot_ from mainline. Maybe you could even get a serial console, or a picture of tux on the screen. But the OEMs don't really have any incentive to upstream their drivers (or port older platforms to newer kernels) - why bother?
Probably the only instance that I'm aware of where an OEM has actually mainlined support for their own mobile devices is Samsung with some of their Tizen reference devices - "trats"[2], "trats2"[3] (which is pretty much identical to the Galaxy S3), "tm2" and "tm2e"[4]. Of course, these will probably never gain support for certain things like 3D acceleration and the modem in mainline, but it's certainly a good start. (Note: a few Nexus devices seem to have mainline DTS[5], but I'm not sure how complete they are).
The kernel isn't the problem - one of the devices I maintain runs 7.1 (mostly) fine on Linux 3.0[1]. The issues lie in the HALs - which translate between the standard Android camera/sensor/telephony APIs and the vendor's implementation in the kernel. These are device-specific, and usually provided to the OEM by a HW/chipset manufacturer.
Google is generally pretty good about keeping source compatibility, but ABIs change, and sometimes completely unrelated changes break everything for no obvious reason. Some things I've encountered include:
* sensor blobs crashing when using a clang-built libc, but working with a gcc-built one.
* blobs crashing when using jemalloc, but not dlmalloc (dlmalloc was removed with 7.0).
* Vendors introducing hacks in the OS - workarounds to deal with broken HW media encoders (which misinterpret pixel formats), misbehaving GL blobs, or devices which expect one pixel format for their display when the system provides another (e.g. RGB vs BGR).
* closed-source OpenGL drivers which use-after-free - the bug's probably existed since forever, but it only manifests after 7.0.
The real issue for the Nexus 6 is that Qualcomm has completely abandoned their 32-bit mobile platforms. Look for "8084" here: https://wiki.codeaurora.org/xwiki/bin/QAEP/release - the Snapdragon 805 hasn't received a release since August 2016.
So, Google did an in-house bringup for 7.0 - and "normal" OEMs aren't able to do that. Qualcomm usually provides a lot of pre-compiled binaries to the OEM, which either require nasty hacks to work on newer versions of Android (which won't pass CTS - so can't be shipped), or just straight up don't work. The blame here rests largely with chip manufacturers and their short support cycles.
Of course, LineageOS[1] remains an option if you're looking for extended support for the Nexus 6. (disclaimer, I'm a device maintainer for Lineage)
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.
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.