Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

141–150 of 226 posts

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

#141

Post by 10000truths »

surround wrote: post #139

> 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.

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

#142

Post by bitmapbrother »

swiley wrote: post #47
kogir wrote: post #5

Qualcomm is only able to obstruct in this way because Linux doesn’t keep the kernel driver ABI stable for any fixed period of time. If Android used FreeBSD and Qualcomm shipped drivers for the latest build when the SoC was released, you’d have up to five years of support from that kernel release. Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the pl…

The Linux driver ABI doesn't need to be stable because the drivers are supposed to be published under the GPL. This way manufactures just need to help get their drivers upstreamed and are largely off the hook for support after that. Androids awful graphics API is hack that allows Qualcomm to keep the driver source closed which means the BSPs rot and you can't use your phone after 2-3 years. I'll happily buy a 10 year…

Qualcomm is allowing their GPU drivers to be updated via the Play Store. This started in 2020 so it will only apply to Qualcomm SoC's released from 2020 onwards.

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

#143

Post by jokoon »

PurpleFoxy wrote: post #122
Naac wrote: post #62

Earlier quoted context omitted.

People aren't using it because it is no longer receiving updates. 2-3 year old hardware should not be considered "old", or obsolete.

Android hardware ages really poorly. I have an iPad and a few android tablets from around 2014 and the iPad is on the latest version of iOS 14 and feels almost new while the android tablets are basically unusable and on 2015 versions of android.

If the software doesn't get updated, it doesn't mean the hardware is not aging well.

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

#145

Post by scaladev »

rubatuga wrote: post #138
boring_twenties wrote: post #136

Earlier quoted context omitted.

Hmm, don't think so. Vendors cannot create CPU microcode, Intel has to do that. And the relevant Intel document[1] clearly stated that they weren't going to do that. The HP400 specs I found only list Bloomfield processors[2], not Westmere. Perhaps that is the source of your confusion? 1- https://www.intel.com/content/dam/www/public/us/en/documents... 2- https://support.hp.com/us-en/document/c01709672

X5690 (Westmere) works well in Z400. Here’s another article specifying the BIOS update: https://www.techpowerup.com/forums/threads/new-microcode-for...

Jesus, what a pain. Why the hell do you need to wait for your proprietary OS vendor or BIOS vendor to update anything? On Linux the kernel does that for you, just configure your bootloader to point the kernel to a microcode image and that's it. Why can't windows do the same?

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

#146

Post by bitmapbrother »

kogir wrote: post #5

Qualcomm is only able to obstruct in this way because Linux doesn’t keep the kernel driver ABI stable for any fixed period of time. If Android used FreeBSD and Qualcomm shipped drivers for the latest build when the SoC was released, you’d have up to five years of support from that kernel release. Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the pl…

>Qualcomm is only able to obstruct in this way because Linux doesn’t keep the kernel driver ABI stable for any fixed period of time.

The Linux kernel used by Android is based on the LTS version that now has 6 years of support [1]. So by the time an OEM releases a new device the support window will be about 4 years. Google has also been working to stabilize the Android kernel HAL so that OS updates don't require a brand new kernel [2]. Because of these developments Android devices can now offer 4 years of support [3].

>Windows Phone 10 was actually in a position to support phones for years and even got Qualcomm onboard. It’s a shame the platform was never competitive, and they’d burned all their goodwill on the 7 and 8 fiascos.

This is pure speculation and I highly doubt Qualcomm would have invested the time and money, to support a platform that had no chance of success, beyond their obligated 2 years of support at the time.

[1] https://arstechnica.com/gadgets/2017/09/android-users-rejoic...

[2] https://arstechnica.com/gadgets/2019/11/google-outlines-plan...

[3] https://android-developers.googleblog.com/2020/12/treble-plu...

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

#147

Post by klodolph »

codewiz wrote: post #133
dathinab wrote: post #15

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…

> 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 of a good time.

I get that they have no responsibility vis a vis the GPL to upstream their changes, and I have no doubt that this is a cheaper way for them to run their business.

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

#148

Post by blendergeek »

jamiek88 wrote: post #85
swiley wrote: post #58

Earlier quoted context omitted.

Everything on the application processor is open source (think your laptop running debian.) The only thing that could break are the radios (wifi,bt,modem) becoming incompatible with the networks they communicate with but they're separate components anyway and the modem speaks a standard protocol so I'm sure it could be replaced.

>Everything on the application processor is open source (think your laptop running debian.) Even GPU?

> Even GPU?

The Librem 5 uses a Vivante GPU that is supported by the open source Etnaviv driver.

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

#149

Post by alisonkisk »

fakename11 wrote: post #134
garaetjjte wrote: post #100

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.

How is it clear?

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

#150

Post by DaiPlusPlus »

DaiPlusPlus wrote: post #125
dathinab wrote: post #124

Earlier quoted context omitted.

Because Windows is a (very broken) Micro-Kernel system which did very little changes to it's kernel (as far as I know) in the last many years, in difference to that Linux is a macro kernel with constant changes and improvements to it. Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not). What I do know is that there are clear benefits of micro kernel arch…

Windows NT is not a microkernel - Windows CE was, however. NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the ke…

> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality

I typo'd that - it should be

> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality

Post reply on HN