Part of the problem is that Linux has no driver API like Windows. The result is each vendor maintains their own fork of the Kernel with their crappy drivers shoehorned in. On the next Kernel version, they have to uplift all of their garbage to it.

The problem kind of exist but the comparison is mostly bullshit -- or at least was until recently. Windows regularly breaks driver compat, even more so on Windows phone.

Only with Windows 10 Mobile they engineered a strong way to upgrade the OS without needing vendor intervention too much (or at all?), it is a shame Windows Mobile market share as fallen so low and Windows Mobile is not even a priority of MS anymore :/

On Linux side, some (most?) phone vendors are most of the time not supposed to distribute the kernel and their binary-only driver the way they do it, because most of those distributions are likely GPL violations. The sad thing is some high profile organisations (Linux Fondation comes to mind) don't give a fuck about licence compliance, which is insane given the technical side NEEDS licence compliance in order for the end result to work well and not be dangerous for end-users for a large part of the ecosystem. (Worse, the Linux Fondation happily accept obvious GPL infringers at the highest levels.)

Anyway the kernel part is a small part in an Android distribution, and I'm not sure anything is available to handle the security update problem, or that somebody is even working on it... The technical update model MS has chosen is the way to go and Google is endangering us all by having such a huge market share and not wanting to take any responsibility that should come with it. (It's even worse given how Android has reached this market share levels, using practices that would make look past MS ones as respectful of competition!)

> Part of the problem is that Linux has no driver API like Windows. The result is each vendor maintains their own fork of the Kernel with their crappy drivers shoehorned in.

Linux has a driver API; the interfaces are not as stable as windows but they are there - the vendor shoehornning has more to do with closed hardware blobs, drivers not being developed in the open, and profits than a few struct member tweaks here and there shifting across android releases..

the handset manufacturers have no profit incentive to ensure that the phones are compatible for a longer term, and keeping the hardware drivers closed/behind version-specific blobs serves as convenient way to facilitate planned obsolescence

plenty of windows hardware doesn't get new drivers across OS release boundaries for the same reasons so slightly better API stability is not really a very good argument here on its own..

To the best of my understanding, Linux has the ability to add and remove drivers to the system. Android should have a package manager for these drivers to allow for updates in the same manor.

Well, if you have control over which patches you accept, you've created an exponential explosion in the testing state space. That may be even worse for security, never mind reliability.

Still, somehow Linux distros are reasonably safe but Android is broken.

Not sure about the linux distro being safe part. Linux desktop distros are also riddled with vulnerabilities that no one bothered to look. This is along with the bad design of the desktop in the first place as there're no isolation between apps and so forth.

Example: https://arstechnica.com/security/2016/12/fedora-and-ubuntu-0...

Android on the other hand, has isolation mechanism built in as the central thesis of its apps system. Additionally, it also has some additional layers on top.

Unfortunately since nothing gets updated it maybe all moot, but I don't think somehow Linux distros are more secure.

Well, GNU/Linux distro are usually patched. Main ones for pretty much all known vulns. Tons of Android systems are not patched. I don't think any of those is secure against anybody motivated enough (and I'm not even thinking about a 3-letter agency, but any hacker competent enough!)

Arguably the security model of main desktop OSes is bad enough so that they are also easy to penetrate. That should not make us dismiss the problem of the way too many unmaintained Android systems!

The Dalvik system that runs on top does indeed put apps into their own named processes with restricted access etc, quite a good idea imho!

But the entire system as a whole doesn't get updates to lower parts. E.g. Updating your java app doesn't solve the problems in the underlying C libraries the system uses. We're at the mercy of vendors for that, if ever.

That's a library vulnerability, nothing to do with bad design of the desktop.

> but instead of a tiny 1Kb diff patch

Wouldn't this require phones to compile their own kernels?

>You could have a bug in a single binary at the kernel level, but instead of a tiny 1Kb diff patch you wait a year for a giant 1.2 GB vendor update that also contains a lot of other changes you have no interest in.

Security patches are not 1+ GB in size - no where close to it. You're referring to OS updates that completely replace the old OS.

So there are security patches in Android? So the problem seems to be: some vendors seem not interested in distributing them... :/

Google distributes patches each month to OEM's 1 month before they're released. Some OEM's merge them into their code base and create a patch while others don't really care.

Does android have a patch mechanism OEM's can use to distribute the patches or do they have to distribute a whole new image?