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.
[1]: https://github.com/LineageOS/android_kernel_samsung_smdk4412...
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.
[1]: https://github.com/LineageOS/android_kernel_samsung_smdk4412...