Currently the only way mUserPassword can be set is when it comes
from onActivityResult. This way when the user chooses "Continue
without Pixel Imprint", and we switch ChooseLockGeneric->InternalActivity,
mUserPassword becomes null (it is not preserved in intent extras).
And then this null is used in getLockPasswordIntent which causes the issue.
Another issues is that when the user chooses to use fingerprint,
mHasChallenge is set to true and password is not forwarded to
ChooseLock(Password|Pattern). I changed the intent builders so that both
old password and challenge can be sent at the same time, so the password
is not lost when fingerprint is set.
Bug: 67672081
Test: cd packages/apps/Settings/tests/robotests/ && mma
Test: manual, adb shell am start -a android.app.action.SET_NEW_PASSWORD,
tried setting pin/password with and without fingerprint.
Test: manual, tried to change lock via Settings -> Security&Location
Test: manual, set pin + fingerprint in Setup Wizard, FBE and FDE devices
Test: manual, set pin + added account, used pin to unlock FRP in SUW
Change-Id: I38d56d84f95c63fef24c2aa1a031d629f22756a1
- Lazy load the SettingsObserver in StayAwakePreferenceController
so that search indexing works properly
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: I1e2afb106ce293f616143da3f37fbde3829f414f
- Fixes a bug where developer options would be re-enabled
if the activity is destroyed when the master switch is set to
off
Bug: 34203528
Test: Manual testing with screen rotation
Change-Id: Ic8e04858f6e3dd2353feb6fa94be9f420ab8adbb
Pull the notification and alarm ringtone out of the preference category
and update the tile limit to 1, so that only the first preference
category will be displayed initially.
Change-Id: I9ae7669fb2b688560a3fc228274ea44f225b262f
Fixes: 67750626
Test: visual
- Refactor BluetoothAudioSampleRatePreferenceController into
AbstractBluetoothA2dpPreferenceController
- Make it easier to implement future bluetooth a2dp preferences
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: Ie94273c2b97504f4fb63f11b1afc21abc6944ffb
- Create new FreeformWindowsPreferenceController
- Create controller inside the DashboardFragment
- Port logic from DevelopmentSettings into the controller
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: I3ce3731a2aa37833c635e5bdaaf452491b2dadb5
- Create new BackgroundProcessLimitPreferenceController
- Create controller inside the DashboardFragment
- Port logic from DevelopmentSettings into the controller
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: Ie151f911917ecf9401df8f3daa6f10770b7a571e
- Create new ProfileGpuRenderingPreferenceController
- Create controller inside the DashboardFragment
- Port logic from DevelopmentSettings into the controller
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: Ic88396a32fdc5564bfa73a3c1daf4fdef0e09c9f
- Create new SetGpuRendererPreferenceController
- Create controller inside the DashboardFragment
- Port logic from DevelopmentSettings into the controller
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: I9f7f944598b2dcd04231c5cf58d83c0ef7e17f04
- Create new DebugNonRectClipOperationsPreferenceController
- Create controller inside the DashboardFragment
- Port logic from DevelopmentSettings into the controller
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: I34349308819054bdd5256058f2de4f76a71f4677
- Create new SecondaryDisplaysPreferenceController
- Create controller inside the DashboardFragment
- Port logic from DevelopmentSettings into the controller
Bug: 34203528
Test: make RunSettingsRoboTests -j40
Change-Id: Ib1a7164b4e8fcf9ae8af96290d2baa33e25648f7
getContext().getDisplay().isWideColorGamut() does not check system
support of wide-color. That's window.isWideColor().
No window object handy so call isScreenWideColorGamut() to
verify system support for wide-color as well.
Bug: 64801219
Bug: 67488442
Test: manual, check Developer Settings for Color Mode
option on Pixel or Pixel XL.
Change-Id: If28e52da174dd460850bc84744818979f52add78
