Live data from Hacker News

Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

arstechnica.com

151–160 of 226 posts

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#151
post #61

Earlier quoted context omitted.

Are you implying the 'no stable binary ABI' policy is responsible for a lot of e-waste?

I mean, that seems to be the result, yes? The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space.

> The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space.

But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#152

Isn't this (binary blob drivers) an obvious violation of the linux kernel's GPL license? I presume that there's a good reason why that isn't being enforced, but I would like to better understand why.

There are intentional loopholes left in the kernel to allow such drivers (Nvidia, fglrx, etc. are also closed source). There are some rules though: Kernel module is always open source and cannot use all the symbols. Also, using such driver marks the kernel tainted. There are some very valid reasons for not releasing open source drivers. NDA bound 3rd party code is one (Java had it, fglrx had it, HDCP stuff has it, In…

The sad thing is that all of the "reasons" are really only enabled by a lack of competition.

Customers want devices with in-kernel drivers. Not just curmudgeonly Richard Stallmans who care about the plight of the wild libre, but Joe Sixpack who just wants to be able to keep using the phone he likes instead of having to buy another one every other year. There is a market for that. Regular people would choose it on purpose.

And it's not being satisfied because Qualcomm keeps buying up their competitors. Because they dominate the Android market and the incentives of an effective monopolist are different than the incentives of a competitive market.

If you're one of five equally-sized chip makers, you don't care that the customer isn't going to buy a new phone for ten years instead of three, because with high probability they could buy from one of the other four next time anyway. And because you need a competitive advantage to get the sale today, and "don't have to buy a new phone after three years" is that.

If you're Qualcomm, you get the sale even if you don't offer the advantage because there is no viable alternative, and then you get another sale in three years.

Time to break them up. Or at least, and I mean come on, stop letting them buy their competitors.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#153
post #77

Earlier quoted context omitted.

This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from…

>as an effort to make the cost of keeping drivers closed-source high I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.

Ironically, they care a lot about stability towards user space interfaces, to the point that bugs become features if someone depends on them, but they don't care about driver interfaces being stable.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#154

Earlier quoted context omitted.

>as an effort to make the cost of keeping drivers closed-source high I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.

It's somewhat pragmatic for the Linux developers. Support a stable kernel API probably wouldn't be that expensive. It's clearly a political decision against writing close source code that does anything low level.

[deleted]

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#155

Earlier quoted context omitted.

> It's not just Qualcomm it's closed source driver blobs in general. To be precise, Qualcomm's Linux drivers are GPL'd like the rest of the kernel. Drivers often come with firmware blobs and proprietary binaries in userspace, but it should be possible to keep the kernel driver compatible with both. The actual reason why older SoCs stop working on newer Linux kernels is that Qualcom's drivers were not fully upstreamed…

My understanding is that a number of Android vendors operate by just taking a version of the Linux kernel and making any changes they need. By the time the phone is released and anyone cares, it's an old version of the Linux kernel, and the changes weren't written in a way that it's easy to incorporate them in the first place. The idea of incorporating a large chunk of changes all at once at the end is nobody's idea…

The SoC manufacturer provides to the OEM exactly one kernel version that works on that chip.

The OEM has to use that version. Oftentimes the SoC manufacturer will deliberately make it an old version because they know that the next android release will require a newer kernel version, therefore forcing the OEM to update to a new and more profitable SoC rather than continuing to sell an old model.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#156
post #2

Why would a company which holds an effective monopoly over Android chips in the US do anything in order to discourage the sale of new chips? Providing support for older chips would hurt sales. Qualcomm is abusing its monopoly position and the laws/patents that allow this need to be changed. Qualcomm is a great example of how IP laws can hurt progress and competition. In the future China and other countries will leapf…

Google holds a far stronger monopoly than Qualcomm ever will. If Google required the driver support as a condition of allowing Android devices to be distributed with their hardware, Qualcomm would have to comply overnight. Every single Android device from every manufacturer that wants access to Google apps must be approved by Google, and compliant with Google's terms. The "poor Google is at the mercy of other compani…

That's a strange take considering millions of devices sold across the world running AOSP Android without any kind of Google software. From Huawei/Oppo phones in China, car infotainment systems, tablets used in Enterprise environments... Your own post doesn't really square with reality.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#157

It's not just Qualcomm it's closed source driver blobs in general. Even if your CPU might still be supported your other hardware might not. A common offender is camera drivers as far as I know and while you sometimes can still make the camera work it often comes with noticeable decreased quality (as the special patent encumbered closed source image post processing sausage is missing). Besides that potential but as fa…

> A common offender is camera drivers

This is precisely why open source libcamera[1] exists.

[1] https://libcamera.org/

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#159

It's not just Qualcomm it's closed source driver blobs in general. Even if your CPU might still be supported your other hardware might not. A common offender is camera drivers as far as I know and while you sometimes can still make the camera work it often comes with noticeable decreased quality (as the special patent encumbered closed source image post processing sausage is missing). Besides that potential but as fa…

Android should have been GPL

Apache License 2.0 is GPL-compatible, isn't it?

Edit: expanding the acronym, to evade Android/Apache confusion.

Re: Fairphone suggests Qualcomm is the biggest barrier to long-term Android support

#160

> First, your SoC (System on a Chip) manufacturer (usually Qualcomm) has to get hold of it and customize Android for a particular SoC, adding drivers and other hardware support. Then, that build goes to your phone manufacturer (Fairphone, in this case) which adds support for the rest of the hardware—things like cameras, the display, and any other accessories. Why is it so easy to boot any linux distro on almost any d…

It's hard to make devices as small and thin as a modern day smartphone while keeping its components modular at the same time. Now, this might be an acceptable tradeoff for you in particular, but Apple, Google, Samsung et al have probably already determined that it's not worth catering to that market segment.

Size has nothing to do with size or modularity. The same Qualcom chips get used from smart watches to tablets to cheap PCs, there's plenty of variety going on there. The difference is that the mobile SoCs are designed differently, requiring a complex system of bootloaders to even turn on that can change between models or even revisions of the chips.

The second problem is the proprietary nature of the chips. The PC became popular because other manufacturers copied and reversed IBM's BIOS and hardware, bringing a huge variety of available hardware that runs the same software. The only way that model could be profitable was to make sure everyone stuck mostly to the same standard, because breaking compatibility made your computer significantly incompatible with existing software your customers want. The crux of this requirement was that the user brought the software to the hardware, and the manufacturer could at most provide an operating system with a few tweaks at risk of breaking whatever the user wanted to run. This backwards compatibility still exists today, to the point that many BIOS update tools from manufacturers will boot FreeDOS to flash chips, running a software architecture older than many of their users on bleeding edge x64 chips.

The mobile ecosystem is designed so that devices last two, maybe three years, after that consumers throw their phones out and buy a new one. If you want to use your phone for longer then good luck, hope you bought a brand that ships you updates.

Qualcom, Huawei and Mediatek do not share the same level of compatibility the original PCs did, because they control the software supply chain. You don't take your software to Qualcom and make it work, you take Qualcom's kernel and then write your software. If Qualcom doesn't want to update the kernel version for your chip, good luck getting Android to boot; their open source drivers probably won't work because they either don't exist or are shoddily designed to fit only one kernel.

There's ongoing work over at the postmarketOS to mainline existing devices. Mainlined devices can run a proper, modern version of Linux with normal update support like any operating system, though Linux distributions often fail to properly implement things like deep sleep that are essential to using a phone. It'll be a while before mobile Linux becomes viable.

Then there's Apple, kind of a weird manufacturer in that they provide updates for well over five years even for slow mobile devices. They can do this because they don't need to buy chips from a manufacturer with an incentive to provide as little support as possible so end users buy new devices. They're also too popular for Linux not to hack in support for their weird, proprietary architectures.

All modular prototypes for Android have had the same problems with chipset and operating system constraints their constant-hardware cousins had; the same kernel supply line, with the same update problems.

Post reply on HN