Closed Bug 833060 Opened 11 years ago Closed 11 years ago

B2G RIL: Need a way to know whether NITZ is available or not

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed, b2g18-v1.0.0 fixed, b2g18-v1.0.1 fixed)

RESOLVED FIXED
B2G C4 (2jan on)
blocking-b2g tef+
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- fixed
b2g18-v1.0.1 --- fixed

People

(Reporter: kaze, Assigned: airpingu)

References

Details

(Whiteboard: QARegressExclude)

Attachments

(1 file, 1 obsolete file)

For the FTU and Settings apps, we need a way to know whether NITZ is available or not:
 • if available, we can propose a “Set automatically” button and preset the time and timezone;
 • if not available, we can hide this “Set automatically” button and ask the user to set the time and timezone manually.
This blocks a tef+ bug, nominating.
Blocks: 827764
blocking-b2g: --- → tef?
Smells like my bug.

Kaze, I'd prefer adding a new entry in the settings (maybe "time.nitz.available"). What do you think?
Assignee: nobody → clian
It’s not ideal but if it’s possible to have a read-only setting, it’s OK as far as I’m concerned. Do we already have other read-only settings in FxOS?
(In reply to Fabien Cazenave [:kaze] from comment #3)
> It’s not ideal but if it’s possible to have a read-only setting, it’s OK as
> far as I’m concerned. Do we already have other read-only settings in FxOS?

As my best understanding, we don't have the mechanism for read-only settings by far.

Vicamo,

In general, how to expose the RIL info (like NITZ in this issue) to web apps? If we need to create a new DOM API for it, do you know where is the best place to put?
Flags: needinfo?(vyang)
I don’t think we intend to expose the RIL info to web apps, but I can be wrong.

(In reply to Gene Lian [:gene] [:clian] from comment #4)
> As my best understanding, we don't have the mechanism for read-only settings
> by far.

Given the time frame, I guess it would be acceptable to have a `time.nitz.available` setting if the back-end ensures that each time this setting is written, it’s overwritten with the real value.
(In reply to Fabien Cazenave [:kaze] from comment #5)
> I don’t think we intend to expose the RIL info to web apps, but I can be
> wrong.
> 
> (In reply to Gene Lian [:gene] [:clian] from comment #4)
> > As my best understanding, we don't have the mechanism for read-only settings
> > by far.
> 
> Given the time frame, I guess it would be acceptable to have a
> `time.nitz.available` setting if the back-end ensures that each time this
> setting is written, it’s overwritten with the real value.

All right. I think it's feasible. I'll upload a patch for this tomorrow. :)
Flags: needinfo?(vyang)
blocking-b2g: tef? → tef+
Attached patch Patch (obsolete) — Splinter Review
Hi Philikon :)

Could you please take this review? It's an issue about NITZ. Please feel free to let me know if you don't have enough bandwidth. The alternative reviewers could be :vicamo or :gwagner. 

Summary:

1. Provide an entry "time.nitz.available" in the settings DB, which is initialized as false when starting up.
2. Whenever the RIL has a valid NITZ info, set "time.nitz.available" to true.
3. Since the "time.nitz.available" can only be written by RIL, we have to check if the setting change is coming from the content process. If yes, restore the old value.
Attachment #705806 - Flags: review?(philipp)
Btw, please see comment 5. I understand this fix is tricky, but given the time frame, this might be an acceptable solution.
Attachment #705806 - Flags: review?(philipp) → review+
Attached patch Patch 1.1Splinter Review
Rebased and r=philikon.

Thanks Philikon for the review!
Attachment #705806 - Attachment is obsolete: true
Attachment #706304 - Flags: review+
Hi Kaze,

This has been landed to b2g18 and will also be done for m-c sooner or later. Please give it a try with |time.nitz.available|. Thanks!
Hey Gene, yep I saw that this morning, looks good! I’m finishing another tef+ patch and I’m on this one in an hour or two.
Hmm, I think this doesn’t work with my carrier (Free Mobile, France). I’ll try to test with other carriers ASAP.
I can do some testing on this later. Two things to note here:

(1) I missed the fact that we want this for FTU. I am not sure how often carriers send NITZ packets down the pipe, but it's not very often. Maybe they do it soon after a SIM card registers with the network, but I don't know. Most carriers support it, so what kaze is seeing actually sounds pretty normal. He might find 'time.nitz.available = true' in a day or so.

(2) We should reset this value when a SIM card is changed. Because you might be switching from one carrier that supports NITZ to one that doesn't. Gecko has no recollection of SIM cards, but I think the system app does. So we'll need to allow the system app to change this setting. This may mean that we need to get rid of the code in RadioInterfaceLayer that resets 'time.nitz.available' if it's changed from content. I think that's fine, we don't have to be overly paranoid about content wanting to change this setting.

Overall, I don't think enabling/disabling UI based on NITZ availability is a great idea due to the nature of the problem. It would be better to always allow the user to choose have time + timezone set automatically, but if we haven't received a NITZ packet in a few days or so, let the user know that NITZ "appears to not be available".
(In reply to Philipp von Weitershausen [:philikon] from comment #14)
> I can do some testing on this later. Two things to note here:
> 
> (1) I missed the fact that we want this for FTU.

Yeap! FTU is probably too early to know the availability of NITZ, when the carrier is still not registered. 
I didn't consider this case because it seems it's still a debate whether to include "Set automatically" or not in FTU.

> (2) We should reset this value when a SIM card is changed. Because you might
> be switching from one carrier that supports NITZ to one that doesn't.

My original thought is we can still use the valid NITZ as long as we used to get one form any carriers. From the point of view of Gaia, should it know where the NITZ is coming from? I mean once we've got a valid NITZ then the "time.nitz.available" should always be true. What do you think?

> Overall, I don't think enabling/disabling UI based on NITZ availability is a
> great idea due to the nature of the problem.

However, supposing a user sets the system time manually to any incorrect time. When he enables the "Set automatically", he would expect to see the system time to be adjusted to the correct time. If we don't hide "Set automatically" in advance (when the NITZ is not available), users might get confused because this function doesn't work.
(In reply to Fabien Cazenave [:kaze] from comment #13)
> Hmm, I think this doesn’t work with my carrier (Free Mobile, France). I’ll
> try to test with other carriers ASAP.

Sorry for letting you down. "time.nitz.available" should be set to true very early when booting up with a valid SIM card supporting NITZ. It works for me, though. I'll try to figure out what's happening on Monday morning.
Summary: Need a way to know whether NITZ is available or not → B2G RIL: Need a way to know whether NITZ is available or not
(In reply to Fabien Cazenave [:kaze] from comment #13)
> Hmm, I think this doesn’t work with my carrier (Free Mobile, France). I’ll
> try to test with other carriers ASAP.

I just gave it a try and everything works well for me. That is, when you insert a SIM card supporting NITZ, you can use the following codes on the Gaia end to retrieve the correct "time.nitz.available" setting value (true):

  var reqTimeAutoAvailable = settings.createLock().get('time.nitz.available');
  reqTimeAutoAvailable.onsuccess = function dt_getStatusSuccess() {
    dump("gene test: gaia: " + reqTimeAutoAvailable.result['time.nitz.available']);
  };

When the SIM card is registered, it can immediately get a NITZ info from the carrier, even before the first page of FTU, which means the "time.nitz.available" can be adjusted to the correct value before starting the FTU process, needless to say the Settings App.

Kaze, may I double check some items with you again please?

1. Does Free Mobile support NITZ? If the "Set automatically" used to work for you, then it must support NITZ, which means "time.nitz.available" must return true to you.

2. Are you sure you're using the latest m-c or b2g18 codes (I know this is a stupid question but just hope to double check)?

If either the answer to the above questions is false, then "time.nitz.available" will return false/null to you as expected.
Flags: needinfo?(kaze)
Target Milestone: --- → B2G C4 (2jan on)
Can you please provide steps to verify this fix - as we will blackbox test from the UI?
Two cases:

1. Install a SIM card supporting NITZ in your FFOS phone. Open Settings App -> Date & Time and then you should be able to see an option for checking "Set automatically".

2. Install a SIM card NOT supporting NITZ in your FFOS phone. Open Settings App -> Date & Time and then you shouldn't see an option for checking "Set automatically". You directly enter the "Set manually" page.

The UI part is designed by :kaze at bug 827764.
Whiteboard: QARegressExclude
No need to create a TC in Moztrap for this defect.
Flags: in-moztrap-
Cannot verify, we do not have access to NITZ/ non-NITZ cards.
Flags: needinfo?(kaze)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: