1022984 - After Restarting Phone, Lockscreen Time Always Shows as 5:32

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Kate Glazko]

Attachment: Actual time 4:27, Time on Lockscreen 5:32

Platform: 32.0a1
Build ID: 20140609040203
Commit: 12af9312

When I restart my phone multiple times, the time shown on the lockscreen is 5:32 despite the time inside not showing 5:32..

Comment 1

[Kate Glazko]

Attachment: Actual time 4:29, time on lockscreen 5:32

Comment 2

[Kate Glazko]

Attachment: Actual time 4:40, time shown on lockscreen 5:32

Comment 3

[Kate Glazko]

Was able to reproduce this on someone else's device, too.

Comment 4

[Jason Smith [:jsmith]]

QA Wanted to check 1.4.

Comment 5

[Yeojin Chung [:YeojinC]]

This issue DOES occur on Flame 1.4. 
Incorrect time is displayed on the lockscreen when the device is restarted.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140611000202
Gaia: d1cf95dc5e8b2f52148487291318542f1396608e
Gecko: a8bb6b76696b
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Comment 6

[Joshua Mitchell (Inactive)]

QAWanted to check if this occurs on Flame 1.3 (base image)

Comment 7

[Yeojin Chung [:YeojinC]]

This issue does NOT occur on the Flame 1.3 Base Image:

Environmental Variables:
Device: Flame 1.3
Build ID: 20140520094859
Gaia: a73235d23685e9898f40647cebd83b3fcbfd0117
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3) 
Firmware Version: v10G-2

Comment 8

[Preeti Raghunath(:Preeti)]

Tim

Please review for incorrect time.

Comment 9

[Chris Kreinbring [:CKreinbring]]

Flame 2.0 b2g-inbound regression window:

Last Working
Build ID: 20140506023004
Gecko: https://hg.mozilla.org/integration/b2g-inbound/rev/82bb5983a805
Gaia: cfc40f41bf417c2d242033fefd53b7aa3f3bf71c
Platform Version: 32.0a1
Firmware Version: v121-2

First broken
Build ID: 20140506053004
Gecko: https://hg.mozilla.org/integration/b2g-inbound/rev/ffe3501fe2ba
Gaia: a3abb00ae7820aed4785f285b8fe7388df06b985
Platform Version: 32.0a1
Firmware Version: v121-2

Last Working Gaia / First Broken Gecko - Fail
Gaia: cfc40f41bf417c2d242033fefd53b7aa3f3bf71c
Gecko: https://hg.mozilla.org/integration/b2g-inbound/rev/ffe3501fe2ba

First Broken Gaia / Last Working Gecko - OK
Gaia: a3abb00ae7820aed4785f285b8fe7388df06b985
Gecko: https://hg.mozilla.org/integration/b2g-inbound/rev/82bb5983a805

Gecko push log: hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=82bb5983a805&tochange=ffe3501fe2ba

Comment 10

[Joshua Mitchell (Inactive)]

http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=82bb5983a805&tochange=ffe3501fe2ba

Comment 11

[Jason Smith [:jsmith]]

Broken by bug 1003011.

Edgar - Can you take a look?

Comment 12

[Edgar Chen [:edgar]]

Hmm, I do not see any direct relationship between bug 1003011 and this one. Bug 1003011 is to activate sim card for Flame and the change only affects Flame (guarded by system property). Anyway, I will check this on my side.

But I would like to ni? gaia guys as well, maybe they can help to find some clues from lockscreen point of view.

Hi John, could you help to check this as well?

Thank you.

Comment 13

[Jason Smith [:jsmith]]

Window needs to checked again - the patch suspected is unrelated.

Comment 14

[Joshua Mitchell (Inactive)]

After further investigation it appears that attaining this regression-window is being blocked by another issue.

Below are the variables for the first available broken build that we have available where this issue reproduces. The bug verification of earlier builds is blocked by https://bugzilla.mozilla.org/show_bug.cgi?id=994463. Also Since the work around for bug 994463 requires the user to go past the first lockscreen after a phone restart where bug 1022984 is seen, the work around will not help us in continuing the regression window. (The work-around becomes invalid after resetting the phone, which the repro requires). 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140506163010
Gaia: 98ca8c55dbe2f21a8661d0eaa87f34d316c3bc98
Gecko: 4e4e0f502969
Version: 32.0a1 (2.0)
Firmware Version: v10G-2

