| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case the insets animation frame will not be scheduled by render
thread when the host window was not visible to user, added
ViewRootInsetsControllerHost#isVisibleToUser to check when invoking
applySurfaceParams to schedule the next frame, if the host was not
visible means we don't have to synchronize with the window host and
just apply the surface transaction on the UI thread directly.
Fix: 206992027
Test: manual as steps
1) Receive any incoming message
2) Tap on inline reply to show the keyboard
3) Tap on the voice input button on the keyboard
4) when permission dialogue prompts on the screen, expecting both
notification shade panel collpse animation and IME hiding animation
are working fine without any stucked frame.
Change-Id: I266587d5a3f136149d116214e2a49de92466ec2e
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
491d113504
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/17378203
Change-Id: Idf7d59382d9cae3161c10655e4533a42ebc5b080
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We should compare the existing appearance with the new appearance which
is about to be applied to insetsFlags.appearance, not the raw appearance
from the argument, before deciding if we can skip it.
Bug: 224613946
Fix: 226227461
Test: atest WindowInsetsControllerTests#testSetSystemBarsAppearance
Change-Id: I1283089a3dadf4ca2c3136f80d1472a34351306a
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 7eb2bed 'Apply Insets animation when hw acceleration unavailable'
has been applied, apps running without hardware acceleration have been
able to animate without any frame sync for now.
However, unlike the intention, the animation may not be performed
forever. Because the frame number -1 was intended as a very early frame
number that guarantees to show. But native BBQ accepts it as the
maximum frame number which can not be reached permanently for showing.
Because native BBQ takes the value as unsigned long long type (signed
-1 to unsigned maximum).
This change involves the following:
- Fix the misuse of the very early framenumber in
ViewRootInsetsControllerHost.
- Treats all -ve values as 0 so BBQ doesn't cast it incorrectly.
Bug: 206482421
Signed-off-by: Hyeongseop Shim <hyeongseop.shim@samsung.corp-partner.google.com>
Change-Id: I87faf440fc657c43fd67caa8644ecbc971187d84
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InsetsState contains much more information than visibilities, such as
display frame, display cutout, rounded corners, privacy indicator
bounds, and frames of of insets sources. The control target only needs
to send the requested visibilities to WMS, so it can be too heavy to use
InsetsState.
This CL introduces an new class, InsetsVisibilities, which only contains
which type has which visibility. So it uses less memory, and it is more
efficient on copying and checking the equality.
Fix: 194186241
Test: atest InsetsVisibilitiesTest WindowAddRemovePerfTest
InsetsControllerTest RegisterStatusBarResultTest
CommandQueueTest LightsOutNotifControllerTest
ActivityRecordTests DisplayContentTests
DisplayPolicyLayoutTests InsetsPolicyTest
InsetsSourceProviderTest InsetsStateControllerTest
WindowFrameTests WindowManagerServiceTests WindowStateTests
Change-Id: I86c1b26b4383bfa3b924726d580e5706e13ba735
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the appearance or the behavior are not controlled by APIs,
InsetsController will still return the default values, but the
internal logic will access the real value.
Fix: 192635471
Test: Open an app which hides system bars with
SYSTEM_UI_FLAG_IMMERSIVE_STICKY, but not
BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE.
Change-Id: I1c2f947e3707fcb4c151c1ad19c9cd16527e11d9
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, we only dispatched onEnd if onStart was already dispatched. However,
some animations might get cancelled after onPrepare but before onStart. In that
case, it is rather tricky for apps to actually cancel the animation.
Now we always dispatch onEnd if onPrepare has been dispatched already.
Fixes: 177983907
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I3fa142110bd5593679f87561c138ed3318034fca
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the calling thread releases the SurfaceControl passed
to SyncRtSurfaceTransactionApplier concurrently with the
applier preparing the transaction, this can lead to a
synchronization error and a crash. Once the state is
inside the transaction no further synchronization is required
as the native transaction will hold its own sp<SurfaceControl>
reference. By constructing the Transaction on the calling thread
and deferring application to the RenderThread we enable the calling
thread to not have any release synchronization requirements with
RenderThread.
Bug: 186391509
Change-Id: I585e1a9d3baf9ea384b00408b6253f34487d5037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The server won't dispatch the legacy content insets, stable insets, and
visible insets to the client. The insets would be computed from the
insets state by the client.
This CL also fixes the insets scaling issue in compatible mode.
Bug: 149813814
Fix: 169940916
Fix: 165412978
Test: atest WindowAddRemovePerfTest InsetsAnimationControlImplTest
ActivityRecordTests DisplayPolicyLayoutTests
InsetsPolicyTest InsetsStateControllerTest
Change-Id: I83570973f587a6abf887752494f750b46e3e484d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new logic sends the requested visibility to server even when the
client doesn't have a control. This makes the requested visibility
reliable at the server side.
This CL also changes getRequestedState to getRequestedVisibility in
WindowState, because the frames in getRequestedState are not reliable.
Fix: 161247175
Fix: 166819574
Test: atest DisplayPolicyLayoutTests DisplayPolicyTests InsetsPolicyTest
InsetsSourceProviderTest InsetsStateControllerTest
WindowStateTests InsetsAnimationControlImplTest
InsetsControllerTest WindowAddRemovePerfTest
ActivityRecordTests
Change-Id: I7d32dacaa1302bab61386f5bd69aaa7dde953ebe
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During transitions and while the IME is controlled by the app,
the IME may be "visible" as far as the IME framework is concerned,
but not actually perceptible by the user due to offsets or alpha
applied to the leash.
This may lead to out-of-place navbar symbols for the IME, especially
in gesture nav.
To avoid this, the ImeInsetsSourceConsumer now notifies the IMF of
whether it has made the IME unperceptible to the user.
For now, we ignore the cases where the IME is controlled by something
other than the client window - in that case, we just revert to the
previous behavior of it being always considered perceptible.
Fixes: 158079255
Test: manual, launch email compose activity, observe that back button only indicates once IME appears
Test: atest InsetsAnimationControlImplTest
Change-Id: I4dc9d6513d0559156f7da39244f3fc5ebc952ed4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When IME has zero insets, it doesn't map to any side and doesn't have
can't be animated.
IME can have zero insets in following cases:
1. Floating IME
2. Fullscreen IME (in landscape)
3. IME doesn't overlap with IME target window.
In order to animate a type, it must have insets. We can animate IME
from negative insets to zero and vice-versa. This makes zero insets IME a
special case of ISIDE_BOTTOM.
Deprecate SIDE_FLOATING because it shouldn't logically map to a side.
Fix: 153909316
Test: atest WindowInsetsAnimationImeTests#testZeroInsetsImeAnimates
Change-Id: I6d1d3430888db4632cb2f93e9042f692b35ebaeb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
eEarlyWakeup flag is used as a hint to SurfaceFlinger to adjust its
offsets so it can wakeup earlier and have sufficient time to compose
more complex scenes.
This flag has been replaced with explicit start and stop flags which
ensure the SurfaceFlinger offsets remain consistent during animation.
Bug: 158127834
Test: go/wm-smoke
Test: systrace to verify new tracepoint and offset behavior
Change-Id: Ib9c35c01a6bf02f88ec7cb1778e01909bd2f9055
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add more dumps and logs to better help debug IME insets better
Logging can be enabled by setting InsetsController.DEBUG to true.
Bug: 154348613
Test: manually build and flash.
Verify showing and hiding IME shows logs.
verify adb shell dumpsys window windows has new dumps
Change-Id: Iad0a21d81a22d6acfaaf5c5ca8b5131eec411e79
|
| |
|
|
|
|
| |
Test: WindowInsetsAnimationSynchronicityTests#testShowAndHide_renderSynchronouslyBetweenImeWindowAndAppContent * 100 times
Fixes: 155602643
Change-Id: I6f736357f5a67c01a29b2c531026a3a76c321003
|
|
|
Such that all it's goodness can also be used in context when
ViewRootImpl isn't available, like the SystemUI controller used
for Car and Split
Test: InsetsControllerTest
Fixes: 154631128
Change-Id: I54a3f8a34810472d9273e4627a7811b7abd0863f
|
