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
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
updateState was invoked in loader callback. But the
package was uninstalled at the callback time caused
null pointer exception. Add null check to prevent
null pointer access.
Fixes: 136170218
Fixes: 133771724
Test: make RunSettingsRoboTests, manual
Change-Id: I2715e77f6e32af42a4bce70c9f409b0311eb36c4
(cherry picked from commit 790a822526)
Bug: 138197084
Test: Verified other accessibility features like Live Transcribe does
not bring the user to the accessibility flow.
Test: Verified that the Sound Amplifier does not bring the user to
the accessibility flow.
Change-Id: I5131d74926c0b01c565da280c55afe0080855688
Use the "July 13, 2019" or similar to display if the value is a valid
date data.
Bug: 137089104
Test: visual test & robotest
Change-Id: Ie4bab2617c1cd6fd956bf6d1a22ce96e6b0b58d0
Merged-In: Ie4bab2617c1cd6fd956bf6d1a22ce96e6b0b58d0
(cherry picked from commit 162e88c262)
Bug: 137197916
Test: Manual test with setting a 3P launcher as default
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SystemNavigationGestureSettingsTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SystemNavigationPreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=RadioButtonPreferenceWithExtraWidgetTest
Change-Id: Id397cfa1c2439222aa21a7b7fe5f69818bf1fe97
Fixes: 137876221
Test: manual - have setting in dev options turned off, post a bubble
=> no bubble appears
- have setting in dev options turned on, post a bubble
=> bubble appears
Change-Id: I4490b978059a73b45fa8d09bf28e05965f42eec1
Add new reminder string in "Magnify with shortcut" page when
it's under gesture navigation mode.
Reference link of screenshot:
https://drive.google.com/file/d/1uo31FZebhXKcCR8QY_WrgEPiInzARmIl/view?usp=sharing
Bug: 134645913
Test: Visual
Change-Id: Ibbaa162d4acf0fdeed8c98b2aa1d83953880e6a6
Merged-In: Ibbaa162d4acf0fdeed8c98b2aa1d83953880e6a6
Move the switch after the caption preview and change the oreder of the
settings inside in caption preferences in Accessibility settings.
Reference link for screenshot:
https://drive.google.com/file/d/1EQLpfQFnJTwU1F8vLAOSHPYqSXKWL_ap/view?usp=sharing
Bug: 130755332
Test: Visual
Change-Id: Icb4dabdef71be165a21d1bde474872ee0bb35bfa
Merged-In: Icb4dabdef71be165a21d1bde474872ee0bb35bfa
(cherry picked from commit fd1f1c0f82)
The launchMode for MobileNetworkActivity specified in the android
manifest is "singleTask", which means that when an intent to it is
launched, if there is an existing instance we will reuse that instead of
creating a new one. But to handle this properly we need to know when it
happens by implementing onNewIntent, which we weren't doing.
Implementing this fixes a bug we noticed that if you have multiple SIMs
and recently visit the details page for SIM 1 but then click on a SIM
selection notification that should bring you to the details for SIM 2,
we'd just bring up the details page for SIM 1 again.
Fixes: 133447239
Test: make RunSettingsRoboTests
Change-Id: Ia9106b15ffde437f6dd6fd2da23336ec5b28f75e
Follow up to http://ag/8222583
- Replace references to Secure.NOTIFICATION_BUBBLES with
Global.NOTIFICATION_BUBBLES
Fixes: 136034310
Bug: 129158983
Test: m RunSettingsRoboTests
Test: atest SystemUITests
Test: manual - work profile bubbles show up
Change-Id: Ifa71206353237b837cfcda6d23ea6a6ec2c146d0
Follow up to http://ag/8222583
- Replace references to Secure.NOTIFICATION_BUBBLES with
Global.NOTIFICATION_BUBBLES
Fixes: 136034310
Bug: 129158983
Test: atest SystemUITests
Test: manual - work profile bubbles show up
Change-Id: I03ffd7f1126f2c20d819f741cd4f7dcced81a405
Fixes: 137285390
Test: Verified that SecuritySettings no longer crashes.
Test: Verified that this PrefenceController no longer shows up
if the device does not support it.
Test: Verified that this PreferenceController no longer
shows up when the work profile is disabled.
Change-Id: I10f015e18491b203db6f942f07034d55f620cfe5
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
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)
For devices which provide biometric authentication options, such as
fingerprint or face, we should be showing different content on the lock
setup screen during the corp account setup wizard. Namely, the title
should read "Choose screen lock", and the "Not now" option should be
changed to "Continue without [auth method]". However, we currently only
check for whether fingerprint authentication is available, leading to
incorrect text for devices with face authentication.
This CL fixes the issue by changing the introducing a private method to
check for any biometric authentication (currently just mForFingerprint ||
mForFace). It then uses this method in place of the existing
mForFingerprint checks in SetupChooseLockGeneric.
Test: On a device with fingerprint auth and one with face auth:
1. Set a work profile with TestDPC and add some password quality requirement
2. adb shell settings put global device_provisioned
3. adb shell am start -a android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD
4. Verify that the correct content is now shown (screenshot/xZPVtpa3j3Z)
5. Verify that setting lock with and without biometric auth still works
Fixes: 136556653
Change-Id: I46d3c964f05986aa97cc8ed77fe0ac125337ddd0
