am skip reason: Change-Id I4d6113561906af5c9e4ac7737aefac17c926059a with SHA-1 db816c9dad is in history
Change-Id: I3e3d9481426bbb02dc7be34dfabd95a35731cda2
If one sim hide the preference and another one show the preference,
the preference always hide. The root cause is config value is wrong.
It should get config with subid.
Bug: 149800931
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SimLockPreferenceControllerTest
Change-Id: I91b551bc363b8ecb0a4b6b40e9de79c74ccd76fd
Merged-In: I91b551bc363b8ecb0a4b6b40e9de79c74ccd76fd
while User disable VoLTE, UE show warning Dialog for 5G disable
add String for it.
Bug: 151313654
Test: build pass.
Change-Id: I2246664f1acbd2489dc3540486a7e1fa08d66656
Right now, it crashes if mEnableUseWifiComponentName is disabled by the
open wifi app.
Bug: 150773571
Test: manual - along with ag/10741759, verified that disabling
mEnableUseWifiComponentName hides the toggle instead of causing crash.
Test: make RunSettingsRoboTests ROBOTEST_FILTER=UseOpenWifiPreferenceControllerTest
Change-Id: I47e36fab411e4e4d1a23b7c91504139f124222e1
Android 10 introduced a security feature to automatically revoke
adb authorizations for systems that have not reconnected to the device
within 7 days. While this is helpful for consumers that enable adb for
a one time task and mistakenly select the 'always allow' option,
feedback has indicated having a developer option to disable this feature
would be beneficial.
Bug: 119510647
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AdbAuthorizationTimeoutPreferenceControllerTest
Change-Id: I7eb123e8c69956aa02bb679784ac79650baf5dcb
am skip reason: Change-Id I5aecfa4b5a8e371b914573ddd080acb98078bfca with SHA-1 3e0f661f11 is in history
Change-Id: Ibe2c542a784ff8309de5fd6a370050d5a0aed8bd
Revert submission 10721220-hide
Reason for revert: Caused build breakage - b/151857606
Reverted Changes:
I7c725a1ec:Show only listUIChanges instead of all
Iec8755171:Introduce listUIChanges API for developer UI
Change-Id: I7753051b06faf1f48a818a134d1eda2500f817f8
For work challenges, do not reset incorrect password attempts if
challenge is resolved via biometric authentication. This is the
behaviour for personal keyguard and work challenge should be
consistent.
Bug: 139438785
Test: manual: enroll work challenge with fingerprint, set failed wipe
count (3) via TestDPC and attempt two failed attempts (via cmd
lock_settings). Resolve work challenge with fingerprint and attempt one
last failed attempt. Verify work profiel is wiped.
Change-Id: Ic64d3e44f3faa5adf8ac43db09e33c8403427990
Fixes: 149270345
Test: manual and check if new string is applied
Change-Id: I412c5b5681a85d482541ae30faa13e904942b612
Merged-In: I412c5b5681a85d482541ae30faa13e904942b612
(cherry picked from commit 86a6cb8ead)
- getActiveSubscriptionIdList
To use getActiveSubscriptionInfoList to get subscription Id list
- getActiveSubscriptionInfoList(Z)
To use getActiveSubscriptionInfoList() instead
Bug: 144478274
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SimLockPreferenceControllerTest
make RunSettingsRoboTests ROBOTEST_FILTER=MobileNetworkUtilsTest
Change-Id: I4d6113561906af5c9e4ac7737aefac17c926059a
Merged-In: I4d6113561906af5c9e4ac7737aefac17c926059a
Use the new method that filters out changes that shouldn't be in the
developer UI.
Test: make RunSettingsRoboTests ROBOTEST_FILTER=PlatformCompatDashboardTest
Bug: 151299145
Change-Id: I7c725a1eca32e2d253b9671c789777b5422ed469
The device management app may run before the end of device provisioning,
and it may start SetNewPasswordActivity. If this happens, use
ChooseLockGeneric instead of SetupChooseLockGeneric. Only use
SetupChoseLockGeneric if SetNewPasswordActivity was started by Setup
Wizard itself.
Fixes: 151552453
Test: atest com.android.settings.password.SetNewPasswordActivityTest
Test: atest com.android.settings.password.ChooseLockGenericTest
Test: Manually run consumer and enterprise device setup
Change-Id: I3b479ed18211d6625654f266fe692f07d0047e4f