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
(cherry picked from commit 5d80553a15)
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
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
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
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Test: m -j RunSettingsRoboTests
runtest -x packages/apps/Settings/tests/unit/src/com/android/settings/core/UserRestrictionTest.java
Fix: 67497909
After turn on the user restriction in TestDPC:
https://hsv.googleplex.com/5414119658225664
The date time settings page become:
https://hsv.googleplex.com/5199302573948928
Change-Id: I42590c4a505ec1b6ffa86eb460b90fa6ec8ba783
