- This covers app data usage settings, power usage details
- Addded helper method on AppHeaderController to build the header as
Preference because every fragment needs to do this anyway.
Bug: 32442716
Test: RunSettingsRoboTests
Change-Id: I6d38321b867154f8fb5194b993d118bcdbbfedc9
- The AppHeaderController is no longer a singleton. Each time appheader
should be updated we will create a new controller. It acts as a
builder/mutator, user provides customizable inputs, and the controller
will bind everything to UI when calling done().
Bug: 32442716
Test: RunSettingsRoboTests
Change-Id: Icfc5bcd8bc170a02b57432d864eaddf71db0d5b4
Add two items to User & accounts dashboard, and refractor
UserCapabilities so that it can be accessed in the new controller.
Test: RunSettingsRoboTests
Bug: 31801423
Change-Id: Ib446ad6c99d4cc6405a17cf82d2d86e044870b73
- moved force stop and uninstall button to bottom of page (as footer)
- Forked appheader layout file, and created AppHeaderController to
contain all binding logic for header.
Bug: 32442716
Test: RunSettingsRoboTests
Change-Id: Id4eb365ca25e035c043c068867f5cbc3a202b201
Only display the WifiInfo MAC address if it is a valid address.
Otherwise, display "Unavailable". The underlying WifiInfo class
now has a default value, and a method that can be used to test
whether or not the contained address is valid. This change uses
this test and avoids having the confusing default address displayed.
Bug: 32478606
Test: Manual: Turn off WiFi and reboot -- make sure "Unavailable"
is displayed as the Wi-Fi MAC Address as opposed to "02:00:00:00:00:00"
Change-Id: I912804eb65735375e0ca3c4618a6399543f33b57
If permission review is enabled toggling bluetoth on or off
results in a user prompt to collect consent. This applies
only to legacy apps, i.e. ones that don't support runtime
permissions as they target SDK 22.
bug:28715749
Change-Id: I5ae0c532c92b2c05a91f0d769ca6744002747fca
(cherry picked from commit b06766f129)
Created some tests to protect some basic bluetooth
pairing dialogs features from regressing. Most of the
tests in this CL ensure that the view is properly
created and that it is properly updating the
associated controller when a relevant action occurs.
Test: make RunSettingsRoboTests
Bug: 32180625
Change-Id: I2f4103a39ffced52353712f952e8ff3d26590169
When updating preferences managed through PreferenceController, the
fragment should skip prefs that are not available.
Bug: 32255863
Test: RunSettingsRoboTests
Change-Id: I2f9b6ddf8c78d40068dc18f07e60672dcba4474a
- Use PreferenceController structure to make things more modular and
testable
- Add tests
- Confirm password before enabling dev settings.
Bug: 24107771
Test: RunSettingsRoboTests
Change-Id: I791d9452fd461f570e70e7428f00a7258663de4b
+ This is caused by the encryption interstitial result code not handled
in ChooseLockGeneric. Change the request code of launching encryption
interstitial screen to CHOOSE_LOCK_BEFORE_FINGERPRINT_REQUEST if it
is set new password flow.
Testing
Test: See below
1) Auto
make RunSettingsRoboTests
2) Manual
On a device (Nexus 5x) that shows encryption interstital screen and
supports fingerprint.
1) Nexus imprint flow (regression test)
Fingerprint can be enrolled with the following flow.
Settings > Security > Nexus Imprint > FingerprintEnrollIntroduction
> ChooseLockGeneric (Unlock selection) > Encryption Interstitial
> Password setup > Notification Interstitial
> Find sensor and fingerprint enrollment
2) Set new password test
i) $ adb shell am start -a android.app.action.SET_NEW_PASSWORD
ii) Click Nexus Imprint + Pattern.
iii) Choose "Require pattern to start device"
iv) Set a pattern lock.
v) Choose any of the notification behavior.
vi) Can enroll a fingerprint.
Bug: 32382952
Change-Id: Ie66ffca2e8c3cc46b5e8b619bd35986e4f41d5ab
This allows us to get rid of an extraneous config switch and
simplify some code.
Test: Manually change usb configuration
Change-Id: Id78da530ff485ecd7a915056832eec1dd8c91954
(cherry picked from commit 5d36a177d9)
