By default we no longer refresh category with each setTileEnabled.
Instead app will call update after all setTileEnabled are called.
This saves a lot of async task execution when Settings app starts
Bug: 34103984
Test: RunSettingsRoboTest (no regresssion)
Change-Id: I71ddcdb3e1fc0df6cacb53583a4f7e8ae8d675f1
* changes:
[RingtoneManager] Option for cursor to list parent sounds
[RingtoneManager] API to delete custom ringtones
[RingtoneManager] API to add custom ringtones
Write a jank test that is animating height and width of a View
backed by a HW layer.
Test: built angler-userdebug and ran UiBench jank tests.
Change-Id: I69eccb73b6fb887549506c80590892665051ee2f
This reverts commit 106ff7a0a1.
Test: All the unit tests (ShortcutManagerTest1*) CtsShortcutHostTestCases and CtsShortcutManagerTestCases
Change-Id: Iadce2b3785cbf728daa60c4e2ff103e516d85896
When Stack#removeImmediately() was called it also recursively
called Task#removeImmediately(), which remove tasks from stack.
This lead to Task#mStack reference being nullified, but task
dim layer user was still registered in DimLayerController.
Therefore there was a crash when dim layer animation occured.
This CL moves most of the logic from Task#removeIfPossible() to
Task#removeImmediately() to make sure that cleanup is performed
every time when task is removed.
Change-Id: Id8d72dc8c66b9eeefbf5c918cf0a0df4ea027fde
Fixes: 34052466
Test: bit FrameworksServicesTests:com.android.server.wm.TaskStackTests
Test: #testStackRemoveImmediately
When the last activity finishes in the stack we're looking for other
stacks and making it focused. However we weren't doing that if the
stack was on a secondary display, so the focused stack records were
not updated in stack supervisor.
Now we're looking for other stacks on the same display first. If there
is nothing focusable left - shifting focus to next focusable display.
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testStackFocusSwitchOnDisplayRemoved
Test: #testStackFocusSwitchOnStackEmptied
Change-Id: Ifbb893e12cbe9c4928b949a86fc8bc027de181e4
Adds an integer resource (config_warningTemperature) that is used
to display the high temp warning. If it is set to less than 0,
the value from HardwarePropertiesManager#getDeviceTemperatures(
HardwarePropertiesManager.DEVICE_TEMPERATURE_SKIN,
HardwarePropertiesManager.TEMPERATURE_THROTTLING) is used instead.
Test: manual
Bug: 30995038
Change-Id: I05aa1b5930c6c151ebac439dfd5c00b3305dc46d
(cherry picked from commit 7518471ab6)
OEMs can overlay the default 9 dots by providing two drawables that represent
those dots:
* lockscreen_notselected: asset to display when a cell has not been selected.
* lockscreen_selected: asset to display when a cell has been selected.
BUG: 33755663
Change-Id: Ic595b01f5e1321696b7a3feb0ff73c1acccfb942
If we do move those tasks to the front, it will annoy the user of the
device because clearly that's not the activity they were using at the
time (otherwise it would have been resumed already)
This is a more generous check than the existing "if !top.visible" which
only prevented the new overlay activity from bringing the task to the
front if it was unresumed AND not visible on the screen.
Now it just has to be unresumed.
Bug: 31001762
Change-Id: I4576aaafa141ef5297f9c18935b747693a80f0fd
- WindowContainerController class allows a component outside window manager
to create a window container and communicate directly with it to make
changes. For example, the ActivityRecord class in activity manager uses the
AppWindowContainerController class to create and communicate with
AppWindowToken window container class which is its counterpart on the window
manager side.
- WindowContainerListener interface allows a component outside WM to get
notified of changes to a window container. For example, the ActivityRecord
class in AM implements the AppWindowContainerListener interface to get
notified of changes to the AppWindowToken container.
Bug: 30060889
Test: Existing tests pass and manual testing.
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.WindowContainerTests
Change-Id: I2896bfa46a80b227052528c7da8cf4e56beab4bc
This is to prevent apps which do not support density
(so essentially pre-Doughnut) from being resized and / or
windowed in free form mode.
These apps are rendered into a smaller sized buffer and
then scaled onto the screen. Using freeform window mode with
these apps uncovered many different problems.
Bug: 33843467
Test: Pre-N as well as Pre-Doughnut applications are presented
properly in free form mode. (Pre-Doughnut cannot be windowed /
resized, many M apps can).
Change-Id: I3c0eb3681486dc85ace15955432d79200743bce3
Remove code that let these components be replaced by external
processes.
Bug: 33006669
Bug: 34106436
Test: manual. reboot device, play music, change volume,
view notifications
Change-Id: I458f11537ab9db6f23735487513815553004613f
Port all system UI notifications to use the registry. Retain stable
integer IDs where they exist. Assign new stable IDs where resource IDs
were previously used.
Using "message" rather than "notification" since we may eventually
want to include dialogs and toasts.
Bug: 32584866
Bug: 30995038
Test: runtest systemui
Change-Id: Iec4d7cebbd88683e339ada29a279315222699942
