| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Depends-On: I5b1dccb5d103ece3112acf38889bae16273b092f
Change-Id: I116aed2bb805f723a5bf2ec9eb94257de0b4a7b5
|
|
|
|
|
|
|
|
| |
on/off switch
Per UX request, convert more CheckBoxes to Switches
Change-Id: I04712bce4c0a54516d9ecedbb554f403fd6dd9e7
|
|
|
|
|
| |
Bug: 17389920
Change-Id: I5c5bdacd863f84c503e7a16dc611feda36bc462f
|
|
|
|
|
|
|
| |
The PIN prompt would reappear if the pin screen had been rotated 90
degrees before a user hit cancel/ok.
Change-Id: Ia5f93aa7a857d46ba95775c85344fa9ff28a4a6b
|
|
|
|
|
|
| |
Bug: 15305103
Change-Id: Ib0147e366fe90de3512d0cc06e2a47ee16012dff
|
|
|
|
|
| |
Bug: 10461761
Change-Id: If63c3801663b347a4643e44d5bd3bab4e3049578
|
|
|
|
|
|
|
|
|
| |
- 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
|