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

It&#x27;s not just Qualcomm it&#x27;s closed source driver blobs in general.<p>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).<p>Besides that potential but as far as I know less likely offenders include the modem.<p>Ironically both might be integrated into the SoC which then massively increases the chance for problems.

It&#x27;s mind-boggling to me that Qualcomm only guarantees 2-3 years of support for their chipset. Compare that to the PC processor space, how much does AMD&#x2F;Intel provide? 10 years? More?<p>Somehow people seem to be running on 15 year-old Thinkpads without a problem, yet a $1000 phone apparently can&#x27;t scrape by for more than three years due to vendor support?

Congratulations to Fairphone. This sounds like a massive task especially for such a small team. I run a Fairphone 3 and I couldn&#x27;t be happier. Sure it was on the pricy side but it&#x27;s served me well, takes great photos, has survived numerous drops (the phone protector shipped with it is great), looks cool,strikes up interesting conversations now and then, and will apparently have Android updates well into the future. Fairphone&#x27;s a great company shipping a great product. Well worth the investment!

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

Compare mobile phones to PC today, you will find that a PC made like five or more years ago can run the latest software without issues while for mobile devices, they can hardly survive for more than three years (I guess?) since the ability to support a new Android version completely depends on the SoC manufacturer. You may also upgrade part of the hardware of PC or install whatever OS you like on them if you want to. However, look at those &quot;smart&quot; phones, which are not smart at all: you are limited to a few Android versions and you are forced to install all these proprietary userspace drivers (HALs for example). Moreover, if you want to have full access to your device (Root), you have to bag the vendor for that privilege (Xiaomi, Huawei, etc. OnePlus is way better), which should be the right for everyone.<p>This is because the PC market is standardized (I guess, correct me if I&#x27;m wrong), compared to the phone market which has all of these proprietary blobs, private interfaces and lockdown. I hope we could have open source drivers, standardized hardware and software interfaces (like UEFI) for mobile smart devices just as PC does. Thus we can install whatever operating system or software without limitations. Also there will be less e-waste just as PC.

some Qualcomm SoCs (410c and 845c) are seeing mainline support. I booted a 5.11 kernel on an 2015 device yesterday and had surprisingly good working handheld with the pmOS&#x2F;Phosh stack. Of course this is still a raw experience for enthusiasts, but one can use an AOSP distribution instead.<p>The Fairphone concept of easily replacing common problems with screens and battery complements the longterm chipset support, one needs both. It wouldn&#x27;t help the repair&#x2F;replace decision if the screen needs 2 hours and heatguns to replace. Making it difficult to unlock the bootloader is another barrier manufacturers and mobile operators are guilty of.<p>Mainline phones can be used until their counterpart antennas fall from the operators towers - and for 4G I think this is well into 2030.

Chipset support from the manufacturer is not, strictly speaking, essential. What we need is support in the mainline Linux kernel. Many of the custom hardware blocks that a kernel has to support via its drivers are shared across chipsets generations anyway, so they end up being supported a lot longer than any single HW platform.

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.

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.<p>Qualcomm is abusing its monopoly position and the laws&#x2F;patents that allow this need to be changed. Qualcomm is a great example of how IP laws can hurt progress and competition.<p>In the future China and other countries will leapfrog the US in areas where competition is banned, because the only possible competitors will be in other countries.

Like I’ve said before, there need to be laws that require companies like Qualcomm to open source their stuff once they stop supporting them in any meaningful way.

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&#x2F;Linux as OS.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Librem_5" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Librem_5</a><p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;PinePhone" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;PinePhone</a>

What about Google? The issues fairphone mention are passing Google certification suites. They should be relaxed to help those cases. As far as I know the major issues are around GLES. It passed older CTS, so GLES was good enough back then. Surely it could be good enough now.

&gt; 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.<p>Why is it so easy to boot any linux distro on almost any desktop computer? What makes it more difficult for phones?

worth noting that there has been really good progress reverse-engineering support for 2017&#x27;s Snapdragon 845[1] (SD845). quad A76 + quad A55 on Samsung 10nm. pretty modern, all in all.<p>generally i still feel tortured by the situation, by highest of high tech devices being unsupportable, unmaintainable after a couple years, and it seems like upstream support is the only available path to keep devices from turning to e-waste. however, there are some positive signs. most chips still have seen nearly no support from the chip makers, but we have seen, for example, Qualcomm land some additional support for some additional the SD845 gpu, for which reverse engineered support had already been nicely developing.<p>we&#x27;re also seeing more phones with Samsung, MediaTek, &amp; some other chips. it&#x27;s notable that none of the other chip makers have much of a presence in kernel upstreaming either. it&#x27;s not just Qualcomm: everyone is very bad at making mobile devices able to be supported.<p>i&#x27;m very interested to see what starts happening with cars, which face a similar supportability problem, but which are less disposable. long term kernel support has been extended greatly to enable a longer life. Google&#x27;s Project Treble has created a device-driver abstraction layer to try to ease things along some. but it&#x27;s very hard to imagine the sea-change necessary for commercial teams to take their work, &amp; rebuild it, safely, successfully, easily, atop the complex drops of vendor code &amp;c. chip makers have had an enormously difficult job supporting the teams making software, providing them updates that they can readily begin to use, and it&#x27;s been a very conservative, slow, deliberate process. most technical folk seem anxious to shift the mode, to get more upstream support, such that kernel &amp; system upgrades don&#x27;t require carefully tailored support packages from the chip maker to make updates possible. the current pace feels very logjammed, there&#x27;s so much custom code people shipping products rely on, and trying to make folks less critically dependent is such a powerful compelling vision for so many techies to improve supportability, to make updates shippable both faster &amp; doable in the long term.<p>[1] <a href="https:&#x2F;&#x2F;en.wikichip.org&#x2F;wiki&#x2F;qualcomm&#x2F;snapdragon_800&#x2F;845" rel="nofollow">https:&#x2F;&#x2F;en.wikichip.org&#x2F;wiki&#x2F;qualcomm&#x2F;snapdragon_800&#x2F;845</a><p>[2] <a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=news_item&amp;px=Qualcomm-SDM845-Display" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=news_item&amp;px=Qualcomm...</a>

Three years of support is very poor and encourages e-waste, I will not be buying a phone with Qualcomm hardware in it.

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

This has been my main gripe with my Google phones. If a phone lasts half as long, it should cost half as much. Otherwise it&#x27;s not very good value.

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.

Having been through a project where we built a mobile OS both the carrier demands and baseband blobs are huge barriers to market.

some qcom competitors pay ip designers for new android version drivers for designs from more than a decade ago

Surely any vendor that doesn&#x27;t upstream their code changes has similar effects on long-term support?

Theirs bootloader is biggest barrier in running mainline Linux.

Interesting.<p>It seems that open source can never really win.

Completely. No doubt.

I don&#x27;t blame Qualcomm one bit. Why would they want to support old hardware long after 99% of people aren&#x27;t using it?