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
an inner exception that captures the stacktrace where
Context.startForegroundService() was called last time,
from the same process.
Bug: 124137635
Test: Manual test with a tesapp. 1: when startForegroundService() is called by
the same process:
```
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: FATAL EXCEPTION: main
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: Process: com.google.omakoto.testapp, PID: 9545
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{e7674af u0 com.google.omakoto.testapp/.MyFgs3}
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:1965)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1934)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.access$2700(ActivityThread.java:255)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2190)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7839)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: Caused by: android.app.StackTrace: Last startServiceCommon() call for this service was made here
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1868)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ContextImpl.startForegroundService(ContextImpl.java:1823)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:779)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:779)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at com.google.omakoto.testapp.MyReceiver.onReceive(MyReceiver.java:53)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.handleReceiver(ActivityThread.java:4345)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.access$1600(ActivityThread.java:255)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2102)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: ... 7 more
```
Test: Manual test with a tesapp. 1: when startForegroundService() is called by
another process:
```
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: FATAL EXCEPTION: main
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: Process: com.google.omakoto.testapp:second, PID: 9432
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{dcaa127 u0 com.google.omakoto.testapp/.MyFgs3}
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:1965)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1934)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.access$2700(ActivityThread.java:255)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2190)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7839)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
Change-Id: I2dd8ec76213d53728eaa8fcc3760813d82a328a5
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Bug: 205859784
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Test: atest NexusLauncherTests
Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
When checking whether a notification has a media session, make sure that
the value in the extra is the correct type.
In addition, moves this check inside of
Notification#isMediaNotification for consistency - existing usages either
already checked both or will not be impacted, given that valid MediaStyle
notifications are now shown in the media carousel instead of with other
notifications in the shade.
Fixes: 205570941
Test: atest
Test: manual, repro case in bug
Change-Id: I5d0134d2ce81e9e6a2ed16748f84252bf765a1c9
Always throwing RemoteServiceException would make it impossible to
tell the cause of a crash without the string message.
Let's use a different exception type so developers can cluster crashes
without the exception message.
Bug: 124137635
Bug: 172001574
Test: Treehugger
Change-Id: If04f8c66efcc32a5200efa70ea20d97e13006039
Also fixed how the logout user was cleared after a successful switch.
They will be used by CarSystemUi to end a session.
Test: Manual verification with CtsVerifier and TestDpc on automotive
Bug: 205185521
Bug: 204483021
Change-Id: Ieda0a22625ef705fcd705aedfc2dbf2cf570bf81
It was requiring INTERACT_ACROSS_USERS_FULL (instead of
INTERACT_ACROSS_USERS), which cannot be granted by Shell
(and hence cannot be used by CtsVerifier).
Test: m update-api
Test: manual verification
Bug: 203752848
Change-Id: Ie84311e6500cefa055548e309ee6d629c62fb10d
A background app that changes the wallpaper, was able to change the
device theme.
This change will apply the theme if the app is on the foreground, like
WallpaperPicker would be, but would defer the event until the next power
button cycles, like we do with Live Wallpapers, to avoid the same type
of DoS.
Test: manual
Test: atest ThemeOverlayControllerTest
Fixes: 205140487
Change-Id: I2086b29ef9bf3bb6fb7d9ebba6e7b8db9392e459
Merged-In: I2086b29ef9bf3bb6fb7d9ebba6e7b8db9392e459
