Currently, some controllers in the Date and Time settings page throw exceptions if a capability is not known. This would cause the Settings app to crash, so we are moving away from exception and replacing it with the deactivation of the controller.
Test: manual
Flag: EXEMPT refactor
Bug: 296835792
Change-Id: I56b01ec6d9eebf721deeb4f67aa177742482dd53
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
Design doc: go/dd-android-settings-time-2024
This change covers Part 1, which consists of adding user-friendly summary under each toggle and rewording titles.
Bug: 296835792
Test: on-device and atest
Flag: EXEMPT resource only update
Change-Id: I0b685743599880fc1c4ad680eca9c36e4e64d0ff
Currently, looking for a location containing diacritics (e.g. accents) requires the user to type in exactly those characters. With this change, diacritics are ignored and the strings are returned if they match (using startsWith).
For example, looking for "reun" will show you "Réunion".
Bug: b/364245352
Test: atest tests/robotests/src/com/android/settings/datetime/timezone/BaseTimeZoneAdapterTest.java
Change-Id: I507a9ebc1c830ad3162fb2382814935fc337328d
Flag: EXEMPT bugfix
The summary (i.e. description under the toggle title in Android settings) from AutoTimeZonePreferenceController is only used in wifi-only devices, like Tangor. We have found that since V, the summary was no longer displayed in the Date and time settings page. This fix brings the summary back.
Bug: b/363176828
Test: tested on a Tangor tablet
Flag: EXEMPT bugfix
Change-Id: I1f118b8e1d5e0d8d1b0f5b515d79522b72fb4fa4
Summary: Fix a NPE when trying to set the time zone.
Test: Set the time zone. See it update without crashing.
Change-Id: I01c394f1a682844babc8119c86348b140eeb18ec
Signed-off-by: Abhishek Gadewar <abhishekgadewar@meta.com>
Restore enterprise policy checks removed by commit
fdab44f9e7 and not since restored by other
changes.
Bug: 325886855
Bug: 316584466
Bug: 235445309
Test: Treehugger only
Change-Id: Id3d79805bb2289b84ad34ac05a97e50f0410502f
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
- Time zone should be restricted when "no_config_date_time" enabled
Bug: 316584466
Change-Id: I90dfc2c84ef0b2155740c7b890f17376c9e57e51
Test: manual via TestDPC
SwitchPreference and SwitchPreferenceCompat are both TwoStatePreference.
Using TwoStatePreference in Java will helps migration in the future.
Bug: 306771414
Test: manual - check Settings pages
Change-Id: I84e1d7b09451106797c2b23d127855c6976678ca
Fix a crash due to absence of no-arg fragment constructor.
e.g. if the dialog were shown and the device were rotated, the dialog
could not be restored.
Bug: 272439218
Test: Manual with repro steps before and after
Change-Id: Idca052acff709af132fa72f7919aa71fe8060595
Change the SettingsUI logic slightly: All other things being equal, pick
the "worst" location dependency status to show. Some renaming and
annotations for clarity.
Also fixes the mocking behavior in the tests around resources, which
were accidentally using the real strings and therefore dependent on real
resource string values. Tests are made more explicit.
Bug: 266921482
Test: atest tests/robotests/src/com/android/settings/datetime/LocationProviderStatusPreferenceControllerTest.java
Change-Id: Ifd96c543dad692884be23bf94e3f1294eed291d5
The existing logic and tests looks incorrect. Tests have been tidied up
to reflect real cases. For example, it's not really possible for the
provider to report being "blocked", but for it to report it is "certain"
at the same time.
Bug: 266921482
Test: atest tests/robotests/src/com/android/settings/datetime/LocationProviderStatusPreferenceControllerTest.java
Change-Id: I1a0faa44ed7dd09828ff758db9e40f5d5e010ab0
(Re)Introduce "enabled by admin" / "disabled by admin" SettingsUI state.
ag/18665634 changed behavior: When enterprise policy restricts the
user's ability to change the "auto time" and "auto time zone" toggle,
the toggle was hidden rather than "visible but disabled".
Bug 266693620 demonstrates testers are checking for the behavior.
This commit returns the old behavior for the "auto time" and "auto time
zone" SettingUI behavior, i.e. the user can see the toggle and its
setting value, but is told that it is under admin control and the
current setting value.
See the bug for more info / historic behavior analysis.
Bug: 266693620
Test: Manual testing with TestDPC
Test: atest to confirm existing tests do not fail
Change-Id: I0a605054312547fbd44fc34025ee36b075e05e01
Add the user's "Use location" state to TimeZoneCapabilities. This
information is available anyway and saves the SettingsUI needing to call
LocationManager directly (with the small possibility it would get an
inconsistent answer).
Bug: 262407244
Test: atest tests/robotests/src/com/android/settings/datetime/
Change-Id: I49d4e41b27f9817b3189a7643c24237603e36396
Adding to the Settings UI in order to simplify timezone on non-telephony devices.
Test: on-device testing, additional unit tests
Change-Id: I58ece9542a7b80823092bd082d4bd8c224b29634
Bug: 253015306
To align SearchView x button with right border.
Bug: 254403811
Test: manual,
Settings > Apps > See all apps > tap the search icon >
input something and observe.
Change-Id: I5146c9ffb3c5177926e75f673497408092f6c065
Track method renames:
getSuggestManualTimeZoneCapability() ->
getSetManualTimeZoneCapability()
getSuggestManualTimeCapability() ->
getSetManualTimeCapability()
Assuming that TimeManager.setManualTime() and
TimeManager.setManualTimeZone() become system APIs in the next release,
they can be used in SettingsUI in place of
TimeDetector.suggestManualTime() and
TimeZoneDetector.suggestManualTimeZone() (in a later commit).
Bug: 236612872
Test: build only
Change-Id: Ifffc022c109fa68ae705e32400db9bfc8a1632ca
- Settings header is restricted scrolling by this ag/15029686
- To void some pages can't show the contain part while heading unscrolling.
We allow the header can be scrolling in the landscape mode.
Fixes: 207353353
Test: make RunSettingsRoboTests -j
Change-Id: Ice97c6244716d4768167feb78588807d13b06a94
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
- "Set time zone automatically" changes to "Set automatically".
- "Use location to set time zone" changes to "Use location"
- Add a new summary text with "Location may be used to set time zone".
Fixes: 233968737
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.datetime
Change-Id: Ia16c428e906cda4ebe052bad83c3f574075a7a64
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
Additional fix:
1. Fixed the SpannableUtil.getResourcesText to actually
preserve Spannable (TtsSpan in this use case) during formatting.
Bug: 185453652
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Change-Id: Iae5e1d4261ec0a34222ae1d042c7f3f027f2e512
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
(cherry picked from commit 7a8ac683d4)
Capitalize Settings UI time zone display name strings for languanges
like Polish for standalone locations like summaries and lists. The
motivating example case is the string for "Coordinated Universal Time"
in Polish, which is not capitalized in CLDR, as they capitalize for the
middle of sentences by default. In English, Coordinated Universal Time
is already capitalized, but the Polish string is not.
With this commit all "display name"-like strings have been capitalized
(region names, exemplar locations, time zone names like
"Coordinated Universal Time" and "British Summer Time") for
completeness. For the Polish case, many are already capitalized, but
capitalizing the first letter is therefore a no-op. The
"GMT+xx:xx"-style strings have not been changed.
Bug: 190109975
Test: Visual inspection in English and Polish of UTC, United States,
Russia in the time zone picker and the date & time screen on mobile
Change-Id: I57d915ac1e30e22cc05e605fcb7d46b102fa8ce1
The time zone transitions can be obtained via the public API
ZoneId.getRules() instead.
Bug: 119751170
Test: atest SettingsRoboTests
com.android.settings.datetime.timezone.TimeZoneInfoPreferenceControllerTest passes
Change-Id: I2c7864580b2a36b725ee250253e97f6cc86d72a4
As title, we do not allow user can scroll app bar while
the search menu is expanding.
So, we can ignore all drag events on app bar.
Test: Can not scroll on the app bar area
Fix: 181741353
Change-Id: I20c0b69059cdc4d13a15abd810a725d4591f6396
Collapse the tool bar when we're doing search for
a better user experience.
And we don't allow user can expand the tool bar at this moment
since it will see a large space at this moment.
Fix: 181741353
Test: Open the page and don't see a huge space now.
Change-Id: Iec5ebe9b22a2aad15dc8cf90113a64c358ee447e
