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
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
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)
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
For saved networks that do not have a MAC address available in their
WifiConfiguration such as Passpoint networks, the MAC address will
be the default value of 20:00:00:00:00:00. In this case, display
"Not Available" as the summary of the MAC address preference.
Bug: 137282522
Test: atest WifiDetailPreferenceControllerTest &&
manual - open saved passpoint network details while disconnected
but in range and observe MAC address preference.
Change-Id: Ie9010b0430726de8105852ae2afe10047dcc3676
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
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
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
