The CL fixes the bug that eSIM profile is not erased even if user
choose to erase eSIM during Reset Mobile Network Settings flow.
The issue was introduced when adding background operations to
restart Phone process and RILD. Restart Phone process performed earlier.
It may interrup the previous reset operations (e.g. eSIM erasing).
The fix here is to arrange reset Phone and RILD in the end of the flow,
only performed after all other reset operations.
Bug: 345854350
Test: atest ResetNetworkOperationBuilderTest
Test: Manual regression test
Change-Id: If2bd492d417a07a7056bf9fd0d051f8811ba6369
This cl moves the creation of repos and interactors to the
SettingsApplication.
Bug: 297082837
Test: atest
Change-Id: I9049da6f03bb1dc18d4186961444bf613d773d0e
Currently, the changes to disable private space settings app component
are located in SettiingsInitialize.java. These get triggered when
ACTION_USER_INITIALIZE is received by the settings app inside the
private profile user. However, we are stopping the private profile user
at the end of the setup flow. This can lead to a scenario wherein
ACTION_USER_INITIALIZE is relayed by the system server but not received
by the private space settings app, since it was stopped. To over come
this issue, we move the changes to disable the private space settings
app component inside the private space setup flow (right after the user
is created and started).
Bug: 342165140
Test: atest PrivateSpaceMaintainerTest#createPrivateSpace_psDoesNotExist_setsPrivateSpaceSettingsComponentDisabled
Flag: ACONFIG android.multiuser.enable_private_space_features NEXTFOOD
Change-Id: Ib9baac1e9d835ea5a27c15d499e10615b84cf97b
Revert submission 27518747-revert-27019285-ACTION_NETWORK_PROVIDER_SETTINGS-UWYYODXDGG
Reason for revert: per b/338527563#comment37, this was wrongly pointed out as culprit, looping folks conducting investigation as +cc
Reverted changes: /q/submissionid:27518747-revert-27019285-ACTION_NETWORK_PROVIDER_SETTINGS-UWYYODXDGG
Change-Id: Id3dfdac978227d0fd065f1eb59b525f041fad3d2
When changing hotspot to 6GHz, we auto-set the security to WPA3-SAE. However, we don't do the reverse when changing out of 6GHz, which may cause legacy devices to be unable to connect. Instead, always revert back to WPA3-Transition when switching out of 6GHz.
Bug: 323764310
Test: manual
Change-Id: I06b1e97f452da86a693812a6620c251ff5d0e932
Migrate test to robolectric, as this test doesn't require a device to
run. This also speeds up the test, and allows for use of roboelectric
shadows.
Fixes: 337417918
Test: atest CommunalPreferenceControllerTest
Flag: EXEMPT fix broken test
Change-Id: I32b2760c98bf527b33a8ccbe46314395a03da1e0
After creation of private space value of auto-lock setting is explicitly
set to lock on device restarts. Just before the end of the setup flow
the auto-lock setting is changed to auto-lock on device lock before the
last screen of private space setup.
Bug: 342398315
Test: atest PrivateSpaceMaintainerTest
Change-Id: I8eeb0058c7ecb31d6e30b4cc78ec5877ed316f75
- Move data logic into repository for better testing
- Check carrier config first, if not shows some items, we don't need to
load data
- Tests in SimStatusDialogControllerTest will be fixed in later cls
Bug: 337417520
Test: manual - on SIM status
Test: unit test
Change-Id: Iccd209fd455d66d4f6438652ee7481d2a0e72a99
- Move data logic into repository for better testing
- Check carrier config first, if not shows some items, we don't need to
load data
- Tests in SimStatusDialogControllerTest will be fixed in later cls
Bug: 337417520
Test: manual - on SIM status
Test: unit test
Change-Id: Ia0c32882f0b35ec9154b3da58ac6a7b98c879efc
Revert submission 27019285-ACTION_NETWORK_PROVIDER_SETTINGS
Reason for revert: b/338527563 CL seems to be introducing jank for systemui tests somehow, reverting to get out of the way
Reverted changes: /q/submissionid:27019285-ACTION_NETWORK_PROVIDER_SETTINGS
Change-Id: I48bc0f4efc22dbff9f983b4606442b3ebd6d584c
Migrate from deprecated api, and use new api as flow.
Bug: 337417520
Test: manual - on SIM status
Test: unit test
Change-Id: I8f938c0ccb6e3e61f8d4f6cb72c293f564351d52
The onReceiveSimCardStateChangeReceiver_receiveAction_timerCountDown
is failed since the action is wrong.
Bug: 337417975
Test: atest UiccSlotUtilTest (pass)
Change-Id: I0cb12432553155d69f985693e4ef911455c81652
Migrate to flow and not call setVoNrEnabled in main thread.
Fix: 339846642
Fix: 339542743
Test: manual - on Mobile Settings
Test: unit test
Change-Id: I27fe7cb2ddadc9a0aaa8c589af4703210b33612d
When search start to index and run to MobileNetworkSettings.java, the
TelephonyBasePreferenceController will find which subId can be the
"AVAILABLE" from the active subscriptionInfo list. This active subscriptionInfo
list does not be filtered, so the search uses the invisibile sim's item for user.
Bug: 335509130
Test: atest MobileNetworkUtilsTest (pass)
Change-Id: I2840e7de344347643197592e125f5524d27a068e
