Recommendation: Pull FP Open OS 21.12.0-rel 1 from software delivery!

Help Fairphone 2
1

I have migrated my Fairphone 2’s Fairphone Open OS in several steps onto Android level 9.

From the beginning, FPOOS was unreliable on level 9 (on all prior levels it was rock solid!). Previously, I had occasional crashes in Quickstocks and Corona Warnapp Companion.

Now I moved to 21.12.0-rel 1, and the result is, in plain words, a nightmare.

I had much more crashes in the above mentioned apps than before, but also crashes in Corona Contact Tracing Germany, even in the Contacts, and finally in Launcher !

But this afternoon, I wanted to use Open Camera. I had no less that 36 crashes - all in two minutes! Really, more than 36. Because the closure of an app, regardless of whether it was voluntarily closed or crashed, plays a system sound, a short clicking noise. Those clicks came so frequently and close to each other, it was a crackling that lasted for more than 10 seconds.

At first I thought that this came from the Storage Access Framework, as I save the photos of Open Camera on SD card. The first crashes occured when taking a picture, thus saving it to the card. But after the first “burst” of crashes I sometimes saw that Open Camera crashed two seconds after startup, without taking any picture at all or touching any function… And then I saw even Launcher crashing…

I am a professional software tester (ISTQB certified). So I have seen many software in beta or gamma status. But release 21.12.0-rel 1 IMHO cannot even be called alpha.

So I would humbly recommend that you immediately pull this version from software delivery before anyone loses data over it…

Crashes while data is being written endangers both the data currently written and all data already in this file system. The SD card carries a non-journalling file system that can easily lose data if write access fails. Ext filesystems are more robust, but not unbreakable. This release of FP Open OS has to be considered dangerous.

Thanks.

The full qualification of this release is “fp2_sibon-userdebug 9 21.12.0-rel.1 sibon-dd018702”. Installed on a standard Fairphone 2 (with the newer camera) and 128 GBytes in a Sandisk Ultra Micro SD card, one SIM (O2 = E-Plus = Telefonica). When those crashes occured, GPS, Bluetooth and WLAN were active (for CCTG), but only a 4G network connection was active.

2

Any factory reset or installing from scratch inbetween?

Meanwhile Fairphone have rolled out Android 10.

Perhaps of interest …

The Companion App had some trouble of its own a while back with higher numbers of keys to match, but this should be resolved by now.

Formatted as Internal Storage or as external/portable Storage?

See sdcardguide.

Fairphone have a beta testing process in place.
If a number of beta testers had this kind and level of failures, I’m pretty sure it would have come up before release.

Checking the SD card can’t hurt, SD cards are bound to fail somewhen in general, and additionally Android 10 at the latest (across vendors and devices) would prove even more problematic for incorporating it into Internal Storage than the concept is already.

If you didn’t do a factory reset or even a clean install already on the way when migrating, this option should be considered, too.

3 Likes
3

No, I never had factory resets or scratch installs. Prior to level 9, all updates through the Updater went absolutely smooth with no disturbances whatsoever.

At the moment I hesitate to go for Android 10, which Updater presented to me the very moment I first started 9… I read that some users have the trouble I have with 9 on 10, and I definitely do not need more of that. I do not use my Fairphone for testing, I actually use the device.

I did not have much use of Open Camera, because during the pandemic I travelled less, and most of the time when I did I had my DSLR with me for photos. I now plan to take my Fairphone apart again (which do not do very often, because I am one of the victims of the beautiful, but brittle transparent back cover) in order to see whether the file system took any beating during those crashes.

I never changed the formatting of the SD card. When I take it out, I can read it’s contents, so I guess it is not encrypted. In Amaze I see two areas “Storage” and “39FB-0908” which would be the ID of a FAT file system, I guess.

4

F-Droid package source updating crashes during link establishment (four times in a row. On the fifth try it did download). So maybe it’s a problem with the IP stack? IP connection was WLAN (4G also active).

5

Crashes while data is being written endangers both the data currently written and all data already in this file system. The SD card carries a non-journalling file system that can easily lose data if write access fails.

That 's true, but only if the operating system crashes (or the system loses power) in the middle of a write. What you’re describing is an application crash, and if those could cause filesystem corruption it would be considered an enormous security hole and get fixed immediately. I’ve seen a lot of things cause filesystem corruption over the years, but never crashing apps: I can’t even envisage a mechanism by which this could happen, since the filesystem layer has no idea a crash has even happened and any crash isn’t going to “strike” until the system is no longer in kernel mode and the filesystem is in a consistent state again (signals, even fatal signals, are not processed until exit from kernelspace, either by return from syscall or via a schedule()). Obviously, if an app crashes while a file is being written the file is likely corrupted or at the very least truncated to some degree. But other files the crashing app hasn’t touched or even opened writably? Filesystem metadata? That’ll all be fine.

Obviously an app crashing dozens of times a minute is a sign of something fairly seriously wrong somewhere: perhaps just with that app, but it could be that the device as a whole has some sort of problem that might impair the kernel or Android framework too and cause whole-system crashes. Since you haven’t mentioned any whole-system crashes, probably this is not true in this particular case.

6

FAT file systems are known to cause some sort of trouble. Depending on the implementation, which I do not know. Linux has several ways to access FAT (kernel, fuse, mtools etc.) and there are two layers for file names - FAT cannot “speak” longer filenames, it needs VFAT for that, and control traverses many times from application to kernel, to layers etc. a multitude of errors can occur.

But coming back to this problem:

Open Camera did not have any problems on previous versions of FP Open OS. Also, the device has no hardware problems, and the SD card is working correctly. A scan on a Windows machine showed no problems.

It seems that Open OS does have problems with SD cards now. For instance, after taking a picture in Open Camera, a thumbnail of that picture is shown in the lower right part. Tapping on that should open that picture, but this takes A MINUTE (no kidding, really a minute), and sometimes it doesn’t open at all. This means you cannot e-mail that picture from the viewer.

Instead, you can open the picture in Amaze, and e-mail it with K-9. Interestingly, on the new Open OS ALL such e-mails fail (connection refuse). Upon killing K-9 and restarting it, instructing it to send all unsent e-mail, the e-mail is sent correctly. I could reproduce this behaviour seven times by now…

Another app that is behaving abnormal is Quickstocks. Quickstock exits every now and then. I believe it could be related to advertisements that are displayed, as they sometimes contain animations of short video. But so far I could not nail it down to that definitively.

Corona Warnapp Companion very often shows this behaviour, which I have also seen on Quickstocks: Suddenly the app exits the foreground, presenting itself minimized. When tapped, the app re-initializes.

I have, in the meantime, witnessed this nasty behaviour with Corona Contact Tracing Germany, too.

7

You could try in Open Camera to toggle Settings - More camera controls… - Use Storage Access Framework and see whether that makes a difference.

But with the combination of issues you have … something seems wrong in general. In-place upgrades to new major OS versions are always tricky, regardless of the OS or the device. They may work flawlessly, unless they don’t.

If it was my phone I would cut my losses of precious time and do a clean install from scratch. That would at least show whether the upgrade process was at fault (if at least most of the problems are gone) or not (if the problems persist unchanged).

Try to reduce the number of days the App downloads exposure data for to then analyse it. Since the massive increase in cases brought along by Omikron the App hits performance limits. The “Number of Download Days” setting in the three-point-menu in the App was introduced to tackle that. Default is 14, and this can be too much.

1 Like
8

SAF is already set (just checked). I remember that without it the SD card wouldn’t work at all. Default for Warnapp Companion is now 10. That minimizes the number of occurences of this behaviour, but doesn’t cure it…

9

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.