Design doc: go/dd-android-settings-time-2024
Changes:
- toggling off "automatic time zone" now sets "use location" off and makes it unmodifiable
- removing "use locale default" for time format
Bug: 296835792
Test: on-device and atest
Flag: com.android.settings.flags.revamp_toggles
Change-Id: I31744f104fed06ee9980a6a0160501325175a02d
The feature is behind a release flag. It is also behind an experiment
flag so it can be trialed with Googlers before general release even
after being enabled in a release.
The feedback button only shows up if there is an intent URI configured,
which should be handled via an overlay. The design means that the intent
is potentially dependent on the manufacturer (good!), though I expect we
will suggest a standard one for GMS devices so we get feedback from a
variety of devices with different form factors / capabilities.
In this default, GMS core (Google Play Services) will handle the intent
and take the user through a feedback UI flow.
Testing:
To enable the button you need to build with one of release variants that
supports dynamic flags, e.g. trunk_food.
Then release flag:
$ adb shell device_config put location com.android.settings.flags.datetime_feedback true
It still won't work without the experiment flag:
$ adb shell device_config put settings_ui time_help_and_feedback_feature_supported true
Finally, the settings entry will launch an intent when pressed which has
to have a receiver. The receiver will be in GMS core but will be subject
to its own review / launch process. Until then, this feature will remain
quiet, biding its time.
Bug: 283239837
Test: Manual (see above)
Test: atest SettingsRoboTests:com.android.settings.datetime
Change-Id: I68798798fc0a47ae4c6755174ce509fbaee24142
This commit moves knowledge of the upper / lower bounds for valid manual
date suggestions to (internal) API calls.
It adds a test to confirm the API calls are used to configure the date
dialog.
Further, it removes redundant filtering from the client that would
prevent suggestion calls being made if the settings UI considers them
invalid. Year bounds are already used to limit the UI entry, and the
system server will return false from the service call if the suggestion
is invalid, though the SettingsUI doesn't do anything (behaviorally)
with the false before or after this change. After this change it is
logged.
The goal of this change is to allow users with devices that don't have
the Y2038 issue to enter dates > 2037. This could have been done with
a smaller change, but the use of the new internal class
TimeDetectorHelper means that the bounds logic is in one place. The
lower bound (on mobile devices) can now be changed relatively easily by
touching one class.
Bug: 228967927
Test: m RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime"
Change-Id: Iaf1ca8220e0e96773aa71b595da9c1ba1e50d59d
Switch auto time setting to use TimeManager APIs instead of low-level
direct settings access.
This makes the AutoTimePreferenceController approach the same as
AutoTimeZonePreferenceController. Most of the logic about what to
display and whether toggles are enabled is moved to the service.
This change has the side effect of adding support in SettingsUI for
devices with no auto time detection mechanism configured at all, i.e.
the auto time toggle will stop being shown in SettingsUI. There are no
known devices that require this currently, but it is a theoretical
possibility if config.xml is configured in particular ways.
Bug: 172891783
Test: Manual testing with different settings for "time origin
priorities" (i.e. empty, non-empty)
Test: m ROBOTEST_FILTER=com.android.settings.datetime RunSettingsRoboTests -j40
Change-Id: I4112fb51adb0d06a1dbc39a44ea109d6df899153
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
As of now GeoTZ state remains unchanged even if user enables
Location toggle.
Bug: 152746236
Test: m -j30 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime.LocationTimeZoneDetectionPreferenceControllerTest"
Test: checked manually that dialog opens Location settings page
Change-Id: I5fd3288e9d5a7aac3bc82da6944b4ccd6bb9e0f5
- It can improve performance because we use less injected item
- Also remove summary provider from those fragments
Bug: 141653158
Test: robolectric
Change-Id: I6255f71b3b8300aea064a4fefd6711c1ff59e08a
