Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon
program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation
function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review
Someone already tried to patch the property in the kernel
Originally Posted by Anirudh Ghayal (Qualcomm consultant)
In some of our MSM/QSD designs, we have a single RTC shared by multiple
processors (other than the ones running Linux). Thus, the need to have a
non-writable RTC using this pdata.
, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X
files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)