am: 890b5c416d -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: I9b09434020a9626958e766d77ebf47005bf8cd41
am: 9f395fd0a9 -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: I113a7b6214ce73864b6d9437eaabafb1063c69ee
am: 32a9b548e3 -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: Iebd57656a9456105f13a8d9de44ded0a4f1e29df
am: c919df9edb -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: I11ceedfa9003dd22ef6dcd23ad618241f9925aec
am: 587d8d7005 -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: I14cf7941c761c973d6c9297d366c213aeae4cbcf
am: 587d8d7005 -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: I2ed1d97f1fa5104e1c381babc2625cb69b147b6c
am: 1c1191b640 -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: I662181a2cfd7b05c9929b868e2b76895f407678c
am: 49c7d07650 -s ours
am skip reason: change_id I6521e896d0402fe856dc85476f51149c9b3084a8 with SHA1 0a33d62a17 is in history
Change-Id: If5e6d4c715b0c3482f297c709320e2ca9f6fa209
If user enters face settings but does not enter the password, then
turns off the screen, it's possible the challenge is invalidated. Instead,
we should finish() the device credential screen as well as FaceSettings.
This prevents
1) The user from being prompted for credential with lack of context
2) Credential returning a HAT that wraps an invalidated challenge
The user will be returned to the security settings screen, where they
have more context and can decide if they want to enter face settings again.
Fixes: 138273242
Test: 1) Open face settings, do not enter password
2) Press power button
3) Unlock keyguard
4) User is not presented with credential screen
Test: Go through SUW, turning on/off the screen at various security
screens. Able to enroll successfully
Change-Id: I3c3d4600138012821bb0eea7d2927df00011cdb0
And a hidden preference category. This makes
hiding/showing the list a lot cleaner and also allows more
of the code to be tested.
Also delete some unused code that no longer complied after
this refactor.
Fixes: 133443871
Test: atest
Change-Id: I4a5fe0e075019bae2df44a0a9dcec26a40ee6d12
(cherry picked from commit a295d71c94)
Currently we always send cancel() if ConfirmDeviceCredentialActivity
goes into the background. However, if the biometric state is no longer
authenticating, requesting cancel() in this state will result in an
inconsistent state between BiometricService/client and
ConfirmDeviceCredentials.
BiometricService/client will receive the ERROR_CANCELED message incorrectly,
while ConfirmDeviceCredential is showing / pending user password. When
the password is entered, its result is ignored.
The correct behavior is for ConfirmDeviceCredentialActivity to invoke
cancel() only if it's still authenticating. Otherwise BiometricService
and its client will receive ERROR_CANCELED, instead of the actual password
auth result.
Bug: 138279856
Test: BiometricPromptDemo, enable device credential fallback, get into
lockout state, successfully enter password. API result is
success instead of "canceled" now.
Change-Id: I6521e896d0402fe856dc85476f51149c9b3084a8
Merged-In: I6521e896d0402fe856dc85476f51149c9b3084a8
In general the mobile network details page has several preference
controllers that don't listen to carrier config changes, so instead of
having each one add a listener, we instead just have one listener and
refresh the entire page when we see the broadcast.
Fixes: 135587885
Test: make RunSettingsRoboTests
Change-Id: Iff5b28dbfe12d94c901b442b23cece8e68218983
Currently we always send cancel() if ConfirmDeviceCredentialActivity
goes into the background. However, if the biometric state is no longer
authenticating, requesting cancel() in this state will result in an
inconsistent state between BiometricService/client and
ConfirmDeviceCredentials.
BiometricService/client will receive the ERROR_CANCELED message incorrectly,
while ConfirmDeviceCredential is showing / pending user password. When
the password is entered, its result is ignored.
The correct behavior is for ConfirmDeviceCredentialActivity to invoke
cancel() only if it's still authenticating. Otherwise BiometricService
and its client will receive ERROR_CANCELED, instead of the actual password
auth result.
Bug: 138279856
Test: BiometricPromptDemo, enable device credential fallback, get into
lockout state, successfully enter password. API result is
success instead of "canceled" now.
Change-Id: I6521e896d0402fe856dc85476f51149c9b3084a8
"Ambient display" was merged into "Lock screen display", and the entry
was also moved from security page to display page and leveraged the
original user restriction of "Ambient display".
The user restriction should just work on the switch of Ambient display
instead of the "Lock screen display" entry.
Bug: 138177691
Test: robotest, visual
Change-Id: I5db0eb68c3aa6f4f7d8ecd42db2cdc72255b12f7
Refine code:
1. Change method name from getSpinnerAdapterWithEapMethods to getSpinnerAdapter
and apply it to other Spinner adapters.
2. Change method name from getSpinnerArrayWithEapMethodsTts to
getSpinnerAdapterWithEapMethodsTts and it will
setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item)
for adapters.
3. Remove the code of ag/8693033
4. Improve indentation.
Bug: 135127581
Test: WifiConfigControllerTest
Change-Id: I653eda11ca1b8235c5ecaa1a826a2fddd004d2e1
1. Only support EAP-TLS for WPA3-Enterprise 192-bit
2. Remove "Do not validate" from the CA certificate menu
3. Remove "Do not provide" from user certificate menu
To reduce review effort, I left refine code change in another CL.
Bug: 135127581
Test: WifiConfigControllerTest
Change-Id: Ibf904da9407ec803afb8bb995e9df1a2e25f0dcb
