As CL[1] introduced WindowTokenClient for WindowProviderService (aka the
parent class of InputMethodService starts from CL[2]) as a token that
IME context can associate with the windowContainer of
the InputMethod window in server side. Like the activity context,
IME context can adopt configuration/resources update when the IME
window changed by display/window changes.
And, the IME context caller can also create another type of context
with wrapping IME context (i.e. calling createDisplayContext to create
a display context), that makes this context can be mixed the window
token of WindowProviderService since it's the base context.
However, the finalization of the context mixed WindowTokenClient
will detach the token when the attached context type is non-window
context, this action will mis-detach the token when it managed by
WindowProviderService.
So like SoftKeyboard previously using
createDisplayContext in CL[3] to workaround context resources issues,
will in-directly expose this mis-detach token issue as the above.
Beside, the handling of WindowTokenClient#{onConfigurationChange,
onWindowTokenRemoved} does not thread-safe since this is called from
IPC.
As the result, the fix is to ignore the check in ContextImpl#finalize
to not detach the token when it managed by WindowProviderService,
also make sure to post to the main handler when received
onConfigurationChanged/onWindowTokenRemoved in WindowTokenClient.
Note that this fix could help to resolve "The Window Context should
have been attached to a DisplayArea." exception if the token has been
detached as the above case that happens before the next
WindowProviderService#attachToWindowToken invoked.
[1]: I64a1614f32d097785915f6105b1813a929e0fe32
[2]: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
[3]: Ic592a1d2fb2da149220c8b503b522b3e864bcc77
Bug: 213118079
Bug: 211062619
Test: manual as steps:
1) adb install -r EditTextVariations.apk
2) adb install -r SoftKeyboard.apk
3) adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
4) adb shell ime set com.example.android.softkeyboard/.SoftKeyboard5
5) Enable screen auto-rotation
6) Launch EditTextVariations from launcher's shortcut
7) Tap the first EditText field to show IME
8) Rotate the device to the landscape mode
9) Expect the IME should not be shrunk
Change-Id: I7beb7a122af93e596239a36db62073233cea0726
Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I9ad876043fd61f708a8f468fffd1ef371bfa0866
postOnAnimation is not robust enough from remove the onDrawListener
before next traversal, add a flag to to ensure that transfer splash
screen view only been called once.
Bug: 204125440
Test: atest SplashscreenTests
Test: verify SplashScreenTests and SplashscreenParametrizedTest pass
Change-Id: Id0e6d57b901b2dae45f5aa77e5571f9cf81b6e29
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
- 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
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
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)
On "traditional" devices, this method switches back to the "primary"
user, which is the system user. But on devices running with headless
system user mode, it should switch to the previous user instead.
Test: manual verification (TestDpc/CtsVerifier) on car and phone
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testCreateAndManageUser_LogoutUser
Bug: 204483021
Change-Id: I3ccbc1f31f8bcc4dae8fcb71cf5de7a7ad8882fe
This ensures that a locusId change will trigger an
onTaskInfoChange immediately. Previously it would just
be sent with the next info change event which isn't
sufficient.
Test: atest NotificationManagerTest
Bug: 204260661
Change-Id: I2b53f63b6efd6d2c22a877b7c33f5a12832a8e1d
The APIs are deprecated (in favor of setRequiredPasswordComplexity())
and some automotive OEMs might not even provide the option to
set passwords (just PINs and patterns).
Fixes: 204252236
Test: atest CtsDevicePolicyTestCases:android.devicepolicy.cts.DeprecatedPasswordAPIsTest # on automotive and phone
Change-Id: I6272bdd0e893f6fd8f1d126d384d1b332e61bac2
