Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
This is a short-term workaround to dump error log instead of throwing
the exception to unblock the test.
Bug: 209744518
Test: build pass
Change-Id: I2ece3b9d85edc1ae43038e6f69b35f59b160a3dd
(cherry picked from commit f8fc1326f7)
The SizeConfigurationBuckets was used to avoid activity relaunch
by insignificant configuration change. Because WindowTokenClient
doesn't have relaunch operation, it is unnecessary to use it.
Especially Resources#getSizeConfigurations() is a heavy invocation,
which may create hundreds of temporal Configuration when calling it
in system server.
Also fix leakage of SystemUiContext if it is detached, e.g. the
associated display is removed.
Bug: 207620458
Test: atest WindowContextControllerTest
Change-Id: I8388a2ab25f3deed2e29eb5636c4b2130f4f1b87
INsdManager is going to move into connectivity mainline module
and it will be not visible to SystemServiceRegistry after
migration done. Thus, use ConnectivityFrameworkInitializerTiramisu
to register NSD service instead.
ConnectivityFrameworkInitializerTiramisu will be implemented in
the framework-connectivity-tiramisu bootclasspath JAR, which need
to be separated from the S+ framework-connectivity bootclasspath
JAR to be only loaded by the module on T+. So its methods cannot
be in the same class as ConnectivityFrameworkInitializer.
Bug: 206702844
Test: atest FrameworksNetTests CtsNetTestCases
Merged-In: Ibf89ab9a35e35dac4978ba70c7ab306b6155a4a3
Change-Id: Ibf89ab9a35e35dac4978ba70c7ab306b6155a4a3
Since ServiceNotFoundException is not a system API. Remove
the unsupported interface which uses this exception.
This is safe since the method annotated with maxTargetSdk = R
and from dashboard it is not using by anybody.
Test: TH
Bug: 204830222
Change-Id: Ib8c0ce7b165732d24929851792d35371b90a5dfc
NetworkStatsService is going to be moved into ConnectivityService
module. Move all related files to packages/ConnectivityT so that
it can be easily migrate these files to connectivity module
after clearing the hidden API usages.
Bug: 197717846
Test: TH
Change-Id: Iead00832b5eb7b1dc40a92027c5a14ae8316b16c
- Do not report change when initializing DisplayContent
(DisplayContent#isReady() is false).
This reduces boot time by dozen of milliseconds
(RootWindowContainer#setWindowManager).
- Only create SystemUiContext if needed. Most of processes don't
use it. This reduces many registrations (e.g. according to the
number of processes, it maybe from ~60 to ~10), which involve
binder/listener creation/invocation, especially the extra cost
of dispatching configuration to the context which no one uses.
- Store token as IWindowToken to avoid object creation every time
by asInterface.
Bug: 207620458
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Change-Id: I867e9f81116796c42048195406d74feccf4772d3
The size of the input of both setStream and setResource may very big
that system server got oom while handling it, so we try to decode it
first before copying it to the wallpaper path, if the decoding fails, we
treat the input as an invalid input.
Bug: 204087139
Test: Manually set wallpaper, no PDoS observed.
Change-Id: I014cf461954992782b3dfa0dde67c98a572cc770
The size of the input of both setStream and setResource may very big
that system server got oom while handling it, so we try to decode it
first before copying it to the wallpaper path, if the decoding fails, we
treat the input as an invalid input.
Bug: 204087139
Test: Manually set wallpaper, no PDoS observed.
Change-Id: I014cf461954992782b3dfa0dde67c98a572cc770
Refactored to system server to the repository pattern
added locks to the WallpaperManager
Fixes: 206632865
Test: manual
Change-Id: Icc73c18e34042ae48e338b03dc3e94fee5d6939d
This CL is a refactoring of the DialogLaunchAnimator and a major change
in how it works internally.
Before this CL, when DialogLaunchAnimator.show(originalDialog, ...) was
called, it would create a fullscreen dialog (called hostDialog) to
which we would add the content view stolen from the originalDialog (that
would then be hidden). We would then run the launch animation in the
host dialog and listen for show(), hide() or dismiss() calls to the
originalDialog to know when we should show(), hide() or dismiss() the
hostDialog.
The main reason we did that was because there was no way to override the
dismiss() behavior of the originalDialog, which we need to do given that
we want to animate the dialog into the view that showed the dialog
before actually dismissing it.
This approach had multiple downsides:
- We were showing the dialog content view inside a different window
than the one in which it was created, therefore any change made to or
any listener added to the originalDialog window was lost.
- Code calling DialogLaunchAnimator.showFromView needed to know that
their dialog content will be moved to another window, which is
unexpected and can lead to subtle bugs.
- We were waiting for 2 dialogs to be shown instead of 1 before being
able to start the animation.
This CL does what we should have done since the beginning: it adds a
hidden API to Dialog so that we can override what happens when
Dialog.dismiss() is called. This allows the DialogLaunchAnimator to run
the exit animation into the view that triggered the dialog before
actually dismissing it. The only modification that
DialogLaunchAnimator.show(originalDialog, ...) now does to the
originalDialog is making its window fullscreen and inserting two views
between the originalDialog DecorView and its children. The first
inserted view is a fullscreen transparent background used to dismiss the
dialog when the user taps outside the dialog content. The second
inserted view is a View that we size and position the same way that the
DecorView was before we made it fullscreen, and to which we set the
originalDialog background. This view now serves as a "fake window" with
the same size, background and position as the original window
(DecorView).
This CL improves the time to start the launch animation by 20-25%
(measured in a totally unrigorous logcat way).
Bug: 193634619
Test: atest DialogLaunchAnimatorTest
Change-Id: If09eda7b06e83b3ed7714cec97afef08b3d9fd3e
Previous the splash screen style can either be EMPTY or ICON, and need
to be set by new hidden API #setSplashscreenStyle, so the flag will
always be "EMPTY" for those 3rd party Launcher Apps which may have not
upgrade to targetSDK 31.
To correct the default behaivor for Launcher Apps, create a new
UNDEFINED style as default value for splashScreenStyle, and if the
value is UNDEFINED, determine the style by checking the launch source.
Test: Verify no change when default home is NexusLauncher.
Test: Set 3rd-party Launcher as default home, verify the splash screen
style should be ICON when launch app from Launcher.
Test: atest SplashscreenTests
Bug: 206746601
Change-Id: I105e2fcfc7a6ee8de7f442931cbeb4b6e517850d
Merged-In: I105e2fcfc7a6ee8de7f442931cbeb4b6e517850d
