- Deprecated effects are set in NotificationManagerService,
so unset them before setting the NotificationPolicy
- When user clicks on Custom, they are brought to the custom vis effects
page instead of resetting custom values to presets
Fixes: 79383781
Test: manual
Test: NotificationManagerServiceTest testSetNotificationPolicy_preP_setOldNewFields
Change-Id: Id6db9ce2aaeed6321389f8dbfbea65eda30c74ad
Distinguish between settings which are permanently unavailable on
the device, and temporarily unavailable. This enables us to restrict
which setting slices are exposed in onSliceGetDescendants.
The primary changes in this CL are renaming:
"DISABLED_UNSUPPORTED" -> "UNSUPPORTED_ON_DEVICE"
to be more clear the the setting will cannot be accessed on the device, and,
adding a new enum to encapsulate settings which are currently unavailable, but
could be enabled in the future.
Also remove UNAVAILABLE_UNKNOWN. Devs should never need this enum.
Bug: 78910582
Fixes: 79245656
Test: robotests
Change-Id: I42c2cedab66be2d76999795f46470a079cc1ec71
Merged-In: I58821a6cfd6134b3b351657b6edf5f74ead00643
Rather than check for the state of the work profile in
LockScreenNotificationPreferenceController#handlePreferenceTreeClick, do so in
the RestrictedListPreference#performClick.
The drawback of checking the state in handlePreferenceTreeClick is that the
preferences are displayed first and then the requirement to unlock/enable the
work profile is displayed on top of it.
This is rather poor UX, so switch to doing the check in performClick and
returning early if the work profile needs to be unlocked/enabled.
This is similar to Patchset 1 from ag/3805482.
The main difference is that the user is returned to the settings screen
both after enabling the work profile and unlocking it.
Test: Manually with TestDPC
Test: atest SettingsRoboTests:RestrictedListPreferenceTest
Bug: 77408805
Merged-In: Id168911b082fffac193cd7c7a658ab92d6ce2c15
Change-Id: I0a3a4ec4dda78e28ee88a11d383eda49e9cf50a6
- Keep launching notification settings in the Settings task. This is not
the expected behavior, but only a workaround until b/72420153 is
fixed.
Bug: 72420153
Test: Enter PIP, go to app > notifications > additional settings, ensure
that it doesn't start in the PIP task
Change-Id: I73e704a283285462d4884db21923818cfb6deead
Managed profiles cannot completely hide notifications, so
this setting should be treated as always "true" for them.
Change-Id: I9808c1e9736d83efccb0e947d9097379bda59ebb
Fixes: 78194020
Test: atest RedactionInterstitialTest
Load app/channel data early so that any open dialogs can be properly
reconstructed. Never call done on an entityheadercontroller with
an activity that's not yet started.
Test: robotests
Change-Id: Ib2b9f8f1985ef038959062204aaceff686f4ebcf
Fixes: 74114917
Instead of replacing the rigner slider, because the stream
isn't actually muted.
Change-Id: Id2c60d6c570084ed8febcaeb3b096a487f572312
Fixes: 77641315
Test: robotests
Convert GesturesSettingPreferenceController to
TogglePreferenceController,
All of its children need follow the change,
add setter and robotest for them:
AssistGestureSettingsPreferenceController
DoubleTapPowerPreferenceController
DoubleTapScreenPreferenceController
DoubleTwistPreferenceController
PickupGesturePreferenceController
SwipeToNotificationPreferenceController
Change-Id: I792b2d370eea828bf345fb2b1cc3eac260eb66f4
Merged-In: I792b2d370eea828bf345fb2b1cc3eac260eb66f4
Fixes: 74913806
Fixes: 67998110
Fixes: 67998098
Fixes: 67998048
Fixes: 67998069
Fixes: 67997452
Test: make RunSettingsRoboTests
- when we adjust the sound volme in Sound settings, we only re-post the
stop sample message when we receive the onSampleStarting callback.
However, if we change the volume while a sample is still playing,
onSampleStarting will not be called as it's already started. This
results in shortened sample duration, which in extreme case, the new
sample will not be played at all if the new volume change is made almost
towards the end of the previous sample period. So, everytime user change
the volume, we should re-post the stop sample message, so that the
sample playing duration would be extended properly.
- also removed the original calls to the onStreamValueChanged() during
init, as the original implementation is empty, and during init, we do
not need any handling to start/stop the sample.
Change-Id: I9f35ddfb6d809eeb83b1a732a09362286ff6ed77
Fixes: 77514234
Test: make RunSettingsRoboTests
