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