Comment 15

[Edgar Chen [:edgar]]

After did more investigation, I found the device time will be reset to 1970-01-01 xx:xx:xx after reboot. So the time you saw in lockscreen after reboot is the incorrect one and it will be updated to correct one in few seconds later because device get the correct time from network  ("Settings->Data&Time->Set automatically" is enabled).  

So if you disable "Settings->Data&Time->Set automatically", you will see device time is reset to 1970-01-01 xx:xx:xx after reboot. Could someone help to confirm this behavior? Thank you.

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Edgar Chen [:edgar][:echen] from comment #15)
> So if you disable "Settings->Data&Time->Set automatically", you will see
> device time is reset to 1970-01-01 xx:xx:xx after reboot. Could someone help
> to confirm this behavior? Thank you.

Yes, this is true on Flame with today's 2.1 build with a SIM card present in the device. After disabling 'Set automatically' from Date & Time and reboot, the device shows 01/01/1970 with an incorrect time.

However, on Buri with today's 2.1 build with a SIM card present in the device, the issue does NOT reproduce. After disabling 'Set automatically' and reboot, the device continues to show the correct time as it did prior to reboot.

Comment 17

[Jason Smith [:jsmith]]

Does the bug as written reproduce on Open C?

Comment 18

[Harvey]

This issue DOES reproduce on the latest Open_C

Environmental Variables:
Device: Open_C 2.1 - Master
Build ID: 20140617122234
Gaia: 83392cae2c964fa6f8a97ac3fc515c3f94ef3c1c
Gecko: 5be519918f65
Version: 33.0a1 (2.1 - Master) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 19

[Dave Hylands [:dhylands]]

I've confirmed that if you put the command:

> log "b2g.sh: $(date)"

into /system/bin/b2g.sh then it always reports 1970 as the year (on my Flame).

This suggests to me that the base image isn't correctly setting the time from the HW RTC.

Comment 20

[Dave Hylands [:dhylands]]

Or that the HW RTC isn't correctly being set in the first place.

Note sure if its relevant or not, but I also noticed that whenever I flash my phone (using a local build), then I see the following at the end:

> Attempting to set the time on the device
> time 1403046216 -> 1403046216.0
> settimeofday failed Invalid argument

I believe that the "Invalid argument" is coming from this code (system/core/toolbox/date.c)

>  res = ioctl(fd, ANDROID_ALARM_SET_RTC, &ts);
>  //res = settimeofday(&tv, NULL);
>  if(res < 0) {
>      fprintf(stderr,"settimeofday failed %s\n", strerror(errno));
>      return 1;
>  }

which implies that the kernel compiled with the base image doesn't support the ANDROID_ALARM_SET_RTC ioctl, which is how the HW RTC is supposed to be set.

Comment 21

[Jason Smith [:jsmith]]

I know what this is. It's a flashing script bug in Naoki's flash_Gg.sh script.

Naoki - What do you think?

Comment 22

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

