When the device is rotated while a Bubble is expanded, the following
things happen after the device rotation.
1. an activity of the Bubble is started, and app transition
TRANSIT_SHOW_SINGLE_TASK_DISPLAY is prepared.
2. the server waits until the Bubble activity draws contents on its
surface, i.e. an app transition is executed.
3. the server trigger ITaskStackListner#onSingleTaskDisplayDrawn
4. SysUI makes a Surface of the Bubble activity opaque.
Depending on the status of Bubble activity, another app transition can
be prepared before the first step above, which is sticky so prevents
taking the following steps.
This change allows to override an app transition which has already been
prepared, so an app transition TRANSIT_SHOW_SINGLE_TASK_DISPLAY is
always executed; thus callback is triggered.
Bug: 158675422
Test: manual, open a Bubble and rotate device several times.
Change-Id: I24fb649c1301e5f5a2443f3eaed166049b5f6108
After we made the DreamService use an activity, we introduced checks
that only the current active dream component can start a dream activity.
This meant that if the doze dream is in a different package, it would
get suspended.
This CL fixes that by whitelisting also the doze dream package.
Bug: 160109097
Test: m && flash && put two different dream as doze and active dream &&
check that the doze starts
Test: atest DreamManagerServiceTests
Change-Id: I553dd1d44f3303d18278482b4a4e88a5564a94d3
AOD status changed after keyguard was set as going away, which
reset mKeyguardGoingAway back to false and put activities to sleep.
Bug: 158640144
Test: Unlock keyguard during AOD2
Change-Id: I9335045668f90d477d19dada0185447bfa3cb2a7
InsetsSourceProvider#startSemlessRotation will be called and cancel
on-going insets animation to revoke the insets control.
The idea is preventing the frame of insets animation will be drawn while the
rotation is not yet stable, and re-apply the revoked control again once
the rotation finished.
However, since the IME insets control / control target / leash has been cleared
after animation cancelled, there is no way to update the revoked IME
control target again, and also cannot have a direct signal to request visible
for client side after finished rotation, that will casue IME surface
stays on and client can't control the IME inets visiblity.
As the issue case which seamless rotation happens during launch fixed portrait
rotation app from launcher in landscape mode, since seamless rotation
animation doesn't well support the target window which controlled IME insets
is animating, we should skip seamless rotation for this case.
Fix: 158924696
Test: manual as below steps:
1. Enable "Allow Home screen rotation" from Launcher -> Home Settings
and "Auto-rotate" from quick settings.
2. Open Snapchat in portrait > open a conversation > open keyboard.
3. Tap Home button > rotate device from portrait to landscape.
4. Tap Snapchat icon in landscape > the keyboard is automatically displayed
5. Tap the back key in the lower left corner of the device.
6. Expect keyboard should hide after the back key pressed.
Change-Id: I7d4685a0b85ec3db9b7e1c266030817da3dde812
Previously they were limited to frameworks/base so that they could be
combined into the "main" android stubs. However, limiting their
visibility is inflexible and unnecessary, and due to limitations in the
build system also makes it impossible to create rules for prebuilts of
these module stubs that set `prefer: false`.
This CL makes it possible to disable the prebuilts, which multiple
downstream branches would like to do.
Bug: 159902351
Test: m nothing (with prefer: false on prebuilts)
Change-Id: Id0eee4bf4e78f5dfddf6ad569e49719fefde658e
This broke several apps because it means certain NON_FOCUSABLE windows
are now layered wrong w.r.t the IME, and also no longer get IME insets.
Originally, this was introduced because the IME target was used to
compute which window gets control, but this is now computed based on
the window actually connecting to the IME as reported per IMMS.
Reverts I941571c97145d77b0a59d030cf2a8c8318f3b59f.
Bug: 143898978
Bug: 140641950
Bug: 145812508
Bug: 141738570
Bug: 144619551
Fixes: 159438771
Test: atest WindowStateTests
atest FocusHandlingTest
atest WindowManager_LayoutParamsTest
Also manually using steps:
1. Launch gmail compose activity
2. start typing in receipient field
3. verify that even thoug the suggestions popup
window w/ FLAG_NOT_FOCUSABLE becomes the
IME target, control and insets still work.
Change-Id: If451276b1a8c485ec88965d8d30ec8fd3836620f
-Media framework does not report "TYPE_GROUP" when selecting a group
of Chromecast devices or the StaticGroup
-MediaRouter2Info::getType() does not provide correct types for group
and video
-Add "getDrawableResIdByFeature()" to get correct type icon
-Use MediaRouter2Info::getFeatures() to get device type
-Designer updates the video icon
Bug: 160113560
Test: make -j50 RunSettingsLibRoboTests
Change-Id: I1c8e9c2729013b9ee49b664e40c04550f315a516
For hierarchical animation, there are missing some handling
around mNeedsZBoost, when closing an activity the transition did
not applied.
1. Move some codes around mNeedsZBoost from ActivityRecord to
WindowContainer so Task can also benefit from it.
2. TaskDisplayArea#assignChildLayers should combined needsZBoost
so this attribute can apply on root task.
3. If next top activity will move to top in #finishIfPossible
and the finishing activity is on top, provide it a higher layer
to remain on top. Otherwise user will see flicker because the
transition need to be applied until next activity resumed.
Bug: 159200318
Test: atest ActivityRecordTests TaskDisplayAreaTests
AppWindowTokenAnimationTests TransitionSelectionTests
Change-Id: I85ec3307b31444e09179abca30298af2ce538834
Previous in order to get better transition from lock screen to Dream, we skip the updateSystemUiVisibility by checking keyguard and occluded
states. But since the Dream become activity, there will be an opening app transition for DreamActivity, the original check condition should be able to removed now.
Ref: 4c1e3183ba
Ref: 380ecb81db
Bug: 159790735
Test: atest DisplayPolicyTests
Change-Id: I057e9b2f866c1deaaf41f50f75edc00f6849ea86
Media key events had been incorrectly dispatched to the
MediaSession2, which is closed from the app side, but
MediaSessionService didn't get the notification for it.
It may happen if MediaController2 from the MediaSession2 was
connecting and also MediaSession2 was closing. This fix ensures
that closing session is always propagated to the controller in
onConnect().
Test: Run following tests 10 times (previously flaky ~50%)
$ atest CtsMediaTestCases:android.media.cts.MediaSessionTest
Bug: 159865360
Change-Id: If16f8c665214614961f28f9406225af19fdad1a8
If the client doesn't change the insets, we use the dispatched source.
In this way, the task snapshot can have the same insets as the client.
Fix: 152931762
Test: atest TaskSnapshotControllerTest
Change-Id: Ib0315ce0a8ab32e1c653eeed725fecccb54b3aa8
