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.
You can't always get what you want. But if you try sometimes, you just might find, you get what you need. — Jagger/Richards
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 Linux kernel goes through many sets of hands before it's transformed into the Android kernel.
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.
Google wants the Android kernel to be the Linux kernel and is spending a lot of effort to make it happen.
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!
No matter which OS you use there is no one-size-fits-all update file.
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.
Google tries everything it can think of to make Android updates better. One day, it will have accomplished everything it set out to do.
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.
These are the best wireless earbuds you can buy at every price!
The best wireless earbuds are comfortable, sound great, don’t cost too much, and easily fit in a pocket.
Everything you need to know about the PS5: Release date, price, and more
Sony has officially confirmed that it is working on the PlayStation 5. Here's everything we know about it so far.
Nokia launches two new budget Android One phones under $200
Nokia 2.4 and Nokia 3.4 are the latest additions to HMD Global's budget smartphone lineup. Since they are both Android One devices, they are guaranteed to receive two major OS updates and regular security updates for up to three years.
Secure your home with these SmartThings doorbells and locks
One of the best things about SmartThings is that you can use a slew of other third-party devices on your system, doorbells and locks included. Since they all essentially share the same SmartThings support, we've focused on which devices have the best specs and tricks to justify adding them to your SmartThings arsenal.