If the code were open source, I'd be willing to bet quite a lot that this kind of code would get cleaned up and mainlined. Certainly for popular handsets from major manufacturers which probably account for the majority of handsets sold.

Thanks to the GPL this is already often the case (at least for the kernel). But vendor code is so abhorrent in quality, upstream efforts are few and far between.

I guess they gotta stop doing that then, huh? I don't see how consumers and society benefit from rushed, vulnerable crap software. Oh, right. Time to market. Race to the bottom. That's what we need more of.

Magic of compartmentalization of concerns.

It turns out that getting a bunch of programmers to do careful modifications to some C code base over a couple of months is more work than getting great many thousands of people across multiple companies to manufacture, distribute and sell new hardware to millions of customers.

> I guess they gotta stop doing that then, huh?

Why would they? They get paid to put out crap, so they'll continue doing it.

Bottle water continues to come in plastic bottles, even though glass if far cheaper/easier to reuse or recycle. Plastic bottles are literally trash, yet it'll continue being produced if people keep buying it.

Near-disposable phones (both hardware and software) won't stop being manufactured if they continue being in high demand.

> I don't see how consumers and society benefit

Actually, you do see. The price of your phone would be higher if Qualcomm had to hire competent engineers to make properly designed kernel changes for their hardware.

How much higher though? If you were to take the total extra expenditure on increased salaries for those engineers, and divide by the number of phones produced, the result is what? A dollar?

Sure, but when applying Marketing Math™, remember that all prices need to end in "49" or "99" to "sound cheaper" than the next incremental bump. So you'll end up with a device that is either $50 or (more likely) $100 more than otherwise.

Or they'll eat that $1 from their profit margins…eh, who am I kidding?

If they're rounding to the nearest $50, they're doing it based on the final cost. They're not going to base it on a what-if scenario of having a cheaper development team. So it's more or less a 2% chance of the price going up $50.

The price of your phone would be much lower if the software stack was truly Open Source, allowing distribution to remove clutter and spyware, and make older phones perfectly usable again.

Planned obsolescence is designed to increase TCO

> Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel.

SoC makers deliberately do this as a way to force phone manufacturers to buy new chips.

For example, if they release a chipset in 2020, it will ship with Kernel 4.14 (released in 2017). Why ship such an old kernel on brand new hardware you say?

Well Android 11 (also shipped in 2020) supports Kernel 4.14, but you can be pretty sure that Android 12 won't support 4.14. So that means that OEM's can't make android 12 work with that chip without a massive engineering effort (and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible).

So, the main reason to use a deliberately outdated kernel is to prevent last years chips running next years android release, without the chipset manufacturers permission and a share of the profits.

> and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible

Binary drivers can be reverse engineered and reimplemented for the new kernel. This takes a lot of effort since it requires following a "proper" clean-room methodology when doing so for interoperability purposes, but is otherwise doable. A complementary approach is to forward port the minimum set of features that's required for Android 12 to the older kernel, in a way that carefully preserves the portions of in-kernel ABI that the binary drivers depend on.

Reversing engineering is hard. It would be nice if the kernel didn’t trash it’s ABI all the time for ideological reasons. Hopefully a new OS (fuscia) will fix this.

Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity.

I can see why Android was so popular with OEMs!

> Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity.

You can sometimes run 20 year old drivers, assuming same ISA and that none of the ABI has changed, which does in fact happen, just more rarely. Windows 10 is certainly not compatible with 100% of drivers from Windows 7, let alone XP (20 years ago is 2001, so Windows 2000 is actually likely).