3 ms·
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 st
by forkbomb_ 9y ago
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/ https://github.com/LineageOS/android_kernel_samsung_smdk4412...
- pas 9y agoOh. I see, so the binary blobs that are not exactly user space, but not exactly non-userspace either. That's why XDA is full of ROMs that "just need to get GPS working and camera sometimes crashes" :( How come Google doesn't try to source better hardware for their phones? Also, is this the cause of why Apple in-housed a lot of things? Also, how come there isn't an isolation layer for these blobs, something like docker for the phone? (So they get their runtime dependencies, and communicate with them via a socket-shim?)