
Bringing the Android kernel back to the mainline - Tomte
https://lwn.net/SubscriberLink/771974/ade4e5fb18058302/
======
pedrocr
When I buy a laptop I install whatever is the latest version of Ubuntu on it
and am done. When I buy an access point I install whatever is the latest
version of OpenWrt on it and am done. I've tried to do the same thing with
phones using LineageOS but it's hopeless. Devices are often half broken and
are never guaranteed to continue being supported because of this kernel mess.
It seems there's slow progress being made which is nice. I was hoping Android
One phones would at least guarantee monthly security updates but it's still up
to the manufacturer if that happens or not.

~~~
nextos
There's a compromise solution to achieve something equivalent. And I say so
after having tried many possibilities.

Buy a Pixel or any other phone that supports AOSP (Sony does too, with some
caveats) and install plain AOSP.

It's not perfect as you need a bit of infrastructure to compile it yourself
and keep OTA updates. But it's the most practical secure and privacy-
respecting option, I think.

~~~
metildaa
The shoddy build quality, plus lack of microSD & heaphone jack means I will
never buy a Pixel or other Google branded hardware.

My friends seem to get a year or so before the SoC desolders from the
motherboard, causing the device to bootloop, or the battery fails, or one of a
million other things. Among us, there are a few dozen Pixels that are unusable
due to their hardware defects.

Meanwhile, both of my old Galaxy S4's is going strong, and ditto for all but
one of my LGs (one had its charge controller start smoking, LG repaired it).

~~~
noderat
I have owned since launch day a Nexus 1, Nexus 4, 2x Nexus 6, 2x Nexus 7 and
Pixel 2 XL and they are all currently still functional well past their
warranty. (The Nexus 1 was replaced by Assurion for water damage with a
refurbished device @1.5yrs but replacement is still running.) In fact my Nexus
4 is still in use every day as an APRS GPS receiver/data logger, and one of
the Nexus 6s is now in use by a co-worker as a OBD2 data logger/HUD.

I've avoided Samsung devices (including Galaxy Nexus/Nexus S) because the
girlfriend has had the last 4 Samsung devices fail or become completely usable
right at the end of the warranty (+/\- 2mo) running completely stock. For
those that became completely unusable it was usually pitiful battery life, the
others became too slow to function on stock roms that I suspect they failed
due to internal storage wear. Not even custom roms could save them.

I keep my devices a long time, and frequently repurpose them after they are no
longer my primary device. Non-Samsung "Pixus" problems are overblown, except
Nexus 6 AMOLED burn-in which is annoying but didn't present itself until it
was used daily as a HUD.

~~~
metildaa
Seems like you missed the horrid bootlooping issues of the Nexus 5x, the bad
battery firmware on the Nexus 6p, and the bootlooping and flakey charge
controller on the OG Pixel.

Your choice in devices of the Nexus/Pixel series is very lucky, you avoided
the defective models nearly entirely. I have no faith that I will be similarly
lucky.

------
sandGorgon
This is happening because of Project Treble which creating a boundary between
device drivers and the kernel. Earlier, kernel versions (even android versions
itself) were subject to integration of device drivers into the kernel source
code... which took a long time and often resulted in forced obsolescence.

By separating out the driver interface using Treble, you can update the kernel
and android versions from upstream without worrying about driver
integration/updates.

~~~
pjmlp
This is happening, because Project Treble still requires OEMs to ship updates
and in one year after its introduction, Oreo got a meager 10% when Android P
was announced and OEMs were still shipping Nougat with updates to Oreo, which
doesn't require Project Treble compliance in such cases.

Google is finally facing the issue that regular consumers aren't caring to
update anymore, specially now that devices are quite usable for several years.

So if they want to bring new OS versions into the market they really have to
force OEMs to do it.

Hence the new GSI concept, finally adding update clauses to the Play Store
usage agreement, and now upstreaming kernel changes.

------
qubex
As soon as I read the title I started to wonder what (if anything) this means
for Fuchsia. At first I thought “oh, they’re doubling down on Linux-powered
Android and that in turn means they’ll be setting Fuchsia aside” to “ah,
adding a HAL to the Linux kernel and reproducing it’s interfaces elsewhere is
a great way to enable proprietary devices to switch OSes”. Does anybody more
knowledgeable in the matter have other thoughts?

------
bubblethink
I'll believe that real progress has been made when google updates the major
kernel version for a phone. No OEM (AFAIK) has ever done a kernel (major
version) bump.

~~~
fffrantz
Honestly, it's extremely difficult to update the kernel since it's usually
tied to the BSP the SoC vendor is providing. Also, you gotta keep in mind the
difficulties associated with the lazy 3rd parties providing drivers for a
single kernel version, making updates almost impossible. \-- Disclosure : I
work for an OEM as a system architect, and it's been one of my goals to try
and get newer kernel versions running. (Suffice to say I failed so far)

