Android to take an “upstream first” development model for the Linux kernel (2021)
arstechnica.comCan anyone who has actual experience in Linux kernel development for ARM platforms offer a realistic defense of the status quo other than "companies making the SoCs don't care nor do the device OEMs that are their primary customers and it would cost more to do it right"?
I'm not a low level hardware person, but being on the edges of the Android modding community for over a decade now and also spending a lot of time working on the various Pi-likes has left me incredibly frustrated with the state of hardware support.
In my mind it is absolutely inexcusable that vendors regularly ship hardware with only binary blob support for ancient kernels, years old versions of Android, etc. with no intent to ever change. To me that's a sign of either pure incompetence or an active desire to do things wrongly. Am I wrong? Is there any reason I shouldn't feel like everyone responsible for those choices should be named and shamed constantly? Basically is there any good excuse other than "it's cheaper this way" and/or defective logic about drivers being "trade secrets" of some form.
I think I'm several years out of date on this issue, but years ago one of the problems was that there were not standard hardware interfaces for things a kernel needs like interrupt routing or hardware bus enumeration. The PC for example is a very homogeneous platform. There are also standards like EFI. But the ARM world has been a wild west. Each device needed some kind of hardcoded hardware map.
That explains why ARM mainline Linux is more of a mess than other platforms, but it doesn't explain why ARM SoC vendors are seemingly entirely uninterested in doing things the right way. They could develop in a mainline-compatible way and work to upstream their changes so their platforms could be supported properly ~forever but they instead seem to go out of their way to do the opposite despite constant pressure to fix their garbage.
ChromeOS/chromebook has been fairly successful at making this happen. Tons of MediaTek and Qualcomm drivers & good support, if you have a chip slightly bigger than a phone chip.
Qualcomms slowly turning it around. Their Wi-Fi router situation was reaching a real breaking point, but we are multiple years of folks + them making good progress to getting into grace.
The benefit is also higher too, since ChromeOS has a more regular Linux-y environment, and I think even using Wayland now. Where-as on phone, it's like, great, kernel drivers, but the entire upper stack is Android so what the driver needs to prioritize is different.
If you read in here, part of the dodge is that rather than a actually upstream, Google maintains their own custom Kernel Module Interface (KMI) in their Android specific "Generic Kernel Image" (GKI) that's different from the actual kernel interface. So instead of vendors targeting upstream, now they're authoring to a Google specific kernel interface - a kernel wrapper - that doesn't exist anywhere else! Google's "Generic Kernel" seems like a fork of upstream that now people develop against. Its hard for me to see this situation as an improvement; it feels like it will insure work doesn't get upstreamed, since work isn't against the kernel but Google's kernel.
"Google Kernel Image" (or Android Kernel Image) might have been a better name than Generic Kernel Image.
Reading that again today in the context of "Linux gives up on 6-year LTS kernels, says they’re too much work", Android could have been a prime helper of LTS kernel maintenance.
Android was the prime helper of LTS kernel maintenance. They're the entire reason that LTS kernels even exist!
https://www.reddit.com/r/linux/comments/jiky5j/linux_510_is_...
Oh! so I guess the plan didn't exactly work out as expected :/
So I guess if something as sizeable and impactful as Android can't reliably move the needle towards 7 to 10 years of maintained stability then the only way forward is a few select ones providing forked stability and the remainder has to continually upgrade to keep being maintained.
(2021)
Here's the up to date documentation https://source.android.com/docs/core/architecture/kernel/gen...
two years passed, not sure if it's doing upstream-first in real yet.
I doubt it, as Android has many subsystems not available upstream.
Subsystems? Which ones? I thought this is all about drivers / SoC support.
Android drivers aren't part of Linux kernel since Android 8.
> In Android 8.0 and higher, the lower-level layers are re-written to adopt a new, more modular architecture. Devices running Android 8.0 and higher must support HALs written in HIDL, with a few exceptions listed below. These HALs can be binderized or passthrough. In Android 11, HALs written in AIDL are also supported. All AIDL HALs are binderized.
> Binderized HALs. HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.
https://source.android.com/docs/core/architecture/hal
> The term Legacy HAL refers broadly to all pre-Android 8.0 HALs (deprecated in Android 8). The bulk of Android system interfaces (camera, audio, sensors, etc.) are defined under `hardware/libhardware/include/hardware` and have rough versioning and a roughly stable ABI. A few subsystems (including Wi-Fi, Radio Interface Layer, and Bluetooth) have other non-standardized interfaces in `libhardware_legacy` or interspersed throughout the codebase. Legacy HALs never provided hard stability guarantees.
https://source.android.com/docs/core/architecture/hal/archiv...
All of this is in userspace.
Yes, most Android subsystems since Project Treble are in userspace.
Hence my doubts, what makes Android Linux isn't on the Linux kernel.
Also I am not sure if everything related to Binder, gralloc and SurfaceFlinger are part of upstream contributions.
Then there are the ebpf customizations, different SELinux and secccomp settings, among others.