One of the biggest freedoms associated with free software is the ability to replace a program with an updated or modified version. Even so, of the many millions of people using Linux-powered phones, few are able to run a mainline kernel on those phones, even if they have the technical skills to do the replacement. The sad fact is that no mainstream phone available runs mainline kernels. A session at the 2015 Kernel Summit, led by Rob Herring, explored this problem and what might be done to address it.
This indeed a big problem, and I’m glad it’s finally being picked up.
There are really two distinct problems:
1. Getting the necessary code open sourced and mainlined.
2. Granting users sufficient access to perform a kernel upgrade themselves.
This article discusses #1, but I don’t think we should forget #2. The “tivoization” issue is supposed to be solved under GPLv3, but alas Linus opposes it. Not all the linux bigwigs do though, Alan Cox appreciated the changes in GPLv3.
This debate shouldn’t be limited to phones since many other embedded consumer devices share the same problem. There are quite a few times I’ve wished that I could reprogram my hardware.
I think I’m one of those people who don’t care, phones are disposable, cheap items that I can buy for £40. Frankly, at the kernel level I really don’t give much of a to55 what happens.
yerverluvinunclebert,
I hate the disposable culture, IMHO that’s something everyone should care about, although I suppose that’s a side issue. It’s not merely about prices and externalized costs though, it’s that sometimes manufacturers are terrible about supporting their hardware and often times third parties can do an even better job than the manufacturers, or at least they could if the code was modifiable. I believe we would see more innovation if not for such barriers.
I agree with you but even if the code was easily accessible & modifiable, there’s still that disposable culture part. Do the Average Joe’s who treat cellphones like toothbrushes care enough to invest their time into modding/hacking their phones OS? I don’t know that there’s any real payoff there for a person who’s happy just trading up to the latest & greatest.
I’m all for people having the opportunity at least – you never know what may come out of it. But, changing the disposal culture mindset seems like an extremely difficult task and I’m not sure cellphones are a good platform for trying to change that.
I think this isn’t about modding the phone, but probably things like more frequent (security) updates.
Is that an honest concern? I’m not aware of any carriers who leave known security holes (especially of the high risk type) in their products. A lot of exploits can’t be utilized without certain permissions or access that a user with an unmodified phone doesn’t have. Security should always be a concern but perspective counts for something too.
The point is that I do not care if there is an o/s inside a phone. The whole perspective is different. I’d rather it didn’t have an o/s at all. If it was hard wired using cables I’d be just as happy. It is a small device that I use to make calls and as a scribble pad when I’m bored. I have a real computer and I care about that, not the phone. The phone is a gadget and it must just ‘work’. If it impresses me on the way to working then I’m even more happy.
I smash/throw away/lose phones once very two months or so. They are lucky to survive longer than that.
Edited 2015-11-24 17:18 UTC
1) From the very very select group of people that show up to your meeting people indicate that they would like to be able to but also would not do so
2) The session ended with developers determined to improve the situation, but without any clear plan for getting there.
Linux was simply not meant to run on phones. It needed the Android team to get things started and the mega-power of Google to finally make a tremendously popular user-facing Linux distribution.
I was actually under the impression that there was a healthy back-and-forth going on from Linux to Android and back but from this article it seems that Android is a complete fork where there is no upstream and backporting. That is quite a shock for me, but this picture seems to paint the same picture: https://source.android.com/source/code-lines.html
while the text below it seems to indicate that there is some back-and-forth (or working in mainline directly) going on:
It is clear that above the AOSP / Platform level Android is entirely Google/OEM controlled and pretty much closed but the same can be said for Amazon-Android and Chinese-Androids.
I think there is no hope for figuring this out. The only incentive for Google+OEM to OpenSource everything above the AOSP level would be to please those “27” people mentioned in the article and possibly to save work patching/securing the older Linux kernels. Apparently those incentives haven’t been worth the trouble in the last decase
Linux is “meant” to run anywhere you can manage to get it to “run”. It’s that simple. Whether you would want to run a mainline kernel without extensive testing and bug fixing is a different story. Also, Android IS a Linux distribution to begin with!
Android is a cohesive whole meant for touch input devices, Linux is but the kernel of an operating system/environment. Theoretically you can run any mainline kernel where you have drivers and firmware for the hardware, but I fail to see why anyone would want to outside of “because I can”. This is one of those cases where running a company’s (like Red Hat, Google, IBM) version of the kernel is far preferable to running the vanilla version simply because the vanilla version moves too fast for proper testing to occur on something so sensitive as an OS’s kernel. Newer isn’t always better.
Edited 2015-11-24 15:02 UTC
Considering how dependent people have become on their cellphones, stability should be a top priority. If for no other reason, running a mainline kernel on a cellphone amounts to a novelty and nothing more. Using the device at the center of `your` daily life for alpha/beta testing is a bad idea.
Then again, maybe people should do it so there’s higher risk their cellphone will stop working. If that happens then people can rediscover things like paying attention when they drive, taking a walk, enjoying nature… They might even learn the lost art of making eye contact and saying “Hi”!
There is back and forth between the mainline kernel and the android AOSP one, the issue is drivers, I think. If you look at any embeded linux device, you’ll typically see lots of hacks. Device tree and Uboot, have reduced this considerably, but its still a wild world out there.
FYI, this driver issue with Android, is the reason why the original MotoX never got Lollipop. If there was some solution for it, it would be good not just for some abstract desire to have a mainline kernel on a phone, but it would also help with android updates as well.
Many that never develop for Android think it is a Linux like system with a bit of Java.
It is quite the opposite, Android Java with a little bit of UNIX underpinnings.
Google could replace Linux (the kernel) with something else (POSIX like) and hardly anyone would notice.
The whole userspace APIs are Java based.
The APIs exposed to the NDK a subset of POSIX, the C and C++ runtimes and a few JNI wrappers to the Framework APIs more relevant for game development.
They can, but they aren’t. Android is still a distribution of software based upon the Linux kernel. That doesn’t mean it’s anything like OpenSUSE, RHEL, or Ubuntu, but that’s also immaterial.
You speak like you’ve never done any programming requiring system calls. There is a lot of code invisible to app programmers in Android that would have to be rewritten to work well on a kernel other than Linux. These are called “Linuxisms”. It’s non-trivial to rewrite all the invisible glue between the Android run time and the kernel. You can’t “just swap out the kernel” for say NetBSD’s kernel and expect it to work without a lot of work even if NetBSD were fully POSIX compliant (Hint: It’s not & neither is Linux). They only aim for compliance “where possible” and there are a lot of system specific system calls specific to Linux (or *BSD). It’s more than just adapting system call semantics. The system calls also sometimes behave differently so any code that depends on the previous behavior has to be checked and changed to reliably work with the new behavior.
Those changes may not alter the app level API semantics, but they very well may change expected behaviors with more demanding programs like games, where sometimes, just changing a phone that otherwise has similar hardware characteristics can still break an app because expected behavior changed.
My Android programming is mainly in C++ with Java for the views, as I code between Android and Windows Phone.
Any call that isn’t described as stable by Google either in NDK or AOSP documentation, can be removed under your feet between Android releases.
So if your application is doing any Linuxisms, bad luck.
The only ones that would complain are the OEMs and mobile operators, as they already customize the kernel at their own will. Most likely they wouldn’t care if Google provided them enough incentive to follow along.
There are lots of UNIX like OSes to choose from, *BSD and GNU/Linux aren’t the only alternatives.
So that’s a “no” to my question. My point was that “behavior” also means latency and timing issues along with the semantics of calls initiation and return codes themselves and any bugs that have to be worked around. App writers may or may not have to deal with them, but people working on system glue DO have to deal with them. Simply changing out the kernel from Linux to *any* other kernel, Unix-like or otherwise is not at all trivial. Sure it can be done, that doesn’t mean it’s worth the effort. There may be no “Linuxisms” in your code, but I can certainly assure you there’s are plenty inside the user space glue and the top level APIs.
It’s very difficult to actually do “linuxisms” on Android. They’re using a BSD libc for a start.
It’s trivial to change the kernel on Android as the original poster said, and some proof is on the various “Windows” ports of Android, e.g. windroy. In fact I’m quite sure that was an Android design goal. Some programs break, of course, but those would also break with other changes such as upgrading the kernel (despite what they say, Linux breaks compatibility with itself every so often too).
Another topic is hardware support, which is what they got from Linux “for free” in the first place. These days, as can be seen from this very post, it’s mostly us trying to get some of Android’s hardware support back to Linux.
The truth is that Google has no attachments at all to Linux, much less to the mainline. And thus mainline has not much to offer to the average Android phone developer; they are much better following their SoCs branch (which will probably follow Google’s branch) than mainline.
Edited 2015-11-25 18:46 UTC
Is there even a Linux distro that uses a mainline kernel? Even Gentoo from what I remember had their own kernel package.
Don’t Ubuntu and RHEL’s kernels also have a bunch of patches applied to them which aren’t yet merged?
Linux from source!
But really, I think when they say “Mainline” they mean one that is closer to Mainline. Rather than a generic kernel from Linus’ tree.
I’m pretty sure I can replace the kernel shipped with Fedora with a stock one built from Linus’ tree today with my older rigs with not any crazy hardware in them. So while they might not ship with mainline, distros can usually be mainlined fairly easily. That is not the case with Android right now.
If not merged and the distros maintainers put effort into maintenance, who cares as long as the distribution works with mainline kernels?
Except that for Android phones there’s actually _a_ “supported” kernel version 😉
Jokes aside, Laptop support in Linux is still problematic, for the same reasons. Once you have it working on a non-standard config, you’d better not touch it, cause every kernel upgrade will give you new issues to deal with.
Of course, if you know which well supported hardware to pick, you’re fine, but then again, it is more or less the same with Android on phones… Choose Nexus, and you’ll have pretty decent kernel support, choose something exotic, and you’re on your own trying to get it to work.
Linux is great on commodity, bog-standard hardware, on anything else it is a lot less appealing….