Nonetheless they have clarified that Android is a Linux distribution and that they include Android when they say “Linux operating system”. Furthermore they clarify what that means when they say “the Linux kernel and its surrounding userspace tools have become the most popular open source operating system in the entire world.” i.e. any OS with a Linux kernel is a Linux based operating system.
If you can’t back up your claim with anything more than anecdotes, don’t make the claim. Also, your claim wasn’t about “major number upgrade of its kernel”, it was about “kernel upgrades”. The only anecdote you provided that I found surprising is that the Pixel 5 upgrade to Android 13 didn’t have a kernel version bump to 5.10 (the lowest original release version for Android 13).
And speaking of Fairphone, I just read that the Fairphone 5 is coming with 8 years of support guaranteed and that they are discussing with the chipset manufacturer whether they can extend that to 10 years.
I like Rob, but I also think that sometimes his videos are a bit narrow sighted. Also some of the things he omits lead me to question his credentials. People who talk about security but never point to a real application of the need for that security are kind of like digital snake oil salesmen. At least I have kind of suspected that a few times.
I would love to see the Linux Foundation explain how we can use the drivers for a Snapdragon, Exynos, Dimensity or any other chip whose manufacturer only supports Android in a mainline Linux kernel or explain to the developers of libhybris why their code is unnecessary.
If you are going to claim that Android really is Linux, the authority on that question is Google, not the Linux Foundation, since Google is the developer, and Google’s documentation calls it ACK for “Android common kernel” or “andoid-mainline” and studiously avoids using the word “Linux” and instead calls it “LTS kernel” when it gets code from the Linux kernel. Here is how Google describes its kernel:
Before 2019, Android common kernels were constructed by cloning the recently declared LTS kernel and adding the Android-specific patches. This process changed in 2019 to branch the new Android common kernel from android-mainline. This new model avoids the significant effort to forward port and test Android patches by accomplishing the same result incrementally. android-mainline undergoes significant continuous testing, this model ensures a high-quality kernel from the day it’s published.
When a new LTS is declared upstream, the corresponding common kernel is branched from android-mainline. This allows partners to begin a project prior to the declaration of the LTS version, by merging from android-mainline. After the new common kernel branch is created, partners can seamlessly change the merge source to the new branch.
In other words, the Android kernel since 2019 starts as a seperate kernel that merges in code from the latest Linux LTS, so it is no longer a derivative of Linux LTS with added patches. Since 2020, Google has been naming its kernels with the specific version of Android it was originally created for, such as android11-5.4, which further indicates that its kernels now start as separate from Linux and then merge in Linux.
A minor version number change in the kernel (such as 3.4.0 → 3.4.113) is not a “kernel upgrade”–it is adding bug fixes and security patches. An upgrade is moving to a new LTS such as android11-5.4 to android12-5.10, and I can’t find a single example of an Android phone making that kind of upgrade to its kernel. In fact, the Android kernels since 2020 no longer include the minor version numbers and just list the date such as android12-5.10-2022-03.
I just provided you with proof that the Fairphone 2 stayed with the 3.4 kernel for its entire existence between Dec 2015 and Mar 2023 and that Google is not upgrading the kernels in its Pixel phones. I can’t give you web links to the other manufacturers to prove that they aren’t upgrading their kernels because they aren’t publishing this information and the chipset manufacturers also don’t publish it.
You haven’t been able to point to a single Andoid phone model with an upgraded kernel and your Quora link isn’t evidence in my opinion, since it isn’t clear that the responders understand that a kernel upgrade means a new LTS. I have seen pretty good evidence from my workshop that Android phone manufacturers aren’t upgrading their kernels, but the sample of 30 phones was admittedly small and only included phone brands sold in Bolivia (which is mainly Samsung, Xiaomi, Huawei / Honor, Sony and Motorola).
In the interest of resolving this debate, we should ask everyone run uname -a on their Android devices and post their results to see if we can find any with a kernel that is newer than the year of the original release of the phone. I will start by posting new threads here and at r/purism to ask that question. Feel free to suggest any other public forum where you think I should post this question.
As I already said, The Linux Foundation controls the Linux trademark.
You should really say “… claim Android really is a Linux based OS” rather than “… claim Android is Linux”.
You’ve ignored the first sentence of their (Google’s) document. Perhaps you don’t know what “downstream” means??? I’ve seen you make repeated mistakes when you’ve used “upstream” and “downstream” before. That must be it.
AOSP common kernels (also known as the Android common kernels or ACKs) are downstream of kernel.org kernels and include patches of interest to the Android community that haven’t been merged into mainline or Long Term Supported (LTS) kernels.
What you described is not a minor version number change. That’s called a subversion number change. A “minor” version change would be from 5.10.* to a 5.15.*.
And even that ignores the fact that the Linux kernel doesn’t actually rigorously use Semantic Versioning.
Right. You just gave anecdotes to support an assertion that " … almost none of the Android phones that get OS upgrades will ever get a kernel upgrade". As I said, if you can’t show your assertion, you shouldn’t provide such strong assertions. Stop over-asserting.
And, actually, you only showed that the Pixel 5 stopped at 4.19.*. That certainly doesn’t encompass all Pixel phones, does it? Again: Stop over-asserting. It’s exactly that behavior that got Micay pissed off and got you temp-banned from reddit. It’s a problem. Stop it.
The Pixel 6’s HW and drivers is more controlled by Google and their releases make it easier to put different versions of the kernel on the device. The Pixel 6 was released with 5.10.* and Google has mainly made that available, but some developers quickly put 5.15 mainline on their Pixel 6. Maybe you should read and explore this: https://www.xda-developers.com/google-pixel-6-6-pro-mainline-linux-kernel-support/ . You continue to confuse “what is typically done” with “what can be done.”
Yes, some Google developers did it, but you have to ask why didn’t Google make that kernel part of Google’s official release for the Pixel 6. It costs chip manufacturers a lot of money to develop separate drivers for Android and Linux. Why bother if Google hasn’t implemented differences in the kernel which cause problems for standard Linux drivers?
Where have I confused upstream and downstream? I explained that the Android kernel used to be the Linux LTS with added patches (i.e, it was a downstream derivative of Linux LTS), but since 2019 Google has maintained its own kernel that merges in new code from Linux LTS every year.
My point is that Android is incompatible with Linux because they can’t share drivers, so it isn’t correct to say that the Android kernel is Linux. I think that most accurate term would be an “incompatible derivative”. Your pedantic arguments don’t change the fact that chip manufacturers have to make separate drivers for Linux and Android, and trying to add support for the Android mobile SoC’s (Snapdragon, Exynos, etc.) to mainline Linux has proven to be a long and difficult process.
Yes, it does. I can’t find a single Pixel or Fairphone model which has had an official kernel upgrade. I started this whole discussion speculating that Samsung might have to offer a kernel upgrade, and Pixel’s SoC is based on Samsung’s Exynos, so maybe Google will offer kernel upgrades in the future, but they haven’t so far. I can’t verify this for the other phone manufacturers, because they aren’t transparent like Google and Fairphone, which is the whole point of me asking a large number of people to post their kernel versions so we can verify whether they are upgrading their kernels or not.
That is baloney. I got banned for 30 days from r/purism because I posted a link to Techlore’s video which proved that Micay has made false accusations against many FOSS communities, just like he made the false accusation that I was organizing raids against the GrapheneOS community. All you are doing is trying to stir up trouble by repeatedly bringing it up. Stop it.
What do you think libhybris does? It allows a kernel.org kernel of the same version that was used when compiling the Android driver to uses that Android driver. The fact that libhybris works shows that you are incorrect regarding assertions that “they [Android and kernel.org] can’t share drivers”.
I actually believe that for the most part Android and Linux can share driver source.
Background: The issue about not being able to share binary drivers is true even between two kernel.org kernels —> they can generally use the same source, but they can not share binary drivers. Specifically, loadable kernel models [.ko’s] compiled for one kernel will not load for a different kernel — it’s an intentional feature. It usually only requires a recompile, but it requires that. Read up on DKMS – it’s a system set up to try to automate such recompiles. And realize that it’s even more difficult for drivers for Android kernels vs. kernel.org kernels because Android uses Bionic instead of glibc … which is where libhybris comes in for non-Android use of Android drivers.
As you can see, the difficulty with sharing binary drivers has nothing to do with whether
Android is a Linux based OS … since two different kernel.org kernels can’t share the same
binary driver. Similarly, the whole point of libhybris is to allow kernel.org Linux kernels to use Android binary drivers (linked to the exact kernel version numbers).
You keep trying to pretend that Android isn’t downstream from kernel.org and that Android releases aren’t based on kernel.org LTS releases. They are. The only change they made in 2019 is in the process of having one extra step (which allows more concurrent testing of Android releases with the kernel.org rc kernels rather than waiting for a kernel.org LTS release ). You’ve completely misinterpreted what they are doing.
LOL. As I’ve said above, the same can be said with any binary drivers (given as .ko’s) between different versions of kernel.org kernels. Those are both Linux and they can’t share binary drivers.
You would know this if you ever had to maintain source for your own drivers. I had the source for one of my network cards that wasn’t part of mainline. Every change to the Linux kernel on my distro required me to recompile my driver before it would load. This is intentionally a feature of the Linux kernel and Linux kernel loadable modules.
LOL. You just asserted that showing something about the Pixel 5 proves it for all Pixels (e.g Pixel 6, Pixel 7, …). That’s absurd.
Furthermore, I showed that Google released a kernel upgrade to their source archive for the Pixel 6. Google hasn’t done so for an official release that got pushed OTA, but nonetheless people have used that to release images for the Pixel 6 using kernel 5.15 and/or 5.10. i.e. It is on some people’s Pixel 6 phones.
Your incorrect over-assertions are, IMO, exactly why you repeatedly have pissed off Micay. The fact that he was already pissed at you is why he reported you for harassment — which is exactly what it was IMO. You have a problem. In almost every interaction I’ve had with you, I’ve tried to point out your over-assertions. You never seem to get it. The pattern is:
You make an assertion. Someone says that it’s not true and you are challenged to prove your assertion. You create a wall of text, but you never prove your assertion. You later make the same assertion … and still don’t prove your assertion. It’s as if you never learned that your assertion might be wrong and that you shouldn’t make it if you can’t show it.
IMO Techlore’s video was deceptive and incorrect. And you believed their video and spread it without even reading Micay and other Graphene dev’s comments —> they were actually able to prove that some of the evidence presented on Techlore video was faked.
To add some anecdata aside from what has been mentioned regarding newer Pixel devices: I recall that Sony has been bumping devices to newer kernel releases - it was mentioned in this FOSDEM talk: FOSDEM 2023 - Sailing into the Linux port with Sony Open Devices
Specifically, the speaker in the linked FOSDEM video at around 2min in says:
… And also the lifetime is really long. Whereas for some other devices you may be stuck on one kernel, Sony Open Devices actively upgrades the downstream kernel that they have to the devices …
The linked chart showed that they have been typically providing 2 or 3 kernel upgrades over the support lifetime for the Sony Open Devices.
Given the context, I believe Vertebra’s question is disingenuous. That said, it’s possible that some people don’t understand that while the structure and features of these kernels might be considered “old”, the kernels themselves are up-to-date in terms of bug fixes.
For example, kernel 4.19 was originally released in Oct of 2018. It’s an LTS release and the 4.19.* kernel version(s) is patched for security and bugs by kernel.org through Dec 2024. Its most recent patchlevel is 294 which was released 3 days ago (Sept 2, 2023). https://kernel.org/ . What that means is that the 4.19 kernel series has had 294 releases for bugfixes.
This brings up the question: Are people here being slightly irrational by placing a high value on the “most recent major.minor branches”? I think so. I actually think people are assuaging their disappointment in having a slower SoC (and stone-age power management, camera software, modem reliability, …) by over-inflating the importance of having more recent major.minor branches. Do most people even know what recent major.minor features are useful for their phones? The only feature that comes to my mind is exfat being mainlined in, I think, the 5.10 release. The only real advantage IMO is that eventually the LTS support on these “old kernel releases” ends. If that support hasn’t ended, it’s not a big deal IMO.
To be fair, Micay/GrapheneOS seems unusually thin-skinned.
I have another example of that, from this podcast (in Swedish) from three months ago, where at 01:35 the Swedish security expert Karl Emil Nikka says that while he was earlier planning to make a podcast episode about GrapheneOS, he is no longer going to do that because of their extreme habit of blocking any kind of criticism. Apparently Nikka was posting something potentially critical about GrapheneOS on social media and then they blocked him on both Mastodon and Twitter.
So, if @amosbatto got banned by GrapheneOS he is in good company.
It’s hard to know. He does seem to exhibit some paranoia and make random accusations at times. Being swatted seemed to have really affected him. Have you ever been swatted??? As an aside: I hope you’re aware that Micay has stepped down from the Graphene project.
That said, while amosbatto seems to have less turbulent behavior, I much prefer my interactions with micay and others at GrapheneOS to those with amosbatto. By far.
So, if @amosbatto got banned by GrapheneOS he is in good company.
amosbatto was temp-banned (30 day suspension) from Reddit for harassment (of Micay). I’m unsure if amosbatto was banned from the GrapheneOS forum ( https://discuss.grapheneos.org/ ) or their twitter. It wouldn’t surprise me.
You characterize Karl Emil Nikka as a “security expert”. He seems to be just a tongue-wagger to me: https://twitter.com/KarlEmilNikka/status/1662020173878968328 ( Yes … that was the tweet that got him blocked https://twitter.com/KarlEmilNikka/status/1662142982949158939 . His conclusion from being blocked was that the project is being mismanaged — that’s an obvious logical disconnect and false conclusion). According to his linkedin page, it seems his degree is in “Theology” not CS or something else remotely relevant … after which he was a “salesperson” and eventually moving up to training/education at a computer/electronics manufacturer. Currently he describes himself as an “Author and IT Security Specialist, focusing on Security Awareness training” at Nikka Systems (his own company and he’s the only employee). I’m unsure why you would call him “good company” — unless he is more impressive in Swedish.
I always appreciate the writing of @amosbatto, and I always learn something from it. I cannot say who’s right about technical disagreements, but during my years using this forum, @amosbatto has been among the few making the richest contributions. @Privacy2, please do not be insulting.
