Fix the logic used that determines whether the automatic time
zone detection toggle is available in the Settings UI Date & Time
screen. Also, ensure that the TimeZonePreferenceController uses correct
logic for whether the user can manually enter a time zone.
This change migrates the controllers to use a existing high-level
TimeManager API rather than (incorrectly) duplicating in Settings UI the
logic for whether time zone detection is supported / enabled.
Without this change, WiFi-only devices _with_ location-based time zone
detection enabled would incorrectly hide the "auto time zone" toggle,
which would have the knock-on of making it look like the user is allowed
to enter a time zone manually when they aren't (because it is
enabled/disabled based on the presence of the toggle).
That toggle still needs to be present while there is a possible time
zone detection mechanism. All the (quite complex) logic around this is
already considered by the TimeManager API.
Possible side effects:
This change decouples the "does the toggle show true or false?"
(isEnabled()) from the "should the toggle be shown at all?"
(isAvailable()) logic by removing a call to isAvailable() inside of
isEnabled(). This is to avoid making multiple (probably more expensive
than what it was doing before) calls to the time_zone_detector service,
and avoid the extra complexity of caching / cache invalidation that
would be needed to mitigate it. Previously, as a result of the call to
isAvailable(), isEnabled() would always return false when mIsFromSUW is
true, but now it will return the underlying value of the device's
auto_time_zone setting. This means that if the UI is changed in future
to render a visible-but-can't-be-changed-by-the-user toggle for auto
time zone, it will display the current setting value, which is perfectly
reasonable. It is assumed it will have no other side effects.
The AutoTimeZonePreferenceControllerTest.isFromSUW_notEnable test has
been changed to reflect the change in behavior. Various name changes
made to tests to reflect the new behavior.
Bug: 228247623
Bug: 186625820
Bug: 172891783
Test: treehugger
Test: Manual test on a device with telephony
Test: m ROBOTEST_FILTER=AutoTimeZonePreferenceControllerTest RunSettingsRoboTests -j40
Test: m ROBOTEST_FILTER=TimeZonePreferenceControllerTest RunSettingsRoboTests -j40
Change-Id: I4c7608e8645eee5994c8ecf85a14a27d3278ac04
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
When auto time zone preference is not available, it should be considered
disabled, so that user can still select time zone.
Change-Id: I9b17205a11ff512da02694e3bce06cfbd21dd7db
Fix: 34203177
Test: make RunSettingsRoboTests
