This is made necessary by changes to the SystemAPI the lib relies on.
Test: RunSettingsRoboTests
Bug: 116798569
Change-Id: I2812ce9e58e3fb15a5579ddc10cd0edf33d0ed44
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
The dialog for a setting being restricted was showing even when the
password was being entered correctly. This CL makes it so that
if the password is correctly entered we dismiss the dialog if it
is up.
Test: robotests
Bug: 77722622
Change-Id: Ifc82bc1e5800afff2a0883a13bf316f84169d80d
RestrictedDashboardFragment has all the same logic coming from
RestrcitedSettingsFragment but extends from DashboardFragment.
As a result, we could use preferenceController in child class of
RestrictedDashboardFragment.
This cl also make DeviceListPreferenceFragment as child of
RestrictedDashboardFragment, which enfluences the bluetooth page.
Bug: 38041586
Test: Build
Change-Id: I01395d506176c5cc584948478f7ca16c1c7c7045
Removed the left-alignment on restricted empty views which was
inherited from Bluetooth settings but inconsistent with normal
settings fragments.
Bug: 22685111
Change-Id: I3a36c47d523392b8925031d4cac2ab3ef681e360
The PIN prompt would reappear if the pin screen had been rotated 90
degrees before a user hit cancel/ok.
Change-Id: Ia5f93aa7a857d46ba95775c85344fa9ff28a4a6b
- Reprompt for pin after screen has been locked and unlocked.
- For protected preferences, store the Preference and continue if pin entry is successful.
- Protect whole UserSettings and DevelopmentSettings pages.
Bug: 10543207
Change-Id: If1d4b31ca94a8cfc103625b74385bcd0bdd3d88b
Fixed bug in WirelessSettings where it was asking users for a PIN when
they weren't restricted. Did this by refactoring the preference level
pin checking into the superclass, where it checks for the restricted mode first.
Also pin protected changes to certificates for restricted users.
Change-Id: I8310fd39f0862159668318fc1360ec6859cc00d5
When these screens are locked down with user restrictions,
it should prompt the user for the restrictions pin before allowing
access to the settings screen.
Change-Id: Iadbb087da2d9470b855ea0bea89f2da1ffb9e854
Creates an easy way to ask for the restriction pin before
allowing access to a settings page. Does this to the WiFiSettings.
Change-Id: I49734f66e09b6449596412ecf6fc1113bf57ce7f