There is a bug in regards to setting the time on some systems for the flash script.
( it's also in the ./flash.sh for the b2g repo )

As far as I understand things, the NTP sets the time with wifi on/SIM on if set time is set to automatic, so in testing this, you have to have that setting off.

However this doesn't explain the discrepancy between the lockscreen and the status. 

I think I found a separate bug:

STR:
1. after having flashed and wifi turned on
2. turn off set time off automatically
3. adb shell date -s 20140615.040302
4. set time automatically on.

I don't see the time returning back to the proper time via NTP.

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Dave, I am not sure I understand comment 20.  

Does this mean an invalid date will some how default to the wrong date after reboot all the time for the android date function?

Also does this mean we need a kernel compiled with the base image does support the ANDROID_ALARM_SET_RTC ioctl; ie this is a vendcom issue?

Thanks in advance!

Comment 24

[Dave Hylands [:dhylands]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #23)
> Dave, I am not sure I understand comment 20.  
> 
> Does this mean an invalid date will some how default to the wrong date after
> reboot all the time for the android date function?

I think that the Invalid Argument is the ANDROID_ALARM_SET_RTC. I'd have to check the kernel driver to be sure.

> Also does this mean we need a kernel compiled with the base image does
> support the ANDROID_ALARM_SET_RTC ioctl; ie this is a vendcom issue?

I think so.

Comment 25

[Jason Smith [:jsmith]]

The above comments imply the original bug as filed isn't a vendcom issue - it's a lockscreen bug. But there's a separate problem we also found here that's a vendcom issue.

Comment 26

[John Lu [:mnjul][Please NI or I'll miss]]

Hi all,

If we think this is (still) a lockscreen issue, regardless of being dependent on some other platform/kernel issue or not, Greg and I would still like to see some regression window analysis for Gaia to see what we can fix.
I understand chances are the regression window analysis might be hard or even impossible to do before related platform/kernel issue is resolved, so if the analysis cannot be done right now, we can do it later (but it will still be needed). Thanks.

Comment 27

[Tim Guan-tin Chien [:timdream] (please needinfo)]

John, based on previous comments I don't think it's possible for QA to identify the regressed bug without more specific STR. If you have better instructions on how to workaround the platform issue (restart b2g process only?) please specify and set regressionwindow-wanted again.

Comment 28

[Dave Hylands [:dhylands]]

As far as the lockscreen window thing goes, Here's my guess as to what's happening:

1 - B2G starts up - date is set to 1970
2 - Homescreen gets initialized - date is still set to 1970
3 - In the background, the date gets automatically corrected (over cell or wifi) and the system date/time gets corrected
4 - When you unlock the phone, you see the correct date/time.

So I'm thinking that there needs to be some type of notification of the date/time change that gets broadcast to the apps (I think that the lockscreen is now an app, where it used to be part of the system).

Comment 29

[John Lu [:mnjul][Please NI or I'll miss]]

Hi everyone,

It seems that with the latest Gecko/Gaia build, Flame no longer boots into epoch time, and shows correct time after boot ? I've turned off the Set Automatically in Date/Time setting and after reboot, lockscreen still shows correct time.

Now, do note the time on lockscreen just after rebooting probably doesn't advance, though -- I have discovered bug 1027536, which will be fixed on its own.

Comment 31

[John Lu [:mnjul][Please NI or I'll miss]]

Attachment: Patch (PR @ Github)

Patch as offline discussed with Greg to address bug 1027536, actually a dupe of this bug

Comment 32

[John Lu [:mnjul][Please NI or I'll miss]]

Comment on attachment 8443383 [details] [review]
Patch (PR @ Github)

Greg, any chance you can review this patch for me? Thanks

Comment 33

[Greg Weng [:snowmantw][:gweng][:λ]]

Comment on attachment 8443383 [details] [review]
Patch (PR @ Github)

Simple change and tests are all passed. Thanks!

Comment 34

[John Lu [:mnjul][Please NI or I'll miss]]

Master: https://github.com/mozilla-b2g/gaia/commit/fb7bfd5401c5a2dc83b8147576b9cc772808b7d9

Comment 35

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/ed7bd44e2a448dcb5f6e074b3d873ac4f4ae2637

Comment 36

[Ryan VanderMeulen [:RyanVM]]

v1.4: https://github.com/mozilla-b2g/gaia/commit/fcc1d87b8529a8eec109b2aa5cf57129c46904fd

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Backed out from v1.4 for unit test failures.
v1.4: https://github.com/mozilla-b2g/gaia/commit/c9416de14acf9e94ab006619cd2418c768422fcb

Comment 38

[John Lu [:mnjul][Please NI or I'll miss]]

Let me investigate it.

Comment 39

[John Lu [:mnjul][Please NI or I'll miss]]

Attachment: WIP / 1.4 Uplift PR @ Github

Comment 40

[Ryan VanderMeulen [:RyanVM]]

Green on Travis, thanks!

v1.4: https://github.com/mozilla-b2g/gaia/commit/4979e8d625aed26ebf2aefbf4c86c9b8412f58ce

Comment 41

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.0 & 2.1.
Steps:
1.Turned off the Set Automatically in Settings.
2.Restart device with/without SIM card.
**Lockscreen will show the correct time.

See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/5

Flame v2.0 version:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141130000204
Version         32.0

Flame v2.1 version:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141130001203
Version         34.0