Software Update: 8901.4.A.0016.6

It’s not related to this update, it’s an already known issue.


1 Like

Known, yes. But being worked on? I doubt it, because when I reported it to support they wanted me to reset to factory settings which I refuse to do if it’s just a stab in the dark.

I disabled Digital Wellbeing recently to see if that helps and have successfully rebooted twice so far.

Thanks for your link to the other report of the same issue. I have done a cold restart of the phone, also have stopped and restarted the LibreLink and the NFC apps, to no avail. I also had an old unused sensor that I stuck on my other arm and attempted to twin with the app, but again the same scan error. As @ralfberlin says in the other thread, an NFC service component is likely at fault since the update. I have logged it with FF support, who are now asking me to prove that I own the phone…
Whatever, it seems that I shall have to do the reset/downgrade later today, because I have very few finger-prick tests with me.


A “reset” does that mean a reset to factory settings? So going up no data is lost (over the air), but going down a version means losing everything which is not back up at Google??

1 Like

Yes with reset I meant a factory reset. When you manually flash something (up or down) and your bootloader isnt unlocked already all data will be wiped. When your bootloader is unlocked, normally an upgrade will not cause data loss, however a downgrade would normally cause a data loss. Having good back-up is always a good idea :wink:

1 Like

Updated to 8901.4.0016.6 yesterday and after a reboot the assignment of SIM1/SIM2 to functions (SMS, Phone, Internet) is again lost.

This issue existed before (cf. 🇬🇧 🇩🇪 Report: 1 month Android 11 / Erfahrungsbericht: 1 Monat Android 11 - #17 by yvmuell and also a bugreport 528986), was fixed in build 8901.4.A.0013.4 and now raises its ugly head again.

Annoying!! (and that’s saying it mildly)

You use dual SIM? If yes enable SIM code for both SIM.

Same here, neither BT-Headphone-controlls are working nor the controls from the car. That is completely broken.

However, for some of us changing the AVRCP-Version back to 1.4 (within Developers Options) might help (source: Fehlende Titelanzeige bei Bluetooth Verbindung im Auto – Doesn’t work for me. Just a hint here: The issues of Android 11 with BT-Connections is know since 2020. Proof: ibid.

Sloppy work, worse quality control.

Wouldn’t it be better to fix what’s been broken than to downgrade into an older version?

There’s no such choice :frowning:

This is a user forum and as such none of us have that option. For each disgruntled user the options if they cannot find a workaround are a) to wait or b) the option to try a reset or downgrade.

1 Like

There might be a third option: Fairphone, because of being a small firm, tends to be significantly more dependent on the loyalty of the single customer. Maybe Fairphone should ask itself which customers they want to attract, when the bottom line is: Support su***, quality control is not working etc. An update like that might work for Samsung or Apple, with the latter mostly because due to ideology and propaganda, with first due to market power, but small firms have been broken because of smaller issues with their policies.

1 Like

The target must be those that care more about thoase that do the work than the product, which is unusual and difficult to access.

Given the increased sales I imagine things are working quite well and given the global problems it is surprising they can survive ~ they have clearly hit on a big enough audience.

So I don’t know who you are refrring to or what caused such a downfall but the problems occuring with updates are trivial on who is being used and abused to provide fancy phones.

But given the popularity of ‘smart’ phones they are unlikely to downgrade to make support easier as it probably would ‘break’ the ‘firm’

This topic is about the Update and workarounds or acknowledgment of it’s success or otherwise.

This discussion is well off topic so will end it at my end.

All the best

Yes, this works around the issue, but is not a fix.

Bugs in version n-1 that were fixed in version n, but re-occur in version n+1 are a symtom of poor engineering and even poorer quality control. Each new version becomes a Pandora's box ("What is going to be broken (again) when I install this patch?"), which is definitely not the way it should be.

I also strongly detest the (very common) ‘but we have a workaround’ attitude, because it puts the workload to get the system to function properly on the customer (and forum members) instead of the developer where it should be.


A thought … how feasible, I don’t know, but a thought nonetheless :slight_smile:

The Fairphone 3 is an A/B device. It holds two OS installations at a time, after an update the old version is still there. User data is shared (not doubled).

The cool thing is … users should be able to switch the OS slots and thus boot the old version (by disrupting the boot process into the new version a few times intentionally, if more convenient methods are unavailable with a locked bootloader?).

The “uncool” thing is … rollback protection. With obvious good intentions, this mechanism breaks the possibility to simply fall back to the old OS version in case of obvious trouble after updating, because if the old version is on an older security patch level (which it usually is), a factory reset will be needed to boot the old version, user data as well as user-installed Apps and their data will be deleted.

This kind of bugs me, conceptionally.
The result of this protection is that a quick and practical fix for users in case of serious issues after an update is disabled for a gain many affected users would legitimately consider much less important, if given a choice.

What if OS updates could be split into updates which do substantial changes while keeping the same security patch level date as before … and later updates which only raise the security patch level date?

This way, after a feature update the possibility to fall back to the old OS version in case of obvious trouble would be left intact, because rollback protection wouldn’t kick in?
And a later update ideally just raising the patch level date wouldn’t break stuff and could be started by users once they are sure they don’t need to fall back?

I don’t know whether the deed of only raising the date is left to the discretion of the OS vendor, or if raising the date would have to be bundled with actual security patches. In the latter case, leaving 1 patch undone until the date-raising update should do the trick.

Wouldn’t this be possible?


New problem seemingly related to this update

@formerFP.Com.Manager WPA3(SAE) networks are not shown anymore and no (auto)connection possible since update.

@Cookie WPA3 was already not supported on Android 10 and the previous Android 11 releases (only some Android 11 beta versions had WPA3 support enabled, which was a mistake). FP3 is not certified for WPA3, therefore we cannot enable it.

WPA3 was already possible with Android 10 release versions on the FP3 and was disabled with update 8901.3.A.0077.20201221.
See: Is WPA3 officially supported? As it does no longer work

Facing the same issue with Bluetooth earphones with the FP3 after this update. Is there any fix for it?

The only things we can do are:

  • wait for an update
  • downgrade
  • switch to /e/OS or that other one
  • get a new phone without that update installed

No workarounds or fixes are known. We’re stuck with this issue for now. Devs apparently are aware of it but there’s no timeframe when we get an update solving it.