Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The recently released Fairphone 6+ runs on Android 16. I had to look that up on Wikipedia, their website doesn't even clearly state that. Android 16 is 14 months old at the moment. Android 17 was released to manufacturers 6 months ago and had a general release 2 months ago.

So why does a brand new phone run an operating system from over a year ago? Does it really take over 6 months to update a phone to a new version of Android?

How am I supposed to believe a company is committing to supporting a phone for a long time when at release it already runs outdated software?



I am a user. What does Android 17 do for me that 16 doesn't?


Security is the big reason to want 17 over 16, though I believe 16 is getting a lot of those features backported still.

Otherwise, I preferred 16. The UX, AI, and all the other garbage I really could do without. I don't love it. My phone (pixel 9) feels slower and the battery is now draining like crazy.


Android 17 is required for full Android security updates. Only a subset of patches are backported to older versions and that's decreasing. Android 17 is also required for the latest and greatest privacy/security protections which are not backported. There have been massive privacy and security improvements in each yearly Android release.


Since about 12 or so, it's been a series of cosmetic changes, bugfixes, and "AI" features.


Android 17 is required for full Android security updates. Only a subset of patches are backported to older versions and that's decreasing. Android 17 is also required for the latest and greatest privacy/security protections which are not backported. There have been massive privacy and security improvements in each yearly Android release. There have also been far more improvements than those. Being unaware of it doesn't mean it hasn't been done.


This is largely untrue.

You would be missing out on:

- Minimum Target SDK Enforcement Blocks installation of apps that target ancient versions of Android and legacy APIs.

- Restricted settings for sideloaded apps

- Null-Cipher rejection and 2G disabling

- Cell Network Surveillence Alerts

- Platform Rust Migration

- Scoped Media

Among many many unpatched Med and Low severity CVEs that don't get backported.


> Minimum Target SDK Enforcement Blocks installation of apps that target ancient versions of Android and legacy APIs.

Funny to list a user-hostile change as the first “improvement” that comes to mind.

I guess GP should have said “series of cosmetic changes, and breaks in your UI habbits and a few of your apps deemed too old”.


Minimum Target SDK is the opposite of user hostile. Privacy and security changes are added to the SDK consistently. Apps that fail to comply with that SDK are much more of a privacy risk.

Feel free to look at the AOSP SDK changes for each major version that's released and you will see many of these examples.

Apps that failed to keep up with these changes, regardless of licensing, should be avoided and ultimately removed from availability.

The deprecation of 32-bit apps is another example of this.


Getting security updates for issues that are not marked high/critical. These are not your typical RCE, but they are used in exploit chains.

For those not aware, Android Security Bulletins only cover high/critical vulnerabilities. There are also rumors that Google will soon stop fixing vulnerabilities in not-actual versions that were discovered by Google in LLM-driven vulnerability discovery. There was recently a GrapheneOS thread about it.


> There are also rumors that Google will soon stop fixing vulnerabilities in not-actual versions that were discovered by Google in LLM-driven vulnerability discovery.

These are not rumors. It's an official announcement from Google to OEMs and we have access to it.


> Getting security updates for issues that are not marked high/critical. These are not your typical RCE, but they are used in exploit chains.

Aren't those back-ported for a while?


Android Security Bulletins are a list of the High and Critical severity patches backported to older Android versions. At the time a bulletin is published, the patches have been available to OEMs to ship for 2-4 months. Fairphone is nearly always 1-2 months behind the latest bulletin but it can get much worse over time.

Android Security Bulletins do not cover the vast majority of Linux kernel security patches. They only cover an extremely small subset tied to Android. The Linux kernel has a massive tsunami of security patches on an ongoing basis. Fairphone 5 and earlier have an end-of-life Linux kernel without security support. They're close to not updating the kernel at all anymore. Their more recent devices will end up in the same situation.

The Linux kernel is not the only component ending up unmaintained while the devices are still presented as supported.


No, they are not.

https://grapheneos.social/@GrapheneOS/114101511604296440

You need new releases or QPRs to get other patches.


Android 17 is required for full Android security updates. Only a subset of patches are backported to older versions and that's decreasing. Android 17 is also required for the latest and greatest privacy/security protections which are not backported. There have been massive privacy and security improvements in each yearly Android release.


