FP Open OS: Clock resets after reboot

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… :slight_smile:

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 :wink:
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

:tired_face: 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.

Qualcomm MSM 8974

It was already pointed out that that is the expected behaviour for Qcom chipsets (mentioned CodeAurora sources are for MSM chipsets, and the base for FP Open). The delta is not an alternative solution, but the way it was designed for.

FP Open has no init.d support, unfortunatelly. But AOSP seems to have some kind of init scripting, if you want to continue your investigation: Android Booting - eLinux.org

In fact the bug is probably due to the service in userspace (/init.qcom.rc?) which has to track the time delta not working for some reason (or not implemented in FP Open by mistake)

That was, what I already assumed by saying “I’m certain”. :wink: My apologies for being too lazy to read the whole thread. The Wifi and battery draining tips got annoying. I also assumed the existence of an init system, but not a specific one like sysvrc, systemd or openrc. Since this is an embedded appliance, they tend to save space. Thanks for the starting point of doc and main rc scripts, which I found in /device/qcom/common/rootdir/etc/ of the source code. I’ll look into it, when I find the time.

1 Like

Don’t worry, we all have done that sometime, :wink:

Great! :smiley:

It would be interesting to see if there is a hook to run a shell script that does not require compiling or patching the system image. Because the bug is serious for me I am thinking to use the “custom script” facility of the AFwall+ firewall I am using to run the userinit script I mentioned in my earlier post. It’s dirty, it’s a kludge, but much better than missing your flight…

Kernel Adiutor has what it calls an “init.d emulator” tool to execute scripts on boot. I’ve just found out! Hope we can get a workaround working fine, :slight_smile:

2 Likes

Clock Reset After reboot workaround

Warning: It works on my phone but I cannot guarantee that it will work on yours. I have now tested it under a different timezone while travelling and it works. You do this at your own risk and nobody will pay your ticket if you miss your train or plane in the morning! :wink:

Thanks to @Roboe for pointing in the right direction!

Requirements

OK, lets go for it:

  • Make sure your FP2 shows the proper time.
  • Open the “Clock Offset Fix” app and click on "Install offset and initscript"
    Important: This fix does not update the offset-file regularly so you will have to update it by clicking on “Install Offset” whenever you have “cold started” your phone (removed the battery).
  • Open “Kernel Adiutor” and go to the “init.d” section (listed under "tools)
  • Enable init.d support (slider to the right and pink)
  • click on the + sign to add a new script
  • call the script rtcfix, your horses name or whatever you like, but no special characters.
  • Simply add the following line to the script (leave the #!/system/bin/sh as it is):
    /data/local/userinit.sh
  • Save and you are cooked !
  • You can check the script by tapping on the entry in the init.d section. It should show the current time as result.

Test your setup:

  • WiFi off
  • Mobile Data Off
  • Aeroplane Mode On or remove SIM
  • Wrap your phone in tin foil if you want to be really really sure it does not get the time from outside. :slight_smile:
  • Shutdown phone
  • Start phone again
  • Things going well Kernel Adiutor will set the time after approx. 10 seconds (the default delay) plus boot time. :+1:
7 Likes