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
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
If a profile owner is defined for a specific user, do not delete usage
stats for a package on package deletion.
Bug: 197399948
Test: atest UserUsageStatsServiceTest
Test: atest UsageStatsTest [all]
Change-Id: I94a8e3dfca8ef4c7616f77944d61726e06043b85
Merged-In: I94a8e3dfca8ef4c7616f77944d61726e06043b85
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
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Change-Id: Idd74da965c18bdbf8912bd45e89be21f652dcf93
setTurnScreenOn shouldn't dismiss keyguard automatically even when the
keyguard is insecure.
The keyguard state should only be affected by requestDismissKeyguard
and/or setShowWhenLocked, and for either case setTurnScreenOn can be
used to wakeup device if the activity is going to be resumed and
visible.
Bug: 201103497
Test: atest ActivityVisibilityTests KeyguardTests KeyguardLockedTests
Change-Id: I283dea469a33286fc9cf835e39ee5a3be2444739
(cherry picked from commit f3a1274a38)
