If this were genuinely 100% a Qualcomm limitation, I'd expect every Snapdragon 7s Gen 4 phone to be similarly stuck. But Motorola's Edge 70 Fusion uses the same SoC and was already in Android 17 beta testing in February, and Nothing's Phone (4a) and OnePlus Nord CE 6 are also slated for Android 17. So it seems the SoC isn't inherently preventing Android 17.

▲

dathinab 7 hours ago | parent | next [-]

it's not that simple

to promise 5 year of security updates your SoC needs to also have that support for that time frame + part of your developmeant/production time (as you can't the last steps of development/production before that chip is released). Lastly you need to add the duration during which you promise the 5 years security updates.

to put it simple for a 5 year guarantee you need ~8 better 10 year support for the SoC, measured from is release date

a lot of phone SoC (which tend to get Android porting priority by their producer) have shorter support. Hence why the fp5 had a SoC from a product line designed for industrial embedded appliances instead of a phone SoC...

but the main reason is likely simpler:

They are relatively small and likely will updated FP5, 6,6+ to Android 16 roughly at the same time to not have to support multiple major Android versions for the same time.

Still as long as Android 15 still gets security this doesn't matter too much. Recent major Android version IMHO often have been more disruptive then helpful. At least for me, but my guess it's this applies widely for the kind of audience which pay more because they plan to actual have the same smartphone in use for more the 3 years ;)

▲

microtonal 5 hours ago | parent | next [-]

Still as long as Android 15 still gets security this doesn't matter too much.

It does matter, because Android Security Bulletins only contain fixes for high/critical vulnerabilities. But all the other vulnerabilities can be useful in exploit chains. Add to that that ASBs have a three month embargo, but GrapheneOS and Samsung roll all/some patches out before they are in a security bulletin. So phones like the Fairphone have critical/high CVEs have been known for up to three months for anyone that looks.

but the main reason is likely simpler:

I think the main reason is that they do not do most hardware and software development by themselves, it's done by their Chinese ODM T2Mobile, for which Fairphone is probably just another customer.

Everything is at glacial speed. For instance, Android 16 on FP6 has some IPv6 bugs that breaks WiFi connections after a few minutes for a substantial number of their customers [1]. Six months later, they still haven't been able to properly fix it.

[1] The issues itself is probably not restricted to WiFi, it's that some brands of WiFi routers trigger one or more of the condition. One of which is sending a router advertisement with a lifetime of 0 for the IPv6 prefix used by the network. The connection handling code goes in a state where it misses the next prefix advertisement.

▲

artisinal 7 hours ago | parent | prev | next [-]

That sounds horrible. I can understand why Apple makes their own chips with the practices that these SoC manufacturers are getting away with.

Perhaps the EU can step in and force these SoC companies to change their way of working so that a user can simply install Android 17 with a few clicks regardless of their hardware (to a point). Like how desktop computers work.

	▲	ValdikSS 6 hours ago \| parent [-]
		Desktop computers work because Intel and AMD provide support to their chips to Windows and Linux, because these chips are used for desktop and servers, and these OS are what their customers use. Mobile chips are not used for desktop and servers, not used for Windows and Linux. They are used for Android, and that's a 98% of the market. The customers of the chips (the companies which develop devices on the chips) just don't use Windows or Linux, that's why there's no reason for a chip company to support it. Android does not use desktop/server firmware, desktop/server bootloader, and even desktop/server stock Linux kernel. They have their own Generic Kernel Image with the Android patches on top, strict Google requirements for the booting and working process, etc. PC operating systems are supplied by third parties that are not part of the computer manufacturer, motherboard or processor vendor. All component manufacturers must write drivers for Windows, certify them with Microsoft, and make sure that their device works properly ideally on any computer. You, the user, buy (or obtain) a copy of the operating system from the operating system company. The operating system for a appliance (smartphone) comes with the appliance itself (as a bundle), and is supplied by the appliance manufacturer, not by operating system manufacturer. The manufacturer of electronic components does not need to contact the creators of the operating systems, they write a driver for Android kernel (yes, for Android kernel, with all its wakelock subsystems and such in mind) and gives it to the manufacturer of the appliance directly (and sometimes only supplies hardware, and the driver must be made by the manufacturer of the appliance).

▲

5 hours ago | parent | prev [-]

[deleted]

▲

iririririr 7 hours ago | parent | prev [-]

SoC vendor (and correcting myself, every componet vendor, such as camera, touch screen, flash controler, etc) must make the drivers available TO YOU to ship to your customers. picking out binary blobs and reusing is what grapheneos does, and ia highly frowned uppon and will get you blacklisted