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

91–100 of 226 posts

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

#91

Post by cwyers »

dathinab wrote: post #87
DaiPlusPlus wrote: post #73

Earlier quoted context omitted.

> The intent is to compel device manufacturers to release the source of their drivers I doubt that was the "intent"... perhaps a contributory argument in favour of a non-stable ABI, but I understand the reasons are far more pragmatic: maintaining a stable kernel ABI is a lot of work which could have strangled Linux in its early years.

> have strangled Linux in its early years. And likely would still do so toady. I mean we are speaking about the kernel internal API (not the syscall API, which is stable). Even systems which pride themself for internal kernel API stability do change the API every view years, while often having much less internal (feature/platform support) changes then Linux . Furthermore in android Linux LTS versions are often used w…

Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.

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

#92

Post by phh »

gruez wrote: post #43
mmastrac wrote: post #24

It will be interesting to see what Project Treble brings to the table w.r.t. long term support for Android devices. It should help with the bitrot problem, though it pushes a bunch of stuff into blobs instead of creating long-term maintainable kernel source code.

Hasn't treble been around for years now?

I, as an OSS community contributor, have been using Treble for years now, and I have devices who got let down by their OEMs on Android 8, that I pushed up to Android 11, and that's been pretty cool.

I, as an OEM, am still NOT allowed (by Google) to use Treble to provide upgrades. This "legality" issue is being fixed ( https://android-developers.googleblog.com/2020/12/treble-plu... ), but its effect won't reach users for at least 2 years.

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

#93

Post by cwyers »

dathinab wrote: post #84
baybal2 wrote: post #79

Earlier quoted context omitted.

> is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high. And Qualcomm is probably very, very happy with this arrangement. They can put a gazillion devs to maintain their BSPs using any means possible, but a small 2nd tier SoC fabbless don't.

Or you just push it upstream, which solves your problem because whoever is refactoring kernel code is also likely doing the appropriate changes in your code if necessarily.

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.

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

#94

Post by muststopmyths »

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…

I heard one of the reasons Microsoft had to ruthless kill support for phones when switching from WP7 to 8 to 10 was Qualcomm not willing to ship chipset drivers for the older devices with the new kernels in each of those iterations.

It would have gotten Microsoft a lot of goodwill if they had, but strangely enough Microsoft at that time did not seem to be interested in the goodwill of Windows Phone users anyway :-)

I'm still hanging on to a 950XL for some weird reason.

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

#95

Post by phh »

traverseda wrote: post #18

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.

In the Android smartphone world, most big OEMs abid by the GPL properly, with nothing closed source in kernel.

But if you have bugs either in other processors' firmware, or in userspace binary libraries, kernel's GPL won't save you.

One could say that userspace binary blobs are meant to circumvent the GPL, but I don't have that feeling: GLES libs are userland just like Mesa, modem is userland just like ofono It looks like userspace/kernelspace separation is pretty much the same between oss world and android smartphones' proprietary world

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

#96

Post by userbinator »

sitkack wrote: post #29

Time is now for an unencumbered SoC with fully available documentation, 1k+ pages downloadable as a complete set of PDFs along with a reference design.

If you count what's been leaked, Mediatek ones would qualify.

1k pages is underestimating by quite a bit. 3-4k pages is closer to the norm, and that's just most of the programming/registers documentation. The complexity in these SoCs is astonishing.

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

#97

Post by Qwertious »

fsflover wrote: post #49

If you want lifetime updates for your phone, consider Librem 5 [0] or Pinephone [1] instead. They do no rely on Android but use GNU/Linux as OS. [0] https://en.wikipedia.org/wiki/Librem_5 [1] https://en.wikipedia.org/wiki/PinePhone

If you want a "just works" phone, don't buy a Pinephone. The PinePhone is great for it's intended purpose but it is not a good consumer-phone.

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

#98

Post by toast0 »

muststopmyths wrote: post #94
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…

I heard one of the reasons Microsoft had to ruthless kill support for phones when switching from WP7 to 8 to 10 was Qualcomm not willing to ship chipset drivers for the older devices with the new kernels in each of those iterations. It would have gotten Microsoft a lot of goodwill if they had, but strangely enough Microsoft at that time did not seem to be interested in the goodwill of Windows Phone users anyway :-) I…

From WP7 to WP8 was WinCE kernel and single core to WinNT kernel and multicore. Maybe the WP7 devices could do it, but not with good performance. That one just wasn't going to happen.

Most of the WP8 devices were able to run WM 10, but the experience was really poor on the low memory devices, so those didn't get a release outside of the public insider builds. There was one or two devices that didn't get upgrades for some reason, other than those and the low memory devices upgrading to 10 was available, but it took a long time for them to get around to fixing things; it actually got a lot better in the release after they officially gave up. Possibly if there was a focus on mobile during development of 10, they could have made the first release good, and maybe even got it to work OK on low memory devices; Edge was still going to be trash though.

All of that said, a bigger problem was dumping goodwill of developers. WP7, WP8, and WM10 all had new frameworks for apps that were needed for new functionality and didn't work with prior Microsoft OSes; calling the WM10 one 'Universal' was darkly humorous.

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

#99

Post by loa_in_ »

lawl wrote: post #82
ArkanExplorer wrote: post #33

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?

> Is there a smartphone that's usable as a daily driver, lets me have root and provides long term updates?

A touchscreen notebook with a GSM/LTE modem and a decent microphone running Linux is the closest you can get today as far as I know

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

#100

Post by garaetjjte »

bri3d wrote: post #77
techrat wrote: 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…

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

Post reply on HN