Android will never be supported by the 'regular' Linux kernel, but that won't stop Google from trying
Google once again had a major presence at the yearly gathering of top Linux developers known as the Linux Plumbers Conference. This is where all the smart people who work hard to make the framework that most of the world's computers run on gather so they can iron out all the problems that any project this big is bound to have.
Since Android is by far the most popular operating system that runs atop of Linux, having it be more "standard" and comparable to the rest is really important. Regrettably, it's not even close because of the way vendors support components and manufacturers put them all together.
Much has been done and Google has some plans to make things even better. Ron Amadeo at Ars Technica has done a great job at trying to make sense of it all in a way everyone can understand, so if reading about forking, how to prevent it, and user-space application binary interfaces are your thing it's a definite read. Even if they aren't your thing, you might learn something by giving it a look.
Enough of the intimidating geek-speak. All you really need to take away from this is that even people who understand how some of it works don't necessarily know how all of it works, and that the two questions you might have are the same two questions a lot of people have: Why can't you update the Android kernel the same way you can on every other Linux computer; and how does Microsoft update so many different things from different companies all at the same time?
The good news is that those two questions have answers that are easy to understand.
The Android kernel is not the Linux kernel
Android runs on the Linux kernel, but it is not the same Linux kernel as every other Linux-powered computer uses. In fact, the Android kernel that is used on one model of phone isn't the same as the kernel used on any other model of phone.
Yes, this is a giant mess waiting to collapse on itself which is why Google wants to fix it. It's also the reason why you can't ever update the kernel on any Android phone to a newer version and the one you are using is at least a few years old.
Google makes any changes needed to support a specific version of Android. Just Android mind you, and not any of the hardware you would want to use to run Android on. Since most all of that hardware is not open, the company that manufactures it, like Qualcomm or NXT, also needs to make changes to support its products and provide them either as part of the kernel or as closed-source binary drivers.
The company that makes a phone, like Samsung or OnePlus, or even Google itself, then has to put the right parts that support the hardware being used together into a kernel that will start the device and power all the parts so Android can load and run. It's like a jigsaw puzzle from hell.
The biggest problems arise when you want to use a newer version of Linux to build the Android kernel. The entire process needs to be redone, and companies are all required to do everything all over again. Most refuse, so you're stuck on the same kernel version throughout the life of the phone.
On a "regular" PC running a Linux distribution like Ubuntu, you can grab the source code for the kernel version you want to use and configure it for the hardware you have on hand. Most PC parts are well supported, either as open-source contributions to Linux or as a standalone binary driver that you can download and install yourself. And because this is relatively simple, most Linux distributions will have a ready-made kernel you can download and install yourself that just works.
This is how Google wants Android to work. It's a long way from doing so and probably will never happen because it would mean companies need to spend extra time and money to support a cheap chip that's inside your phone or open-source the code to power it correctly. Neither sounds like a good option to the Qualcomms and Broadcoms of the world who want to maximize profits and hold its IP as a closely guarded secret.
Update everything all at once
If Microsoft can update a billion computers all at once why can't Google update two billion phones? Windows must be better than Android's kernel mess. Right?
Wrong. It's different and good since the move to Windows NT, but neither is "better" than the other on a purely technical level. In fact, they are exactly the same when it comes to updates!
Remember how I said you can easily update the Linux kernel version on a PC? Well, Microsoft can also easily update its kernel and user utilities on a PC. Both happen partially for the same reasons.
PCs have standards like UEFI or Machine BIOS that allow different hardware manufacturers to boot an instance that a "real" OS can use to load itself. Your phone's ARM hardware doesn't have this and instead relies on a simple bootloader to provide power then turn on the OS itself. PC parts manufacturers also happily provide Microsoft with whatever is needed to update the OS and use their products because they want to be Windows certified.
Without any unified standards, every Android phone is essentially unique and needs an entirely different kernel as explained above. It's simply not possible for Google to build a kernel for the Pixel 4 and ship it out as an update for any other phone.
When it comes to apps and utilities, the company that makes your phone is the one who decided how to implement them. Things like Project Mainline aim to fix this, but as of today only Samsung can update a Galaxy S10 and the update for a Galaxy S10 from Verizon is not interoperable with a Galaxy S10 from T-Mobile.
When it comes to phones, it's also worth remembering that there was no one file that could update phones from Nokia, HTC, and Samsung. Every phone had to be treated individually, and while Microsoft said it couldn't update many models to Windows 10 while users were editing a few registry files and making it happen anyway. ARM products like phones are just not built for universal updating the same way other computers are.
Getting Android devices to run on the regular Linux kernel isn't going to magically solve these issues. But if it happens — and I'm skeptical no matter how many smart people are trying to make it so — there will be one less hurdle for manufacturers like Samsung to jump through when it comes to updating your phone with new features or for better performance.
In the meantime, there is still plenty of work to be done that can address some of Android's other issues when it comes to better and faster updates. Those are being worked on, too, and things get better every year.
Or maybe in 2020 none of this matters and everything will run Fuchsia.
Get the Android Central Newsletter
Instant access to breaking news, the hottest reviews, great deals and helpful tips.
Jerry is an amateur woodworker and struggling shade tree mechanic. There's nothing he can't take apart, but many things he can't reassemble. You'll find him writing and speaking his loud opinion on Android Central and occasionally on Twitter.
Nvidia must enter the market with mobile OpenPower or RISC-V processors. A lot will improve if the hardware is open source. This is a chance for them.
AMEN. 3 words to satisfy spam filter
Sure, because Android on Intel was such a success -- every developer was rushing to "recompile" (to borrow your sister-site term) their software. And ARM and Intel had the same byte-ordering... Please, do not bother telling me that Android apps are written in Java and/or Kotlin, just use your search engine of choice and find a statistics on how many of the most popular apps have JNI bits in them.
But if a company were to bring more open hardware to market and Google used it because it was easier to put the mainline kernel into place, the development tools would have to be updated to do a better job cross-compiling and spitting out executable bundles. I'm willing to bet that companies like Samsung would also be interested because of the cost savings. Unfortunately, we'll never know because it will never happen. Edit: Yes I know that the amount of work it takes to make the kernel handle threading and JNI calls is a mountain of work and hardware changes would mean building another mountain. But I also think the amount of work it takes to build a working "Android" kernel for every model is also a mountain of work that Google really wants to do away with. We can still dream, though :)
Of course they want android to use mainline linux kernel....hell of a lot less work for google.
A lot less work for OEMs and lazy ass Qualcomm too
On to Fuschia...
It’s just good to see that Google isn’t giving up on the poor Android updates mess. The internet has become very dangerous place and the phones have become very expensive. With this, better methods of keeping Android devices up to date is very important, irrespective of who the OEMs are.
There has been a considerable amount of support in the GSoC world on expanding the support for the Linux ABI in FreeBSD's Kernel (Linuxulator)... While Linux today is the preferred plarform for Android due to its plethora of Hardware support, the lack of support in the GPL for industry IP via BLOBs is a difficult boundary in the hardware world, specifically for embedded systems manufacturers. I really believe Google has been so successful with Android purely because of their scale and support from the Google Parent (Alphabet). I think we all would love to see manufacturers be more open with their source code. That being said, there needs to be provisions for furthering development and simplification of legal structures in this instance. It seems to me it would be wise to further expand efforts to leverage the Linux ABI within FreeBSD for Android whose permissive licensing model would allow for a tighter integration with the kernel source tree. The BSDs have a long history with embedded systems for this reason. It might lead to a much simpler support system for both Android and the Linux ABI in embedded systems or at the very least help in limiting refactor of hardware dependant source for manufacturers. I know those of us that support BSD alongside Linux would greatly appreciate the additional contributions from developers with a good understanding of third party hardware.