Just another “me too”:
Symptoms:
- (if using the phone) - screen freezes for a few seconds (does not respond to touches or keypresses) then turns black. Now the phone is in a “crashed” state.
- (if not using the phone) - one finds the phone unresponsive (same “crashed” state) and battery mostly drained the next day
- if keeping the phone in the “crashed” state, battery is drained much faster than during normal usage (from ~80% to ~10% within 3-4 hours), heats up a little bit (over the course of e.g. 1-2 hours)
- Restoring phone functionality requires battery in/out or long press
- happens about 3-4 times per week for me. (note that I use the phone very little, it’s mostly lying in a corner - I have a feeling crashes happen more often when I use the phone more actively)
- behaviour is very random; with/without GPS, with/without actively using the phone; with/without WIFI enabled; using apps or doing nothing;
My current OS version:
- Build number userdebug 5.1 FP2 fp2-sibon-16.06.0
Hypothesis:
- the randomness of this problem occuring reminds my software developer brain (not a mobile developer though I’m afraid) of a race condition triggering this problem.
- the increased battery usage in the “crashed” state could mean there is some infinite loop, or a deadlock/livelock is being triggered - that could also explain the short initial screen unresponsiveness.
Is it possible that there are multiple JVM threads accessing something that is not thread-safe?
Questions:
- Race-condition-type bugs are hard to debug, sure, since reproducing the issue is time-intensive. Still, can we get this problem onto a list of issues that fairphone developers will take a look at? This thread has been open since January 2016 after all.
My suggestion
More messages of the kind “me too” don’t help much - what’s needed is someone familiar with the FP2 codebase to make an educated guess as to which part of the codebase is likely to have a race condition that could lead to the problems explained in this long list of posts. And then to construct a test case exhibiting that potential race condition, by executing certain parts of the code hundreds of time. Then either that part is probably race-condition free, (in which case the next educated guess should be done), or one can start narrowing the issue to a smaller area of code, making changes, re-running the test, etc. At least that’s how I’d approach this problem as a backend developer. Not sure how easily this is done on android.
Thanks.