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!
Google packages the Linux kernel for Android and provides it to manufacturers. All that is missing are all of the kernel modules that make all of the hardware work. These kernel modules are proprietary blobs. They are different for every device and may be different for the carrier specific revisions of every model.
If you try to update the kernel, to something like mainline, the changes present in the mainline kernel are not compatible with the old modules and will break stuff. The source code of these modules must be present when compiling the new kernel.
This is the intended behavior and design. It is theft of ownership using this mechanism.
However, it is not just this simple. Android is designed to allow idiot users that do not have a clue about operating systems, security, networking, or radio communications. Android makes this possible in a unique way, and is a great way to learn about how to secure a Linux system properly.
When the manufacturer finishes configuring the device kernel modules, the final step is to remove absolutely every way of adding a binary package to the device. This means they remove the su, sudo, wget, curl, git, Python, etc.
The entire Linux base is only present to run the Android user space. This is like a single Linux application. Nothing else is running in Linux like a .deb or .rpm.
So how does the competent configuration magic happen? - nobody asked.
This is the important detail to understand; the application developer is given the same user space permissions and access as the end user of the device. Android apps are not some static executable program you run on your device. These are entire user profiles that coexist with you at all times. This is how the application can operate securely without any intelligent configuration required by the end user.
SELinux is used to sandbox the various Linux directories so that apps are limited in their access to each other.
The code for Android apps is often garbage. It has to do with the enormous number of devices, configurations, exceptions, aging, and just bad code. Android handles this by just steamrolling through. It can largely get away with this because there is no way for the app to modify the kernel and compromise the system, or for the user to do so for that matter. This is why you can’t have root on Android and adding root is absolutely insane and will wreck your device.
You are not admin. Most of the privacy aspects are a joke to make you feel better. THIS is why everyone wants you to use their app. Apps are users that are always with you, and very intimately. These are your soulmates; your digital life partners — far more intimately connected than any human partner. In a sense, Google and Android are the pimp, and you are the product.
If you have a full kernel, you must have the administrative binary, or at least the package key for access to the bootloader. If a mobile device existed fully open source on mainline, you shift the burden of configuration onto the user.
There are also many aspects of Android that are more advanced than the mainline Linux kernel. Things like asymmetrical CPU schedulers, or how I glossed over the way there are 3 types of users. The way the modem interacts with the SOC is another enormous mystery to me and a giant can of beans. The simple ways that typical Linux distros are configured are nowhere near sufficient for a mobile device. Fedora is one of the only distros that even comes with SELinux but it is set permissive and unconfigured out of the box. Most people never really get into understanding NFTables and networking, preferring to have lax setups using ad block where others do it for them. You would need to know all of these systems intimately if you want full control and for mobile networks to allow connections, or payment systems or banking apps to function. That is simply unrealistic to expect for the general public. In truth, for a typical Linux user, something like OpenWRT is hard. Android in its true complexity is next level beyond this.
Still, it is not full proof. The Linux kernel has around one bug for every 1k lines of code. That means there are tens of thousands of bugs. These are found and patched constantly. However, kernels on Android are almost always ancient, and static/unchanging. This is the reason custom ROMs have existed all of this time. When a bug is found, that exploit is the way into the kernel and an administrative root binary can be added. The only exception (that I know of) is Graphene OS. The Pixel has the same type of Trusted Protection Module (TPM) as your computer uses for UEFI Secure Boot. This device enables Graphene OS to sign and load a separate encrypted operating system without cracking the kernel like a typical ROM.
In an ideal world, governments would protect the unalienable human right of ownership autonomy. This is a cornerstone of citizenship, and therefore democracy itself. Ownership is simple to regulate by requiring that all hardware sold must be fully documented with every piece of the toolchain used to configure the hardware made publicly available immediately upon public offering. This would not change Android as it is now, but would make it possible for the community to take full ownership over their devices and take away absolute control from Google/manufacturers with planned obsolescence.
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.