Alarm clock went unreliable with FPOOS 9 and still is on 10

Help Fairphone 2
14

“I just accept that a smartphone is not 100% reliable in what it does. It can’t be according to my subjective perception of nowadays software quality (or lack thereof),”

So you admit that FPOOS, which Open Source, lacks the software quality it needs?

How about improving it? Reliable software can be written.

Your words are nothing short of a capitulation.

Why should anyone want to buy a phone (or install this OS on it) if even the people close to it’s development say that it cannot be trusted?

If you don’t even set yourself higher goals, how could you ever achieve them?

I work in the IT department of a large international airport. Believe me, reliable software is possible and it does exist. Both commercial an Open Source. Without it, operating air travel would be dangerous for passengers and people on the ground. Todays jet airliners are operated solely by computers and software, they control everything on board, and so is ATC, air traffic control.

Thank god reliable software does exist.

And sorry,

“I would return it. And I wouldn’t compare a probably hardwired simple alarm clock with a computer device running overly complex layers of software. It’s quite a stretch.”

is just far away from reality. If the alarm clock isn’t mechanical, anything showing digital numbers is also just a piece of software. But a reliable piece of software.

" If all else fails … :uk: :de: :pencil2: Installing the Fairphone 2 from scratch"

As the unreliability is new to alarm clock (wasn’t there before A9 level), simply undo the damage done to it’s source code. Regress and go back to earlier, reliable code revisions, and learn where the mistake was done.

1 Like
15

In my point of view that is true for the largest part of any halfway complex software running today.
It could be different, as luckily you attest to yourself.

Absolutely.
Perhaps you can help me out a bit.

Is better software quality in aviation achieved by applying best development practices from the ground up, or just by rigorously cleaning up after industry “standard” development practices because strict regulation in aviation defines that in the end somebody will have to take responsibility for mistakes instead of treating software malfunction like an act of God?
I lack the insight to perhaps draw some hope out of it.

Because customers readily do this because of other priorities, there’s not much choice anyway, and if there would be a realistic choice, would customers prioritise the better approach? The better concept doesn’t automatically win, IT is full of examples of this. Or to phrase it better, the market decides the better concept in hindsight and not entirely based on conceptual priorities.
And I’m not close to development, just to say.

For this it would first need to be established that there is in fact something wrong with the clock App and the issue is not caused by other influences.
Given that, this should of course be fixed, and then on to the next bug.

1 Like
16

This has nothing to do with FPOOS and is a general problem regardless of the system installed and starts with Apple and Google. You cant compare with important software used in other circumstances, we are talking about a Smartphone, and the FP2 is an old smartphone and keeping it alive is cost intensive and difficult due to the old Hardware.

And a digital alaram clock has nothing else to do than showing the time and waking you up, a Smartphone has a lot more responsibilities, so a comparison of apples with oranges.

Overall I guess we will not agree here, you dont want to accept and I accept such obstacles as not important for me. Fight your fight and accept I will not attend this fight.

I understand you are unhappy and I cant change this ,so please get in touch with Fairphone.
We are not Fairphone, so telling us what you expect will not help you.

17

“Because customers readily do this because of other priorities, there’s not much choice anyway,”

What other priorities would make anyone accept an untrustworthy device? And “not much choice” in smartphones, this must be a joke of yours.

“For this it would first need to be established that there is in fact something wrong with the clock App and the issue is not caused by other influences.”

I already established that. The alarm clock app was reliable up until the upgrade to Android level 9.

Theoretically, the root cause (to speak in ITIL terms) could be something else. And my assumption (being an ISTQB certified software tester) is that it is not only the alarm clock app, but something in the OS around that changed - and the app was not properly adapted to. Because FPOOS since the upgrade to Android level 9 does have problems with crashing apps all around. Commercial, open source, there seems to be no common denominator. Which does lay proof to a fundamental flaw. And no, it’s not about my device. There are numerous bug reports from users that have problems with apps crashing since A9. And most of those users hoped it could go away with A10. Because most bug reports on A9 got closed with remarks like “why don’t you upgrade to A10?”. But it did not go away.

18

“This has nothing to do with FPOOS and is a general problem regardless of the system installed and starts with Apple and Google.”

Why is it then that there are no reports of unreliable SW with Google’s Android? If the alarm clock in Googles Android would have been as unreliable, surely we would have read tons of complaints, because of a user base in the hundreds of millions… So it does have something to do with FPOOS and only with FPOOS.

