Please note that switching off the phone and switching on again uses more power than a night in airplane mode - so it’s recommended to use airplane mode instead of switching off.
4 Likes
Same for me. I haven’t had another reboot during the night, so I just hope for the best!
Hi! I found a workaround for when I have important meetings: turn on wifi! The clock syncs directly with wifi, even if you don’t unlock the sim. I tried last night: turned on wifi, manual reboot, no sim-unlock, and the alarm clock woke me up.
Wouldn’t do it every day though, wifi drains the battery.
Edit: I’m writing about the alarm clock issue, many of you already had mentioned wifi of course!
1 Like
I don’t think anyone is actively maintaining that github. Reporting bugs here on the forum is sufficient.
Just noted the FP1 tags for that repository. Seems you were right.
thank you for your help paul. maybe this hint should be added to the batteries guide also as former FP1 user were used to turn off their phone automatically by FP1s system feature. And it has the benefit of a correct wake up too… 
Like most smart phones the FP2 cannot wake up for giving an alarm, because it has no hardware clock. So not only in regard to safe battery it makes sense to keep it on (I.e. In flight mode), but also for the alarm clock to work.
1 Like
This does not help a person like myself who does not want to have a microwave transmitter sitting by the bedside.
2 Likes
Well, if you put your phone far away, not only will you sleep without microwave transmission but it also helps to minimize the repetitive snoozes 
Let’s hope that FP will come up with a fix in the next update.
Hi,
Just installed 16.09 and the bug is still there. Could we have a statement from Fairphone about this bug? It’s out there since May and I haven’t read anything official. I wonder if the team is working on it and trying to find a solution or if they’re not even working on it. I’m not a developer and I may be a bit naive, but I don’t think that a working clock should be such a tricky thing to fix?
Is there a list of the bugs and developments FP is currently working on?
12 Likes
Solved (or almost)?
I’ve just updated (16.10.0) and had a nice surprise! After turning off and on again, without wifi, it took less than 5 seconds to update the clock. I saw the wrong time for some seconds, got an error message from a calendar or Whatsapp (can’t remember), but the clock instantly changed!
Can you confirm that it works on your phones?
If so, thank you FP to have fixed it, it’s a very good surprise. You could have communicated earlier that you were actively working on that, so we would have been more patient at the end, but the result is a good surprise.
That’s because you have a SIM in your phone.
The bug is only fixed if you can reboot without a SIM and with Wifi turned off and get the right time & date (immediately).
1 Like
Clock bug not fixed on 16.10.0: Your Fairphone for -47 Years, 08 Months, 23 Days… when the phone is put into aeroplane mode & WiFi off before reboot. The moment I disable aeroplane mode the clock gets synced.
1 Like
Doesn’t work on my phone! These annoying Issue is still there.
I confirm!
there is an improvement, because if you are not on flight mode, the clock comes back really fast. Still a bug though, because if your phone is on flight mode during the night and reboots, you won’t wake up.
I am not sure if there is an improvement. In my experience the online syncing largely depends on the network at your location (provider, signal strength, network type G/G3/G4/H/H+ : When I was with EE I only got a clock-sync when I enabled mobile data while Vodafone syncs fast even without data enabled.
1 Like
There might be light on the horizon for a workaround / kludge for this bug. I had a look on XDA and found this: http://forum.xda-developers.com/showthread.php?t=2580974
I downloaded and installed file version 2.2 (the latest of the listed APKs). The application creates the clock-delta and installs the startup file. However the FP2 does not execute the userinit.sh on boot. But - and a big BUT here: If I execute /data/local/userinit.sh manually as root (using connectbot) the script does the promised action and sets the clock to the right time using the delta it created before. This leaves one questions for me:
How can I run a custom script as root after boot without modifying the system image ? I am on Open OS and I want to avoid using apps like “Script Manager” from Google Play.
2 Likes
Grrrr, I was being too optimistic and you are completely right: I made the test on a trip in another country and the clock came back real fast; being at home now, I can confirm that there is no improvement at all. It must have been linked to the provider or the network type.
I also investigated this issue quite a bit. I’m certain, that it was already pointed out, that it’s caused by the kernel having no write access to the hardware clock, while it is actually working. My attempt for fixing this was changing kernel configuration.
The Mainboard is a MSM 95xx by Qualcomm (can’t recall it exactly) and there would be a rtc driver for it. The actually used driver is currently rtc_drv_qpnp and since this allows read access to the rtc it should be correct. rtc_drv_msm is explicitly unset. Interestingly activating this in 16.08.0 fixed the charging hang on poweroff, when a USB cable was attached (fixed in 16.09). I assume, that dependent options fixed it in a way.
Anyway the only option for fixing it by a kernel configuration change would be, that the MSM driver could be used instead of qpnp, but I doubt it. The msm driver would be altered by rtc_secure_time_support, which possibly would allow the support, but I couldn’t get it to compile successfully. I’m still too unexperienced for kernel development, so providing a kernel configuration change would have been option one to help. But even if I would be capable of that, Qualcomm could have made it inaccessible for non-customer friendly reasons.
This leaves option two: I actually already read in a kernel dev thread, that a delta saving and restoring script or program is the only solution for that. I’m just not yet familiar with the Android init system, or generally the autostart mechanisms. Using the init system would be preferable though, because this should prevent app failures because of time desync (eg. ssl certificate validation failures). It has to be set before the network interfaces get up. I could look into init service development. I just have to find the documentation for the used one.
Still, option one would be much cleaner and option two is just a workaround. So it depends on the device. One could find that out by rooting Fairphone OS and checking the date of hwclock. If it is set correctly there, a fix should be possible. Otherwise they also use a delta time script / init service.