Hi everybody,
I’ve been unable to make sense or gain better understanding of the Android update system, so I’m asking here.
Coming from the linux desktop, there’s two main parts of the system: the kernel and the userland. I could simply update the kernel without updating userland and vice-versa.
But does it work the same way on Android? Why are we so dependent on OTA updates from the individual manufacturer? I understand that microcode is proprietary and can come only from the device manufacturer, but aren’t kernel updates and userland decoupled from this (for devices which support project treble and GKI)? Can’t I just run a different FOSS launcher, get the upstream GKI kernel and run it with the microcode offered by the manufacturer?
What consists of an Android “version”? Can’t I just not update the microcode beyond what the manufacturer provides, and instead keep updating the kernel (by “kernel” I mean GKI and not the actual linux kernel) and userland and in essence keep updating my android version?
I’m probably missing some fundamental understanding of android here, which is why decided to ask here. Thanks for your help!
I feel like at least part of this is copy-pasta, but whatever. You make valid points, but I do not understand how it is relevant to the question. If proprietary drivers can be plugged in as modules (which is what GKI wants), shouldn’t I just be able to update to the latest FOSS GKI myself (which is exactly what Google wants to do with Play updates to the kernel) and keep the drivers from the vendor?
To my understanding, no. Graphene did a blog post in the last couple of months about this IIRC.
If you use gource (GUI view of git commits over time and individuals involved), you’ll intuitively see the issues. The mainline kernel often has some change than requires someone goes through every module in a branch of the tree and makes some small change. It might be some code snippet or it might be a change of type casting. These are the changes that require source code. If a variable is type cast incorrectly or that snippet is missing, the module code will error.
So with things like traditional custom ROMs, the way they are supported is by someone intimately knowing both the kernel used in the device and all of the changes happening in mainline. They back port the required changes to the old kernel as best they can. Eventually, this task becomes untenable and the support is dropped.
The reason I explain things is so that I can expound if needed and get a better understanding if you ask questions, while also giving you a more broad and abstract overview.
You said:
This implies that you do not understand the fundamental architecture of a kernel. Windows is a Microkernel. Linux is a Monolithic kernel. A Microkernel basically provides a specification like API for anyone to write a driver. A Monolithic kernel includes all hardware supporting modules inside the kernel itself. A kernel module is not some separate thing that exists externally. The monolithic kernel is not handicapped by a static API like interface as software technology and new hardware evolve. The way Google has enabled orphaned kernels with Android is a hack and defies the kernel architecture. Every orphaned kernel is therefore outdated before the first device reaches customer hands. The configuration details I explained before are the hack scheme used to get around the vulnerabilities and issues. The kernel architecture can not be changed to accommodate this.
I’ll try to remember not to respond to you in the future. It is a waste of both of our times if writing the details is mundane copy pasta to you. I don’t mind writing it, and haven’t copied anything. I have said it many times, but whatever. Sorry I replied.
Apologies for my tone earlier. I simply did not expect an in-depth and genuinely thought someone did a copy-pasta from another relevant thread/got an LLM answer in. It was my mistake to assume as such and I apologise.
Ah, indeed for some reason this part about the Linux kernel completely escaped my mind about it being a monolithic kernel. Yeah I can see the problem now. Unfortunate that OTA updates are the only way for updates to reach devices not supported by custom ROMs.
I’m sorry again.