“You cant compare with important software used in other circumstances, we are talking about a Smartphone, and the FP2 is an old smartphone and keeping it alive is cost intensive and difficult due to the old Hardware.”

Of course you are right the HW is old. But the HW is the one thing totally innocent in this regard.

“And a digital alaram clock has nothing else to do than showing the time and waking you up, a Smartphone has a lot more responsibilities, so a comparison of apples with oranges.”

Sorry, no. Android is built on a fork of the Linux kernel, and the Linux kernel is known to be very effective in process isolation and memory protection. Which is why today the critical IT systems in airline industry are built on Linux and not on Windows…

“I understand you are unhappy and I cant change this ,so please get in touch with Fairphone.
We are not Fairphone, so telling us what you expect will not help you.”

I did open a ticket on the issue tracker, thanks for providing the link.

19

Dont agree

No reports🤔

Btw dont see any report here except yours, so…

20

I’ll make a clarification, so this doesn’t take on a wrong twist: I do not blame anyone, especially not in here.

But from my perspective, there is nothing that could be more important than stability and reliability. Without them, there can be no performance, there can be no feature that could be counted as an asset. Without stability and reliability, everything (!) you may strive for in software will come tumbling down.

A system with only few features, but with stability, is a much (!) better base for development and growth than a feature packed, but instable system. Which is why such a system must always be preferred.

So from my (ISTQB) perspective I would like to give the advice to put stability at the top of all demands directed at any (!) SW. Or HW.

21

“Dont agree”

Then please enlighten me. I am a HW specialist, and I don’t see it. What leads you to the assumption that the HW could be an issue regarding the alarm clock?

“Btw dont see any report here except yours, so…”

Then please look again. Regarding the alarm clock there is more than just mine. Not many, yes, but mine isn’t the only one. And regarding crashing apps on A9 und up there numerous reports. And: Even if there would be only one report: That is not a valid proof, not even a basis for an assumption, that it would be that devices fault. Technically just not the case. I analyse problems professionally. In 30 years such a connection could only rarely be discovered. If there is a HW problem leading to instability, it almost never shows itself in some apps crashing. If HW problems lead to that you get much more severe crash scenarios.

HW instability in most cases comes from cold solder spots, broken PCB traces, connector problems or - most prominently - problems with proper thermal management. I can rule out all of them here.

22

It’s new.
It’s shiny.
It’s cheap.
It’s expensive (to show off).
It has [insert the next best feature here].

You name it. Who overall cares about software quality/reliability in the scope of the general public?

Not much choice in software quality/reliability in this context. Sorry for not being clear.

Ok, but how many affected users upgraded to a newer basic OS version in-place via the updater, a tricky procedure which on any OS and not only on smartphones will always leave some users with the short straw of something not working right after the procedure? And how many installed from scratch, which should establish a well-defined and tested state of the phone?

Anyway, apart from the things already offered in this topic, this should be for Fairphone to sort out …

https://support.fairphone.com/hc/en-us

https://issuetracker.fairphone.com/products/fp2-a10/

23

"It’s new.
It’s shiny.
It’s cheap.
It’s expensive (to show off).
It has [insert the next best feature here].

You name it. Who overall cares about software quality/reliability in the scope of the general public?"

I am speechless. Do you really believe these should be goals in any development to follow? And yes, I know many people caring about reliability. I see them every day. As soon as people depend on software (i.e. the use it to do their job/earn a living etc.) they do care. In fact, they demand this with full force given to them. Have you ever witnessed a hotline? I mean, from the operator side?

24

Of course not. You still argue from a standpoint of what would be desirable in an ideal theoretical situation.
While I guess we wouldn’t have many differences about what would be desirable, I’m arguing from a standpoint of what I see in reality in front of me. And I’m simply dealing with that reality.

Good for you. Doesn’t seem to improve the default modus operandi of the software industry and thus overall software quality much, though?

25

“Good for you. Doesn’t seem to improve the default modus operandi of the software industry and thus overall software quality much, though?”

Software manufacturers that do not deliver or even refuse to correct bugs will simply get kicked out. Depending on their conduct, this may range from being blacklisted to being sued.

26

Now I want to look optimistically towards the future and happily revisit this in let’s say 10 years from now to see whether we are then in a better place overall in this regard, or whether the software industry still gets away with declaring alpha/beta states as market-ready products, mixing in blatant and totally preventable security missteps now and then for thrilling excitement, forever patching and fixing issues which shouldn’t be there in the first place. I’m not holding my breath, but I like positive surprises.

1 Like
27

