Hide preferred network mode UI no matter home, roaming or no service
when KEY_HIDE_PREFERRED_NETWORK_TYPE_BOOL been enabled.
Bug: 137681413
Test: atest PreferredNetworkModePreferenceControllerTest
atest EnabledNetworkModePreferenceControllerTest
Manual with AT&T SIM card in out of servce and in service
Change-Id: Ia0d1333c6cbae3a3717c8db6b77fbb9ea8cec968
Context#getResources loading is done based on the last SIM to
come up, we may get wrong customization settings.
This fix check the setting of active subscription and shows the preference.
Bug: 138956509
Test: CellularFallbackPreferenceControllerTest
manual test:
1. Insert feature supported SIM and check UI.
2. Remove feature supported SIM and check UI.
3. Turn airplane mode on and check 1. and 2..
Change-Id: I72b6db415429181395a02f163889bb1b9c0f070f
Merged-In: I72b6db415429181395a02f163889bb1b9c0f070f
Currently, the title will not update at all if set to silent.
Bug: 130445562
Test: make RunSettingsRoboTests -j48
Change-Id: Id8fc0182adb37c05436f5924b7dcdffb9d994e0d
Users may have trouble finding this setting in face auth.
Heard this from dogfood/executive feedback and customer support discussion.
So add Skip Lock Screen preference in
Display > Lock screen display > What to show >
and
App & Notifications > Notifications > Lock Screen >
Bug: 138458558
Test: robotest & manual
Change-Id: I10e420821423821743d65b00c8b7e6d4d1224e00
If the DISALLOW_CONFIG_MOBILE_NETWORKS admin policy is set, we were
accidentally still allowing access to the flow where you add an eSIM
subscription via the "plus" button on the Network & internet page. While
fixing this, I also noticed that the mobile networks list page (which
only becomes available if you have multiple subscriptions) has a link at
the bottom to start the flow as well, and that wasn't being protected.
The fix for the plus button on the Network & internet page was just to
make sure not to call setEnabled(true) if the preference was already
disabled by admin policy, since that has the effect of overriding the
admin-disabling.
The fix for the mobile networks list page just needed to add the
relevant tags in the layout XML, and then we get it for free.
Fixes: 137627845
Test: make RunSettingsRoboTests
Change-Id: I896ac248f50aaeecc157791938a0a0a98265aa07
Change the color mode preview image to better illustrate the difference
between Natural and Boosted color modes.
Bug: 138126243
Test: manual testing on Pixel
Change-Id: I367b383f9f2da9b2e2d5960e51c3ec7821d4915b
The controller for the "Preferred network type" preference on the SIM
details page wasn't listening for changes to the underlying global
setting, so changes to the setting would be reflected in SysUI but not
on this page if it happened to be showing.
Bug: 135667565
Test: make RunSettingsRoboTests
Change-Id: I5dfe4843a681c613f49caf4584e9dbebc54e708a
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
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
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)