~~~
pedrocr
Is upstreaming hardware drivers to at least staging quality that much of an
uphill task? Seems like this should be fixed at the source by having the
initial development go straight into mainline. That's what seems to happen for
PC hardware anyway.

~~~
de_watcher
Upstreaming costs like several times more than just hack it and ship it. It
seems that a lot of vendors can't estimate the costs and benefits.

~~~
fffrantz
That's exactly it. And even keeping to the preferred/qualified vendor list
provided by the SoC vendor does not guarantee that the drivers will be in the
mainline... Android's use of the kernel really is fundamentally broken

------
craftyguy
Devices like the Librem 5 cannot come fast enough...

------
kristianp
All this vendor-provided code is why lesser-used hardware features like
bluetooth low energy don't work on many tablets, even new ones. Good luck
trying to get web-bluetooth running on Chrome, despite it supposedly being
supported for Android 6.0 and later [1]. Samsung seems to have good support,
but Lenovo and Vivo don't support it, despite saying they support Bluetooth 4
on recent devices.

[1] [https://github.com/WebBluetoothCG/web-
bluetooth/blob/master/...](https://github.com/WebBluetoothCG/web-
bluetooth/blob/master/implementation-status.md)

------
shmerl
_> Devices will be expected to run this kernel; to make that happen, vendors
will provide a set of kernel modules to add the necessary hardware support.
Getting there will require the upstreaming of kernel symbol namespaces among
other things._

Google should go one step further and require upstreaming hardware drivers.

------
yjftsjthsd-h
Nice to see that progress is being made on upstreaming the Android patches.
Hopefully this will make it easier for ex. postmarketOS to work using a
vanilla kernel, or at least to update the version used.

~~~
craftyguy
While hacking on postmarketOS off and on for the last year, the #1 issue was
always dealing with crappy old kernels from manufacturers with out of tree
patches that would no longer apply to the current mainline.

Unfortunately this problem will still exist with the proposal in the article,
manufacturers will still be allowed to ship out of tree code. Being able to
boot a mainline kernel on your device is practically useless if the code
necessary for display, input, audio, etc are out of tree and thrown over the
wall by the manufacturer with no intention of keeping it up to date.

~~~
ChristianBundy
This is even an issue with Chromebooks from Google (e.g. Chromebook Pixel
2015). Sure, it "runs Linux", but how useful is that if you can't put any
other distro on it? After a few years we finally got all of the Chromebook-
specific patches pushed to mainline Linux, but Google doesn't seem to care
about mainline at all.

------
DonHopkins
Misread the title as "Bringing the Android kernel back to the mainframe".
Since you can run mainframe emulators on Android, it only seems fair to run
Android on mainframes. I wonder if the code is 36 bit clean?

------
rsre
I've always found this curious since Linux fans usually mention the high usage
of Android as Linux usage. The people usually think of GNU/Linux when they
think about using Linux but the truth is Android is far from that. Be it the
lack of GNU utils, not using a mainline kernel or the myriad of blobs and
proprietary stuff bolted on top.

~~~
craftyguy
It's not clear what you are curious about. You can run GNU/Linux with out of
tree modules (e.g. proprietary nvidia graphics driver). That doesn't change
the fact that you're running a (now probably tainted) Linux kernel.

I don't think anyone is thinking of a GNU/Linux desktop environment when they
think "Android runs Linux!", they are quite literally thinking "Android uses
the Linux kernel." They are not wrong.

~~~
rsre
Of course. I wasn't talking about the population of HN, I mean it in a broader
sense, people who know GNU/Linux is a thing but don't know or care enough to
realise the differences.

I'm curious about what is there to celebrate in some huge corp using some free
software in a completely cornered use that gives little to no freedom to its
users.

I'm sorry if my points are not clear. As it has been evidenced english is not
my first language.

~~~
izacus
> I'm curious about what is there to celebrate in some huge corp using some
> free software in a completely cornered use that gives little to no freedom
> to its users.

Huge amount of money poured into development of said opensource software -
including the patches in the article you're commenting on.

Major opensource projects are (and have for years) receiving most
contributions from developers in Microsoft, Google, Intel, RedHat, Pivotal,
and many others.

------
dcbadacd
It would also be really nice if common distributions finally considered
creating feature+architecture-based repositories, small improvements that you
get by creating more specific binaries really sum up on mobile/low-powered
devices. It does require more effort (and money for storage, compilation)
though.

------
noja
Are the binary blobs staying, or are they open source now too?

~~~
yepguy
They're staying.