No need. We are doing this for the last 50 (!) years. No one delivers nonfunctioning SW to my employer. Some have tried. And failed. It seems to me that you only have the view of a personal user of IT, is that possible? Professional IT is very different. Pacta sunt servanda. You have to deliver what you promised your customers.

28

A naive question from me, do you test the software with all the use-cases possible, with all the different settings? Because it seems to me software bugs depend of how you use the software, and I think there’s a difference between software done to operate planes that should always work more or less the same for the same tasks, and software of mobile devices which you can customize at will.

To come back to the topic, have you tried clearing cache or storage of the clock app? Have you tried dic:safemode?

Well, I was never affected by any bugs on any software versions of FPOOS concerning alarms on my testing FP2 (on A9 and A10), and I used it every day for two years. It means it’s not general. There is a use-case (I mean by that a set of variables) where it works. To be able to say a problem seems general, you need really many reports, which doesn’t seem the case to me about the alarm clock. Crashing apps may be a different problem, or even different problems for everyone with a similar consequence.
How can you know it’s not a specific app you installed that creates a bug stopping the alarm from working well, that was updated simultaneously? Then it wouldn’t be FP’s fault. And there are many other variables.

1 Like
29

“A naive question from me, do you test the software with all the use-cases possible, with all the different settings? Because it seems to me software bugs depend of how you use the software, and I think there’s a difference between software done to operate planes that should always work more or less the same for the same tasks, and software of mobile devices which you can customize at will.”

First of all, we don’t test aircraft software. That is done by the aircraft manufacturers (and EASA). Our focus is the ground. Second, a modern jet airplane is much much more sophisticated than a simple smartphone! Actually, with more than a dozen (or more) high-performance computers it’s more like a flying data center. And, most important: Aircraft software must perform in real time, something smartphones do not. That is a complete game changer. Under RT conditions, deviations that would not even be recognized on normal systems can lead to fatal malfunctions here.

Just to illustrate the criticality of reliable software: The famous rescue on the Hudson River was performed by a skilled pilot who knew the behaviour of his vessel. Sullenberger had to reduce speed at maximum rate. However, braking without engines means increasing the angle of attack, and even pulling slightly too much results in stall meaning crash. Sullenberger knew his plane that had what is called “flight envelope” control, meaning: The computers would constantly reduce pilot input so that the airplane will always stay in the air. So Sullenberger deliberately pulled too much, knowing the computers would always keep the plane on the razor thin line between maximum braking and falling out of the sky. That is trust in the reliability of computers…

Regarding the “all settings” question: That depends on the depth of the test. Most of the time, different settings do not cross-interact. So it is mostly not necessary to go thru all billions of permutations. Most tests are regressions where a certain function gets a close look, and results are compared to previously recorded results. If full tests are required, these are done with test automation software.

I did clear caches. So far I did not erase alarm clock’s memory, because then I would have to reprogramm all 14 alarms that I have (most of them are constantly off, only one is always on).

30

Very interesting.

I certainly think you should test your phone in safe mode as Alex has suggested. That won’t delete your data.

I’m impressed by the 14 alarms. Just wondering whether you might not have hit on a use-case that rarely occurs and hasn’t been tested very thoroughly. If safe mode doesn’t help then in your place I would delete the app data and test one alarm, and add others gradually. In the mean time (no pun intended), maybe you could use your calendar to produce reminders, if that’s enough.

31

I agree with you that very stable SW can be written where nearly all bugs are ironed out. But as you mentioned this needs very thorough testing and so lot of time and money (and gives a lot of sense for the business SW for airplanes!).
This is IMHO unfortunately not like it works with software for consumer devices. In this case what counts is low price and always new features. You may like it or not. But this is what I observe…

You could do a full backup of your device using TWRP and clear data or even apps. And restore everything if it didn’t help anyway or if you found the reason.
Still easier it might be to just start with the safe mode as mentioned above.

P.S. and please use the quote function of the forum when quoting others (instead of just putting the quotes into " signs)! Your posts will be much easier to read then! Thanks.

2 Likes
32

For the moment, although I think I did try to remove and re-set all alarms, the problem went away after I added a new test alarm, which worked flawlessly. I deleted my regular alarm and changed to test alarm to this time, and deleted many auxiliary alarms, and since then it seems to be trustworthy again. So at the moment I suspect, altough this is hardly explaining why the alarm clock process would die over the course of a day, that a damaged alarms database could be the culprit.

1 Like
33

Unfortunately the problem has reappeared after having been away for some weeks. I did disassemble, clean/tighten contacts and springs, which improved things, but now I will go for a refurbished bottom module.