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
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
TimeZoneCapabilitiesAndConfig has a new constructor argument.
Bug: 236624675
Test: m SettingsRoboTests
Test: m RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime"
Change-Id: I2b6178809ca09f280b3a22a4696b8f2575b3f703
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
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)
It also makes setting in line with "Set time zone
automatically", which is rendered w/o toggle on search page.
Bug: 185906072
Test: manually verified that toggle is not shown
Test: m -j30 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime.LocationTimeZoneDetectionPreferenceControllerTest"
Change-Id: Ie71572c4a9b9bd6adf3660556363331e2943fd5b
If America/Godthab is set as device time zone, display it as if
America/Nuuk is chosen.
If time zone is known, but is not an alternative and not shown
in time zone picker, region will de derived from user's locale.
Bug: 155738410
Test: atest com.android.settings.datetime.timezone.model
Test: set persist.sys.timezone via adb and checked
Date & Time screen
Change-Id: I168fb4319e144dbe9e2496d06a681d4c09b411c0
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
The correct target context should use the mActivity in
MobileNetworkSettingsTest, so that the mocking for
telephony service could correctly applied.
Both AutoTimeZonePreferenceControllerTest and
BasebandVersionPreferenceControllerTest refer to the lib
implemented shadow Connectivitymanager but that does not
the correct reference after utils class being updated.
Update the test logic inside to refer to correct method.
The reference to ShadowConnectivityManager does not needed
anymore so remove it from the test.
Fix: 183068151
Fix: 183067742
Fix: 183068139
Test: make RunSettingsRoboTests ROBOTEST_FILTER=\
com.android.settings.network.telephony.MobileNetworkSettingsTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=\
com.android.settings.datetime.AutoTimeZonePreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings\
.deviceinfo.firmwareversion.BasebandVersionPreferenceControllerTest
Change-Id: I15ecc6aab7d530d20cd23b06267cc184a2c62b40
Capabilities are extracted to separate class to reuse them
in time API.
Bug: 172891783
Test: m -j30 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime.LocationTimeZoneDetectionPreferenceControllerTest"
Change-Id: If7351c4f022c69262ddffd26efacd449dc7238c5
Previous sub-menu is deleted.
Toggle is always enabled and shows current configuration
setting. If MLS or auto time zone detection is off,
the toggle has not effect.
Bug: 152746236
Test: toggled and checked dumpsys time_zone_detector
Test: checked summary info on different MLS/set time zone automatically
states combinations
Test: m -j30 RunSettingsRoboTests
ROBOTEST_FILTER="com.android.settings.datetime.LocationTimeZoneDetectionPreferenceControllerTest"
Change-Id: I75ee41cfcaaf34b1b63e18809be4cd614446017d
Merged-In: I75ee41cfcaaf34b1b63e18809be4cd614446017d
This change do the 2 things:
1. Add new junit tests files which replace robolectric
RobolectricTestRunner & RuntimeEnvironment with
AndroidX objects without problem.
2. Remove the robolectric test files which have it's new junit files.
This change migrate 103 files, there are still 1209
files to go.
Bug: 174728471
Test: atest
make RunSettingsRoboTests
Change-Id: I15ed3f4745b85862f720aabbf710ce1475aced93
Move the Location time zone detection setting to Date & Time as per
UI review / product request.
This initial commit just moves the existing MVP setting behavior to a
different screen. Still invisible by default.
Enable with:
$ adb shell setprop persist.sys.location_time_zone_detection_feature_enabled 1
.. plus a reboot.
Bug: 152746236
Test: Manual: build / boot / toggle switch in SettingsUI / inspect output of adb shell dumpsys time_zone_detector
Test: m -j30 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime.LocationTimeZoneDetectionPreferenceControllerTest"
Test: m -j30 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime.locationtimezone.TimeZoneDetectionTogglePreferenceControllerTest"
Test: m -j30 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.datetime.locationtimezone.TimeZoneDetectionSettingsTest"
Change-Id: I9ecfa853014a9f92086a9cb2d34e1517474ceb93
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Merged-In: I76f9c37cb699ce6ab8715ffe35d11668ccbceea1
Change-Id: I76f9c37cb699ce6ab8715ffe35d11668ccbceea1
(cherry picked from commit 46e85a2fad)
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Change-Id: I76f9c37cb699ce6ab8715ffe35d11668ccbceea1
This commit tracks changes in libcore to extend the IDs recognized
to be associated with a country.
Bug: 155738410
Test: treehugger
Change-Id: I0d75b6c41cdce4a373f73761ccd2d7db357d6548
Switch settings to use TimeDetector when setting the system clock rather
than using AlarmManager directly.
Bug: 140712361
Test: treehugger
Test: manual
Test: make -j30 RunSettingsRoboTests ROBOTEST_FILTER=TimePreferenceControllerTest
Test: make -j30 RunSettingsRoboTests ROBOTEST_FILTER=DatePreferenceControllerTest
Change-Id: I671bf0e7e7364f64f1397d524c6277591eb4e22e
Merged-In: I671bf0e7e7364f64f1397d524c6277591eb4e22e
(cherry picked from commit 9861696306)
Switch settings to use TimeDetector when setting the system clock rather
than using AlarmManager directly.
Bug: 140712361
Test: treehugger
Test: manual
Test: make -j30 RunSettingsRoboTests ROBOTEST_FILTER=TimePreferenceControllerTest
Test: make -j30 RunSettingsRoboTests ROBOTEST_FILTER=DatePreferenceControllerTest
Change-Id: I671bf0e7e7364f64f1397d524c6277591eb4e22e
We don't rely on FooterPreferenceMixinCompat
to create footer preference in dashboard fragment.
Instead, declare a FooterPreference explicitly in
xml of screen.
It makes more sense for our referenceController design.
Test: visual, robotest
Bug: 124129485
Change-Id: I0b0c0f9e38d85aa89b815ce2b84ddff30a1d206b
The resources available to tests are now exactly the merged resources
located in the APK under test.
Bug: 74359828
Test: make -j56 RunSettingsRoboTests
Change-Id: I050db81a92decefea23314b5ec7a62f77ff4bb2b
Some time zone related libcore classes are moving from
libcore.util to libcore.timezone.
Bug: 119026403
Test: build only
Change-Id: I920411dfa7e000a0da9678826a035e0461211619
We directly use Robolectric/ActivityController to
setup an FragmentActivity lifecycle.
So, I removed the custom Robolectric in robotests/testutils.
Change-Id: Ib93265f719e1eb9606c9ad6f05c1dd1957302e8b
Fixes: 111195450
Test: robotests
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Fix all Roboletric test cases.
In this CL, some test cases are broken.
So, We ignored these test cases temporarily.
Test: make RunSettingsRoboTests -j56
Bug: 110259478
Change-Id: I1a3075438a614432a2de4f2d96d8abf9a83ce58c
Created b/77277084 to help Android variants to migrate from
old time zone data source, i.e. ZoneGetter.getZonesList, to
new time zone source, e.g. TimeZoneFinder.
Bug: 72376227
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime
Test: manual
Change-Id: I332077a67cc9f9c83b298e25feea71463e1ee98b
The codes are unused due to the UX changes in b/73952488
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Bug: 72376227
Change-Id: I9562e97fe13a3c00f8c142f30af7ca350af10757
- android.icu.impl.TimeZoneAdapter doesn't fully implement
java.util.TimeZone, e.g. does not override getOffset(long date).
TimeZoneAdapter isn't a public API in ICU/Android. It shouldn't be
used in the first place
Bug: 77223510
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Change-Id: Ic0d7794326948796dcc5cc0b268ef634a74803c4
Extra fixes in this CL
- Minor string update in time zone picker.
Use date_time_search_region string in search bar,
and date_time_set_timezone_title string for lower case "zone".
- Fixed b/76893139. Remove the unnecessary top padding in RecyclerView.
Create a new layout file time_zone_items_list.xml without the padding.
- Add missing return statement when region ISO code
is invalid in RegionZonePicker#getAllTimeZoneInfos
Bug: 76209571
Bug: 76893139
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Test: Verified that the strings are updated in the UI
Change-Id: I1fb3e2abf80da3cb53cfbc3363bbe46e40a6ac22
- Can't reproduce the race condition with manual test, probably the view
updates are fast enough that only monkey test can reproduce the issue.
- Reproduced a similar stacktrace and IndexOutOfBoundsException with
Robolectric test by assuming that the race condition happens after
text filtering and view updates. Try to fix the bug with this assumption
- The fix is to bind the data (data position in adapter) with ViewHolder.
Bug: 75322108
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Change-Id: Ie5d932bce30590b8067e042c3380911c9608872f
