Fixing a typo in the previous commit: s/remove/put/
Bug: 153013604
Test: ran CTS tests on sdk_gphone_x86
Change-Id: Iabe8ce51f38ac921aa5cc0e78b559e4a512b9273
This will be used by FlickerTests to capture composition state
in SurfaceFlinger trace.
Test: atest FlickerLibTest:LayersTraceMonitorTest
Fixes: 153563549
Change-Id: I3d09196ced43a1b0bac811e8f458c28be4e44992
As the final enabler for the BLASTSyncEngine, we add a new relayout
result BLAST_SYNC. If the WindowState is participating in a BLAST sync
during relayout we return it to the client. If we return it to the
client the client will direct it's next draw in to a BLAST transaction
and report that transaction via finishDrawing. You can now observe
the BLASTSyncEngine working end to end in TaskOrganizerMultiWindowTests.
We do a few small clean-ups in TaskOrganizerMultiWindowTest while we
are there.
Bug: 153561718
Test: TaskOrganizerMultiWindowTests
Change-Id: I719b731350b942aafa444a33972aaef8973422ea
The root causes of this issue are:
1. WindowTokenClient#attachContext makes WindowTokenClient has strong
reference to WindowContext, which leads to WindowContext cannot be
GC'd.
2. WMS#removeWindowToken needs MANAGE_APP_TOKEN permission which
normal apps don't hold.
This CL does following things:
1. Use weak reference instead on WindowTokenClient#mContext.
2. Relax WMS#removeWindowToken to check callingUid if
MANAGE_WINDOW_TOKEN permission is not held
3. Deliver config changes to the client side in
WMS#addWindowTokenWithOption
4. Some minor fixes
fixes: 150812449
Bug: 150715095
Test: atest WindowContextTest
Test: atest WindowManagerServiceTests
Test: atest WindowTokenTests
Test: atest WindowManagerPermissionTests#testMANAGE_APP_TOKENS
Test: atest
WindowManagerPermissionTests#testADD_WINDOW_TOKEN_WITH_OPTIONS
Change-Id: I9f1d73af2abb78fc9844e6d9eb25e9f0293514e7
Add a comment explaining the permissions necessary for a successful call
to acquireFrameRateFlexibilityToken(). This is feedback from a
previously submitted CL.
Change-Id: Id316e6943153c20a06d90af844605851591e225c
Bug: 148033900
Test: n/a
When leash changes, we need to re-apply our local state, to ensure
new leash has same state as before and new leash is visible on
screen.
Test: Switch IME while open
Test: SurfaceControlTest
Fixes: 152876819
Change-Id: Ieae1aecdc3ddc427ccb89c4aa7ef7ae9283f39eb
A window might request to control insets before it is added to WM and
expect the first dispatched WindowInsets as requested.
The first insets state returned from addToDisplay or relayout might be
not expected if the window just become thecontrol target in the
function.
With this CL, WM can return controls from addToDisplay and relayout, so
that the client can apply controls immediately, and update controlled
insets sources before dispatching the insets to the view hierarchy. This
enaures the insets dispatched are up-to-date.
Fix: 150756571
Test: atest WindowInsetsControllerTests RelayoutPerfTest
WindowAddRemovePerfTest
Change-Id: Ib78c24beb7af5a54ad78935c3ddb260ef9645212
This reverts commit 8c56ac6b94.
Underlying issue has been fixed:
Test: InsetsControllerTest
Bug: 152071027
Change-Id: I2b80de7067bf688a6b36233b9a1e92e2cf31c148
Add support for temporarily relaxing frame rate restrictions in surface
flinger. This is used by CTS tests to get a consistent device state
while running frame rate tests.
Bug: 148033900
Test: - On a Pixel 4, I turned the brightness down and covered the
ambient light sensor, causing the display manager to set a frame rate
restriction. I ran the frame rate CTS test without these CLs applied,
and confirmed the test failed because surface flinger couldn't switch
frame rates, as expected. Then I ran the tests with the CLs applied, and
confirmed the tests pass.
- I confirmed that, without adopting shell permission identity, the CTS
test is denied the request to acquire a frame rate flexibility token. So
normal apps won't be able to access this.
Change-Id: Ie2b611cf5726c14a7a22e315a85bf6200d190682
If BLAST is enabled and we somehow end up in positionLost or
setParentSpaceRectangle without having called setUseBLASTSyncTransaction
we will end up putting operations in to a Transaction which will never be
applied. This condition should be considered a bug, but it's best to
defend against it. To compensate, rather than checking the global
use BLAST flag, we check if the current draw is actually using
BLAST.
Bug: 152663327
Bug: 152780239
Test: Existing tests pass
Change-Id: I3c05b83400b59be82a339933fc8ef1382d4f0e21
If visibility changes we will try and hide the Surfaces from
the RT. We want to sync this with ViewRoot drawing so
we enable BLAST sync for the next frame in this case.
Bug: 152663327
Bug: 152780239
Test: Existing tests pass
Change-Id: I9cd157954a3ce87a8f95a7be97d6d5c7f324327b
