The existing Keyguard Occlude Animation Runner doesn't match the spec
for Dream in. It animates activity expanding from the center of the
screen. For Dream in, we have:
- Dream fading in
- DreamOverlay complications fading in slightly delayed, with each part
starting at different times.
This CL adds dedicated AppTransitionType and remote animation runner,
which animates Dream fading in. It doesn't implement the separate
animation for DreamOverlay complications.
Bug: 222507937
Bug: 240477956
Bug: 242864189
Fix: 240477956
Test: on device, wait for Keyguard to time out to Dream.
Change-Id: I5517ded2eea77ea962ca1551ed51dd997ff09993
Merged-In: I5517ded2eea77ea962ca1551ed51dd997ff09993
The client needs to call relayout to get the valid surface if
- mFirst,
- mViewVisibility != viewVisibility,
- mNewSurfaceNeeded, or
- mAppVisibilityChanged.
We didn't cover mNewSurfaceNeeded or mAppVisibilityChanged previously.
All of them are covered by FLAG_WINDOW_VISIBILITY_CHANGED.
Bug: 244521023
Bug: 161810301
Test: 1. Enable LOCAL_LAYOUT
2. Open Camera and double press the power button.
See if the preview screen of Camera become blank.
Change-Id: I37fb8ffc9063b72bf3abba5d29fc2f750e7fc64f
When the program is run to unlockCanvasAndPost method,
if mSurface.unlockCanvasAndPost throws an exception,
the mSurfaceLock.unlock() will not getting the chance to execute.
If an app executes unlockCanvasAndPost in a catch and does not handle the exception,
it will remain locked for a long time after the next execution of mSurfacelock.lock.
make sure the msurfacelock.unlock is executed after unlockCanvasAndPost
bug:245050059 in partnerissuetracker
Change-Id: Ib849c840c61ac261cfaab0daefa7ae2afdbfcba3
Signed-off-by: xiaoxin <xiaoxin@xiaomi.corp-partner.google.com>
This stores the computed decor insets and frame excluding insets.
So it can save 99% time of recomputing the insets every time during
starting an activity. E.g. dozen times of "prepare display info/frame,
compute window layout of insets source windows, calculate insets"
becomes "get result from array".
The saved decor insets will be updated when:
- Display metrics is changed (DC#updateBaseDisplayMetrics).
- Insets provider is added/removed/changed.
Also
- Use DisplayCutout rather than WmDisplayCutout to simplify
passing the cutout between methods.
- Optimize getSourceProvider to avoid unnecessary object allocation.
This also fixes an issue that the display doesn't compute the latest
configuration when navigation mode is changed. Now it is fixed by
checking if the insets provider has layout changes and then recompute
screen configuration.
Bug: 238399969
Bug: 159103089
Test: atest DisplayPolicyInsetsTests DisplayPolicyLayoutTests
DisplayPolicyTests#testUpdateDisplayConfigurationByDecor
Test: Change navigation mode or display size (density) in Settings.
And then swipe-up or press home key, there won't be a
frozen effect (display configuration change).
Change-Id: If6c28a89939372e6362b92f469ef7d793e8ec215
The ArrayEquals, ArrayHashCode, ArrayToString, and
ArraysAsListPrimitiveArray errorprone findings were
demoted from errors to warnings. Fix existing
occurrences of them so they can be made errors again.
Bug: 242630963
Test: RUN_ERROR_PRONE=true m javac-check
Change-Id: Ia6f216cc36ad0a5758f39fd9b34962cd4adf9d8e
The original patch reverted as commit
bc0d5539e6.
This patch only includes the part of refactors to make the calculation
of configuration around insets easier. The actual change of making extra
navigation bar treated as navigation bar and the fix of the UiDevice in
ui automator is in a separate patch to avoid being blocked and blocking
other changes for long.
Test: PlatformScenarioTests
Test: TaplTestsQuickstep, ThemeIconsTest, TaplTestsLauncher3
Bug: 238981445
Bug: 238985243
Bug: 238581838
Bug: 233945217
Change-Id: If966bcc8125300d47d5cd631f7db17ff027e5261
This passive window inset animation control listener
is used to for logging purpose when hide, show
method is called.
Test: atest InsetsControllerTest
Bug: 240192346
Change-Id: I399268ead9d04b356f10cc3e9ac1da9e31306e86
This fixes issues with Views that have their own custom
ViewTranslationCallback.
Bug: 236678324
Test: atest CtsTranslationTestCases
Test: manual - Verified on chat app that uses their own custom
ViewTranslationCallback; old and new messages are translated
Test: manual - Spot-checked translation on a few other chat apps
Change-Id: If4194bc8cde73a9cebb7b56594f6982855374410
IWindowSession#relayoutAsync is similar to IWindowSession#relayout, but
the former is an oneway method which just sends the layout attributes to
the server. Since the client can compute its own window frame, it just
needs to send attributes to the server without getting blocked for
receving the window frame.
In somes cases, the client still needs to obtain things from the server.
Such as:
- When view visibility is changed. The client maybe not be able to
receive the latest insets state while it is INVISIBLE or GONE. In this
case, the client needs to obtain the frame and the insets state. Also,
the client need to obtain the surface control when it becomes VISIBLE.
- When the insets state is stale but the config is up-to-date. This can
happen when WindowProcessController sends the new config to the client
before WindowState does. In this case, the client needs to obtain the
window frame from the server.
- When the position and the size of the frame are both changed. This
will trigger a BLAST sync, and the client needs to obtain the sync seq
ID.
For cases above, the client needs to call the original relayout method.
Bug: 161810301
Bug: 175861051
Test: Seamless rotation, fixed rotation, and regular rotation.
Merged-In: Ifb365789fa08103773fd3180e486ba1d92042fc5
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
