to be more consistent with more Settings usages and with the DashboardFragment class these extend.
Flag: android.app.modes_ui
Bug: 335259054
Test: n/a, just renamed
Change-Id: Ie64c06eb3ed92822ba47cf272f507d4b4a85d11c
This reverts commit 93e4c65d3d.
Fixed the test by cherry-pick change
I7a3d27cb53c930a56ab0f0896b545807bf4f9dc0.
Bug: 336209156
Test: manual - on MobileNetworkSwitchController
Test: atest SubscriptionInfoListViewModelTest
Change-Id: Id606d6ee90acd8a98de706d8533fed0aac96bff4
This reverts commit 15c90207e2.
Reason for revert: ag/27138142 shall fix the crash instead of reverted one.
Change-Id: Icf46fda7af9c9bb6921bc10de0f9c93926f42fac
If BOARD_16K_OTA_MOVE_VENDOR := true is set, OTAs will be present at
/vendor/boot_otas for 16KB developer option. Apply OTA from vendor if
present, otherwise fallback to system OTAs
Test: m, m Settings && adb install -r $ANDROID_PRODUCT_OUT/system_ext/priv-app/Settings/Settings.apk
Bug: 335022191
Change-Id: I534b354c830de2c90fee76502667d5e4ef5a7714
This reverts commit 6142ad927e.
Reason for revert: Droid-monitor created revert due to Build breakage in b/337914519. Will be verifying through ABTD before submission.
Change-Id: I300d5397de156fd0815965cfd99f0814f1365ffc
The main responsibility for updating stored ZenMode data when updated is the Settings page, which reloads mode data whenever any changes are detected. This change adds a process for that Settings page to then update the ZenMode data associated with all controllers on that page.
Flag: android.app.modes_ui
Bug: 335259054
Test: manual with toy implementations
Change-Id: Ie1692da54d962c90378085d8bd8573e5b93f8eb6
This reverts commit 680d062c77.
Reason for revert: <Potential culprit for b/337796129 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
>
Change-Id: I6fbb7a0587fbb474012e1a97a75c036420500f99
When turning off quiet mode for work profiles, ACTION_CONFIRM_DEVICE_CREDENTIAL_WITH_USER is fired
to confirm the device/profile PIN in order to decrypt the profile's storage. For work profiles with
unified challenge, we are expected to call LockPatternUtils.verifyTiedProfileChallenge() that
specifically decrypts the work profile's storage using the device PIN. This code flow is only reachable
when mForceVerifyPath is true in ConfirmDeviceCredentialActivity. In
I8b61e7d2df5792cbdb2e12b19e5a5582ea2290b7 a regression was introduced that caused the wong condition
to be used, and as a result work profile with unified challenge is no longer unlocked correctly in
this unlock flow. This bug is normally masked since we cache the unified work profile's password and
don't ask the user for device PINs most of the time. It's only reproducible when turning on work
profile from the keyguard, when we don't use the password cache. Fix this by using the right condition.
Bug: 328640625
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: I5eb9379dc140c9803f033beee38fcd63aa9a85c0
Which will emit true if any active sub is in call.
And also create SubscriptionActivationRepository to use isInCallFlow.
Bug: 336209156
Test: manual - on MobileNetworkSwitchController
Test: unit test
Change-Id: I75460bf17961349557ac1e19e7f6b15249f3d7b0
This reverts commit f9fabeae1c.
Reason for revert: Java crash when trying to open Settings on secondary user
Bug: 336697633
Bug: 337044085
Change-Id: I0c6793ce2a28294c093c9786cecddd19bd643141
If the registration failed (e.g., device doesn't support satellite), SatelliteManager will not emit the current state by callback. We send `false` value by ourself to make sure the flow has initial value.
Bug: 315928920
Test: atest, manual
Change-Id: Ic87f71bc576cfb1f8e4053c5784fca401adaec08
