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.
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 …
"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?
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?
“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.
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.
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.
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.
“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).
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.
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.
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.
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.