Clarify bogus NITZ correction logic / correction
This change clarifies some logic used to correct for bogus
NITZ signals.
From looking at a frameworks/base commit
(df7bbfd7c28549742443bbf91200871c09e89299) from 2012
it is possible to better understand the original intent
of some NITZ correction logic due to a (since deleted)
comment.
The comments from the commit mentioned above has
been expanded on to reflect the latest code and reintroduced.
The original comment was:
// "(mZoneOffset == 0) && (mZoneDst == false) &&
// (Arrays.binarySearch(GMT_COUNTRY_CODES, iso) < 0)"
// means that we received a NITZ string telling
// it is in GMT+0 w/ DST time zone
// BUT iso tells is NOT, e.g, a wrong NITZ reporting
// local time w/ 0 offset.
Since the recent commit d8ce837499725b, it has been possible
to tell the difference between "no NITZ data received" and
"offset from UTC is zero". The null case (i.e. when NITZ has
not been received) has been retained with the existing behavior
to avoid modifying the behavior at this time but it looks
(historically, but previously undetectably) incorrect and has
been commented.
There have been some small code-style improvements (addition
of braces and improved logging) made as part of changes to
the affected method.
Bug: 63743683
Bug: 69593701
Test: Boot device
(cherry picked from commit ffeba90625790a34e0c49dfaaed4eeabaa83fdca)
Merged-In: I859c809ba004ff9f1996792e2f813ea081acb9f3
Change-Id: I859c809ba004ff9f1996792e2f813ea081acb9f3
1 file changed