Special case Uris need to explicitly add their intents.
This unfortunately duplicates a list of special-cased Slices,
but I have attached a bug with a plan to address this duplicity in Q.
Change-Id: I346915c32543713d33716422018d7c950cce323d
Fixes: 80065409
Test: atest SliceDeepLinkSpringBoardTest
Because I missed them in the long whitelist the first time...
Change-Id: I9fbd7b33e06b3f2f6e5e5778f78abfdb1a52006a
Merged-In: I01c8c80fe306667c1d3ac007b16fad546c5a5f40
Fixes: 79779103
Test: robotests
In several places we were referencing private icons from
frameworks/base/core instead of versions we already had in
settings. Also add in a "media stream off" icon to match the one we
already had for "media stream on".
Bug: 77982107
Test: manual (Settings->Sound, then use hardware controls to modify
media and ring volumes)
Change-Id: I3a1d808b3028bb4f2feae4536194dc58c3177a66
For notification fields. This is required for them to
display properly within an 'advanced' preference category.
Test: robotests, manual
Change-Id: I1e1ff0e801e136c6a86a0d9164ed21d4160e897a
Fixes: 80132743
Only support explicitly approved Settings Slices,
dictated by controllers which return true for the new
method isSliceable.
Updating the supported settings to a whitelist means that
the method to return all available slices must be updated,
and checking slicability when we index slices.
Test: robotests
Change-Id: I85848c2cdf3e151fa94b33dd1dc5c0374ef94b5b
Merged-In: Ib2b9690cdd0036b5cc4a1cb846c52bce7c824ab9
Fixes: 79779103
If the activity has started, style the actionBar when the
header is being updated
Test: manual
Change-Id: Ide69fc0f6e8e5046105bd290d22d9f9a3df5c1ae
Bug: 79983080
For settings which can change in the framework, outside of
the settings app and a slice, a Slice needs to be able to
register a listener for these changes.
Adding a getter for an IntentFilter in BasePreferenceControllers
allows us to use the SliceBroadcastRelay in SysUi to listen for
these changes.
Test: robotests
Fixes: 78138654
Change-Id: I579375069ca98fd21b60cd3a69c1a122cabf96e2
Merged-In: Ifa05b651aaa3458c54866f71469964b1a070e458
Add DND Slice as a special case, since there is an existing
inheritance structures in the zen mode preference controllers which
would be too risky to change at this point in the release.
Change-Id: If4b7013be35c89695786af2dbbea2edcf7a189f3
Merged-In: Ice608b9a7bd6f38b73e581eb3723f0a2fae96f2b
Test: make RunSettingsRoboTests
Fixes: 67997377
* Add AudioSwitchCallback() in AudioSwitchPreferenceController.
This callback is used to notify SoudSettings to update the dialogFragment UI.
* Add UpdatableListPreferenceDialogFragment that updates the available
options when dialog is shown
* Add test to verify the adapter count when
onListPreferenceUpdated() is called.
Bug: 77783217
Test: make -j50 RunSettingsRoboTests
Change-Id: I8cac1b30ec50df026f4b7722dd1cd2f69e77a4cb
Merged-In: I8cac1b30ec50df026f4b7722dd1cd2f69e77a4cb
Use TogglePreferenceController instead of AbstractPreferenceController
for VibrateWhenRingPreferenceControllr
Bug:74915140
Test: make RunSettingsRoboTests
Change-Id: Ib06126324516826411a7d50a2bd8a790bfd477c7
Merged-In: I501a1470da7dc1ff582c2a90b5235b25036caefc
- Show mute icon when ringer is muted
- Show vibrate icon when ringer is on vibrate
- Show ringer icon when ringer is on ring
Test: visual inspection
Change-Id: I662e0d4fd33ac2284378c2f558509c93c907fbe3
Bug: 78330194
- 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
