"Show password" will be moved in Settings > Privacy.
Since each of things should only exist in one place,
we remove it in Security page.
Test: visual
Bug: 116628158
Change-Id: I9f9083b88d7a20faa9bd28ded2cf8c3b9a5622fd
- Create some location icons for different scenario.
- Remove Location in Security page.
- Move Location Setting to top level page.
Test: robotest, visual
Bug: 116628158
Change-Id: I3f57ef49a396877bfbeaefea7dc4f4051e0ccc65
- Condition is already supported in PersonalSettingsFragment
- Suggestion is already supported in PersonalSettingsFragment
- Static/dynamic tiles are supported in TopLevelSettings
Change-Id: I51882e3bd0919ad95109baefac683d98667c11e3
Fixes: 110405144
Test: robotests
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
Test: make -j RunSettingsRoboTests
Test: manual, unify when profile lock is compliant
Test: manual, unify when profile lock is not compliant
Test: manual, unify when profile lock is empty
Fixes: 110262879
Change-Id: I0dfa885f2a0e44e09c217b3e7766b367f1340c9e
This change refactors common biometric settings code as well to minimize
duplicated code in areas such as:
Preference Controller
EnrollBase
EnrollIntro
This change also updates ChooseLock to have Face + Pin/Pattern/Pass
Bug: 110589286
Test: Fingerprint settings/enrollment still works
Test: make -j56 RunSettingsRoboTests
Change-Id: Ie35406a01b85617423beece42683ac086e9bc4a7
Bug: 110589286
Test: make -j56 RunSettingsRoboTests
Test: adb shell am start -a android.settings.FINGERPRINT_ENROLL still works
Test: adb shell am start -a android.settings.FINGERPRINT_SETUP still works
Change-Id: If33b557137cae7b57e4a0e906ee95032bc589436
And remove the entry point from security page. Now we only have 1 entry
point from Display page.
Change-Id: I06bc15a6fd8802a4918d8772af2722d5aafa332e
Fixes: 71892510
Test: robotests
getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
To getPreferenceControllers. "all" is redundant. Then internally, the
old getPreferenceControllers() is renamed to
createPreferenceControllers() to emphasize the controllers are created
from code (versus the ones created from xml).
Bug: 73668763
Test: robotest
Change-Id: Ifec46aefdc2a418031c8e152028b30bdcd396fc7
This way when everything is hidden in security, the whole category is
hidden also.
Bug: None
Test: Robotests
Change-Id: Ib4120975133df7910c5d5229a82d4052364501ac
And create PreferenceControllers for each setting
The page is still pretty janky and controllers are invoked manually.
Next CL will clean these up.
Bug: 32953042
Test: TODO
Change-Id: I1d7478324f5de4fdb464d79f89086f7e79c0ee67
This is a clean up to action bar menu item pattern, we will use the same
pattern to build search icon on all pages in a later change.
Bug: 68814716
Test: robotests
Change-Id: Iedd3ec263e8ccb63ed75ec7a95b28c00878b1de4
- This class is over complex to use, and get in the way of show/hide
pref when availability change.
- The function from DynamicAvailabilityPreferenceController can be done
with PreferenceCategoryController.
Bug: 68956750
Bug: 32953042
Test: robotests
Change-Id: Ia7b7e214c072b8c77f5de3d959fdb1dc79217f76