16 is fine if you don’t connect your phone to rhe internet, or use sms.


I belive you are mistaken. Android 17 final was "released" 6-7 weeks ago.

But Google being Google, this release is pretty much useless until Samsung et al deal with all bugs and performance issues, which will take 2-4 months.


As a Linux, macOS and Windows user it’s really strange to me that you can’t just install the latest OS on your device. Even my iPhone updates to the latest version as soon as it’s released.


I dont know. Does your Linux distribution immediately upgrade to the latest kernel when Linus releases a new one?

Besides, the phone software is highly optimised for the specific hardware. It is not a generic software like Windows


Even distros often provide a kernel mainline branch to let you install the latest and greatest kernel in a click.

But there's also nothing to stop you simply building the latest kernel from source and using that - it's pretty easy and it will work fine.


Why though?

Seriously, why can't Android just be installed? Are they building it like the old-timey kernel before modules and embedding drivers in a giant monolith or something ridiculous?



> Does your Linux distribution immediately upgrade to the latest kernel when Linus releases a new one?

Yes, it does (CachyOS).


Certification takes time and probably overlaped with the phone development. Fairephone is small compared to e.g. samsung and they describe themself more "stable" and long-term support than bleeding edge.


Fairphone 5 and earlier also have end-of-life Linux kernel branches without security support. Fairphone's more recent devices are headed to the same situation. In practice, the same thing happens with other components beyond the Linux kernel.

Fairphones have 1-2 months of delay for partial security backports to older releases from the beginning and much longer delays for full updates. Android 17 is required for full Android security updates. Only a subset of patches are backported to older versions and that subset is decreasing.

Android 17 is also required for the latest and greatest privacy/security protections which are not backported. There have been massive privacy and security improvements in each yearly Android release.


Even worse: Google actually does four releases releases per year (major and QPRs), of which QPR2 is also provided to OEMs. Only Samsung and GrapheneOS roll out QPR2 releases.


The Android version is clearly displayed in the article.


this is 100% in the hands of the SoC manufacturer.

Android versions are locked to kernel versions, which are locked to binary drivers to run your hardware. there's no way around that and you can't reverse engineer or do anything if you want that SoC vendor to continue to fulfill your orders (which you're already at the bottom of the fulfilment list because of low volumes)


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.


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 ;)


Qualcomm provides 8 years of support from platform launch. OEMs/ODMs need to choose to pay for it. Fairphone doesn't ship proper updates from the beginning due to lagging months behind on incomplete backports and years behind on complete updates.

It's entirely possible to port to a new kernel LTS branch regardless of what the SoC vendor provides, but they don't either way. Fairphone 5 and earlier have an end-of-life Linux kernel branch without security support. The Linux kernel is an immensely important part of security on a device against both local, proximity and fully remote attacks. Not having security support for the kernel means the device lacks real ongoing security support.

Android 15 does not receive most privacy/security patches but rather backports of many High and Critical severity patches. Only the latest OS releases receive Low and Moderate severity patches. A growing number of High and Critical severity patches are no longer backported due to how many vulnerabilities are now being discovered.


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.


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.


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


It's inaccurate information. Qualcomm is willing to provide 8 years of support from SoC platform launch. Android also fully supports using a newer userspace on top of an outdated device support platform. Treble provided a very good implementation of it.

Fairphone chose to use T2Mobile as their ODM designing and making their devices. They chose to use the SoC platforms they did. They chose to focus very little on providing updates to the point that the Fairphone 5 and earlier have an end-of-life Linux kernel without security support. Fairphone 5 is still presented as supported with many years to come but it's not getting a large portion of the high importance security patches anymore.


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


Qualcomm provides 8 years of support from platform launch.

Android versions are not locked to kernel versions. In general, new Android versions do not require new kernel versions.

In practice, all kernel drivers are open source including for Snapdragon, Exynos and MediaTek. The kernel drivers can be ported to new major kernel versions regardless of whether the firmware and drivers are still supported. The benefit of updating the kernel and kernel drivers without firmware and userspace driver updates is very low. Rewriting the userspace driver code as open source code on top of the kernel drivers is also entirely possible. It's a lot of work and there's a lack of a security motivation to do it due to needing up-to-date firmware with patches for serious remote vulnerabilities and other issues.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: