bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

RESOLVED FIXED in Firefox OS v1.4


Firefox OS
4 years ago
4 years ago


(Reporter: Kate Glazko, Assigned: mnjul)



2.0 S5 (4july)
Mac OS X

Firefox Tracking Flags

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 verified, b2g-v2.1 verified)


(Whiteboard: [p=1])


(6 attachments)



4 years ago
Created attachment 8437337 [details]
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

4 years ago
Created attachment 8437338 [details]
Actual time 4:29, time on lockscreen 5:32

Comment 2

4 years ago
Created attachment 8437339 [details]
Actual time 4:40, time shown on lockscreen 5:32


4 years ago
Summary: After Restarting Phone, Time Shows as 5:32 → After Restarting Phone, Lockscreen Time Always Shows as 5:32

Comment 3

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


4 years ago
Keywords: qawanted
QA Wanted to check 1.4.
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: ychung
QAWanted to check if this occurs on Flame 1.3 (base image)
Flags: needinfo?(jmitchell)
Keywords: qawanted
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
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression, regressionwindow-wanted
Flags: needinfo?(jmitchell)


4 years ago
blocking-b2g: --- → 1.4?
QA Contact: ychung → ckreinbring
blocking-b2g: 1.4? → 1.4+

Please review for incorrect time.
Flags: needinfo?(timdream)
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
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Broken by bug 1003011.

Edgar - Can you take a look?
Component: Gaia::System::Lockscreen → RIL
Flags: needinfo?(timdream) → needinfo?(echen)

Comment 12

4 years ago
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.
Flags: needinfo?(jlu)
Window needs to checked again - the patch suspected is unrelated.
Component: RIL → Gaia::System::Lockscreen
Flags: needinfo?(echen)
Keywords: regressionwindow-wanted
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Keywords: regressionwindow-wanted
QA Contact: ckreinbring

Comment 15

4 years ago
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.
Flags: needinfo?(jlu)
Keywords: qawanted
(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.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Does the bug as written reproduce on Open C?
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted

Comment 18

4 years ago
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
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.
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.
Flags: needinfo?(jmitchell)
I know what this is. It's a flashing script bug in Naoki's flash_Gg.sh script.

Naoki - What do you think?
blocking-b2g: 1.4+ → ---
Component: Gaia::System::Lockscreen → General
Flags: needinfo?(nhirata.bugzilla)
Keywords: regression
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:

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.
Flags: needinfo?(nhirata.bugzilla)
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!
Flags: needinfo?(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.
Flags: needinfo?(dhylands)
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.
blocking-b2g: --- → 1.4+
Component: General → Gaia::System::Lockscreen
Keywords: regression
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.
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.
Flags: needinfo?(jlu)
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).


4 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+][lead-review+]
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.
Flags: needinfo?(jlu)


4 years ago
Duplicate of this bug: 1027536
Created attachment 8443383 [details] [review]
Patch (PR @ Github)

Patch as offline discussed with Greg to address bug 1027536, actually a dupe of this bug
Comment on attachment 8443383 [details] [review]
Patch (PR @ Github)

Greg, any chance you can review this patch for me? Thanks
Attachment #8443383 - Flags: review?(gweng)


4 years ago
Assignee: nobody → jlu
Target Milestone: --- → 2.0 S5 (4july)
Comment on attachment 8443383 [details] [review]
Patch (PR @ Github)

Simple change and tests are all passed. Thanks!
Attachment #8443383 - Flags: review?(gweng) → review+
Attachment #8443383 - Attachment description: WIP Patch (PR @ Github) → Patch (PR @ Github)
Master: https://github.com/mozilla-b2g/gaia/commit/fb7bfd5401c5a2dc83b8147576b9cc772808b7d9
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [p=1]
v2.0: https://github.com/mozilla-b2g/gaia/commit/ed7bd44e2a448dcb5f6e074b3d873ac4f4ae2637
status-b2g-v1.4: --- → affected
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
Backed out from v1.4 for unit test failures.
v1.4: https://github.com/mozilla-b2g/gaia/commit/c9416de14acf9e94ab006619cd2418c768422fcb
status-b2g-v1.4: fixed → affected
Flags: needinfo?(jlu)
Keywords: branch-patch-needed
Let me investigate it.
Flags: needinfo?(jlu)
Created attachment 8445724 [details] [review]
WIP / 1.4 Uplift PR @ Github
Green on Travis, thanks!

v1.4: https://github.com/mozilla-b2g/gaia/commit/4979e8d625aed26ebf2aefbf4c86c9b8412f58ce
status-b2g-v1.4: affected → fixed
Keywords: branch-patch-needed
Created attachment 8530728 [details]

This issue has been verified successfully on Flame 2.0 & 2.1.
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
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.