Live data from Hacker News

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

arstechnica.com

211–220 of 226 posts

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

#211

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…

Yeah, I think this is a major design point behind Fuschia/Zircon; they have a stable driver ABI to address this specific problem

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

#212

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…

That may keep the phone working but that doesn't provide security updates. Only Qualcomm can provide security updates for the binary blobs, so if Qualcomm won't sell security updates past 3 years than no OEM can guarantee a secure phone for more than 3 years. Sure, they can update other components but I would be very upset if 3.5 years into my 5 year supported phone a CPU vulnerability was discovered that let apps ge…

This was one of the big reasons my newest phone is an iPhone, not an Android phone. I am tired of buying new hardware every 2-3 years just to have a secure device.

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

#213

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…

I worked on the Linux Kernel team at Qualcomm for about five years, left in 2016. Our director was very much in favor of upstreaming but the product release schedules were so aggressive everyone was scrambling just to hit customer deadlines. It was incredibly difficult to get upper management on board with spending an additional 20% time getting drivers upstreamed, despite our team making the case for it ad nauseam.

Hopefully they recognize the value of "upstream first" more now. I think it is getting better...

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

#214
post #93

Earlier quoted context omitted.

This assumes that the person making the SoC owns all the rights to the code for their drivers, instead of licensing them from other firms.

You can demand those terms when you negotiate the license.

And they can say "no" or "money please."

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

#215
post #82

Earlier quoted context omitted.

Google has been promising to 'solve' fragmentation and long-term support for almost a decade, and it doesn't seem like there is any real solution. If you interested in long-term updates, the answer is simple: buy an iPhone.

> If you interested in long-term updates, the answer is simple: buy an iPhone. I would, if apple wouldn't dictate what i can and cannot install on my phone. Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?

Longterm official updates? Not that I've found. Your best bet is likely to buy a high-specced device that allows root + unlocking the bootloader and flashing a custom ROM. That's probably what I'm going to do (minus rooting), even though I'd greatly prefer manufacturer support.

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

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

My 4 year old S8 is doing just fine. I'd be happy to replace the battery and use it for another 2+ years, but I only get one more quarterly security update.

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

#218
post #143

Earlier quoted context omitted.

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.

Except for the battery, my GS7 is fine otherwise..

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

#219
post #161
post #72

Earlier quoted context omitted.

It's a decent device, but feels several generations behind any mid-range phone released in 2019. The screen has color blurring when scrolling especially visible with text, the fingerprint reader often doesn't get a good read, and it's noticeably sluggish in everyday tasks. I justified the higher price to support their vision, not because it's a great daily driver, but it serves well as a backup phone with /e/OS. The…

> it's noticeably sluggish in everyday tasks. I'm not a fan of statements like this. They really should be qualified further, because the Fairphone project deserves thoughtful critique. What exactly is sluggish? Scrolling in the mail app? Tapping links when browsing over cellular? Opening the app drawer?

Scrolling in the RedReader and Materialistic apps, loading images in the built-in viewer, opening links in the built-in or external browser, and many more regular tasks have noticeable hitches and are not as responsive as on other devices of the same era.

Granted, I'm comparing this to a OnePlus 5T with a more powerful chipset, but I also think the screen itself is not as responsive to touch input which adds to the slowness perception. It reminds me of the way Android devices responded before Google's Project Butter, so seeing it in a modern $500 mid-range device from 2019 is underwhelming.

None of these are dealbreakers and the phone is perfectly usable, but together with the other (bigger IMO) issues it adds up to a lackluster experience.

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

#220
post #77
post #44

Earlier quoted context omitted.

What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to the next? What prevents people from using the same drivers for a device on Android 7 and upgrading the OS to 9 or 10? I always understood that drivers would continue to allow the OS to recognize the component that the drivers are for unless something drasticall…

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…

Is it truly necessary that all these drivers run in the kernel space?

I bet a lot of drivers are just interfacing with a standard serial line which could be done in the stable user space and then exposing the next layer through something like FUSE.

If I understand treble correctly that’s close to what Android is doing, where each HAL can be done in userspace?

Post reply on HN