Some info is still helpful for debugging in these cases.
Bug: 139074613
Test: manual
Change-Id: Idbde691c60b53e0ab755df229a3a9dc77406934d
Merged-In: Idbde691c60b53e0ab755df229a3a9dc77406934d
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
(cherry picked from commit 49c7d07650)
The last private DNS settings screen landed in P after string
freeze, which led us to reuse R.string.switch_on_text for the
"on" text when private DNS is active. That string comes from
notifications. Private DNS should have its own string for this
instead.
Bug: 79122154
Test: 1. Build pass
2. make -j44 RunSettingsRoboTests \
ROBOTEST_FILTER=PrivateDnsPreferenceControllerTest
Change-Id: Ie013a858c8bc41e00a1b940d02efa2b605991685
Doing a factory data reset used to always erase eSIMs. Then a few months
ago we added a default-on checkbox to let users opt out of erasing the
eSIM during this process, but only had it show for some devices (ones
which support the "fastboot oem esim_erase" command) by adding a system
property named masterclear.allow_retain_esim_profiles_after_fdr.
When recently updating the strings shown in the factory data reset
screen and the confirmation dialog, we changed the code so that if that
the checkbox is hidden we'll pass false for the ERASE_ESIMS_EXTRA
parameter sent to the factory data reset confirmation dialog. This had
the unintended side effect of making devices that don't specify true for
masterclear.allow_retain_esim_profiles_after_fdr skip erasing the eSIM.
This CL fixes that by removing the "is the checkbox hidden" check, going
back to the previous behavior of just using the checkbox value, which is
on by default even if hidden.
Fixes: 135284765
Test: make RunSettingsRoboTests
Change-Id: Ia9f335920e4e3c4a90f0a6a49d1722a0c19ea83d
(cherry picked from commit 5f612a4b44)
From traces analysis, we found getFreeBytes
was taking a long time to return.
getFreeBytes was used when storage controller
tried to get storage information.
In order to prevent this case, we put the action
which takes too much time in background thread.
Test: I can't reproduce it locally. From code view,
this is a reasonable root cause.
Fixes: 136268875
Change-Id: I78e42cde88553c003f198cffb5747b352055f59a
(cherry picked from commit 0c37f019f6)
Add tobiast@ to the OWNERS file as libcore TL.
Remove pszczepaniak@ as he hasn't been on libcore
for a while.
Test: None
Change-Id: I714d3448ed60006cb58a0f49e95b7b834a6aac36
