There are some apps that use the Surface object itself to indicate
changes. As a result, recycling the existing Surface object for
updates can lead to such apps ignoring events such as size changes.
This changelist restores the original behavior for legacy apps, where
the underlying native Surface object is recreated during updates.
Fixes: 62108743
Test: go/wm-smoke
Test: Open affected application, observe expansion to fullscreen when
nav bar disappears. Rotate to other orientation and observe
expansion to fullscreen.
Change-Id: I874602b6b8686c6ecb05cf7b1a04ec4b700ad3f9
- Unify logic for detecting availability of the accessibility button
- Ensure the initial visibility state is propagated to A11yMS
- Ensure services only receive availability callbacks for changes
Test: Manual, created test accessibility services
targeting specific breakages
Bug: 38345417
Change-Id: I2250b32830cdfc2ecdc1dff7b7130dced2c1db29
Let's first understand how mView could become null. Notice
at the beginning of performTraversals, there is a check that
mView != null, and so it is nulled while we are in the function.
mView is package private and there are only two places which assign
to it, ViewRootImpl#setView and ViewRootImpl#doDie. setView is guarded
by mView == null. But mView was not null (per the check at the beginning
of performTraversals) and so mView is being nulled by doDie().
doDie() only has 3 callpoints:
1. ViewRootImpl#die(). Here though, calling it is guarded by
!mIsInTraversal. !mIsInTraversal is unconditionally set at the
beginning of performTraversals, and so this isn't our caller.
2. ViewRootHandler, handling MSG_DIE. This runs on the same thread
as performTraversal, and so it can't be our nuller.
3. WindowManagerGlobal#addView. This must be our nuller.
We see WindowManagerGlobal#addView will call doDie in the case that
we attempt to add a view which we had previously set to be removed
but deferred removal of. Now we can construct a reasonable sequence
for getting here:
1. requestLayout(). Perform traversals ends up on handler.
2. removeView(). MSG_DIE ends up on handler, View ends up in mDyingViews
3. performTraversals is executed by the handler
4. From a callback initiated by performTraversals (e.g. measure)
the client calls WindowManagerGlobal#addView on the view which
was just removed.
5. We are still in performTraversals so MSG_DIE hasn't been processed
yet. This means that WindowManagerGlobal will perform the doDie
immediately nulling mView.
6. We return to performTraversals and crash.
We can see shortly after the offending call to doDie, a new ViewRoot will be
constructed and so whatever traversal we are doing on the old one doesn't
seem particularly important. It doesn't seem that we can do any better
than letting it fall through without crashing.
Bug: 38421184
Test: go/wm-smoke. Feed to the monkeys.
Change-Id: I55f310a3533175c9df4a82878be5a60fd01b80c1
To workaround a deadlock caused by bufferqueue locks
we force RenderThread over to use async mode which
we enable via eglSwapInterval(0)
Bug: 38372997
Test: steps in the bug
Change-Id: Ia305f73abbdd64ab0c25d1f7d32792cc6295a0ce
I will not pretend classes are interfaces...I will not pretend
classes are interfaces...
Bug: 62444724
Test: cts-tradefed run singleCommand cts -d -o --module CtsViewTestCases --test android.view.cts.SurfaceViewSyncTest#testSurfaceViewBigScale
go/wm-smoke
Change-Id: Iccca46edcd669430c32f31e9c7d8aba1db254f2d
This CL will be reverted once it merges into the next release branch
to re-introduce the proposed APIs.
This CL also makes the following code changes to preserve API
compatibility:
-- It keeps the recently added RemoteViews.clone() synchronized logic
intact, but moves it inside the method to avoid changing the API
signature.
-- It reverts the RttCall.read() behavior to the oc-dev logic, since
we can't throw IOException until we get an API level bump. (The
original logic returned null instead of throwing.)
Test: builds, boots
Bug: 62427252, 62431886, 62427329
Bug: 62468911, 62431162, 62428935, 62429096
Bug: 37290820, 37359238, 36886243
Bug: 30143923, 35761231, 62192626, 29829689
Change-Id: I83d723f598cb0ee1fe198e65debd86ef7fd0420c
View already checks if its layout is being updated when calling
notifyEnterOrExitForAutoFillIfNeeded(), but that doesn't prevent apps crashing
when the autofill process was triggered by another view.
Test: existing CtsAutoFillServiceTestCases pass
Fixes: 38198484
change-Id: I8e9435ddc4cf21fb648d39aace93f3af0e1fdf4f
- Add new Choreographer instance that runs on vsync-sf
- Use this new Choreographer for WindowAnimator, and remove all
the hacks around it
Test: Open apps and close apps, notice no stutter
Test: Screen zoom animations
Test: go/wm-smoke
Bug: 36631902
Change-Id: I988ae25645effc3ac20efa7cb9b68f23444da0d0
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Bug: 62271937
Change-Id: Ib3447281f3bd1abc811a25fc55ad55e34e155bbb
This is needed by VR to handle keyboards that display a window larger
than the interactable region
Bug: 62194867
Test: Manually with prints
Change-Id: I7288956ed8da8d24e7c46ffa8f27461f7abbca5e
(cherry picked from commit 56162a0a51)
Careless mistake on my part :). Sorry about that.
Test: Try an app with two SV like Netflix verify top SurfaceView doesn't occlude bottom one.
Bug: 62375611
Bug: 62113351
Change-Id: Ia33aabf8b8e276f70365d62b82f113ecd3bee2fa
This reverts a part of 2ae1bf568b
RecyclerView relies on the old behavior. Will un-revert this (with
targetSdk check) once we have a solution for RecyclerView
Bug: 38352147
Test: RecyclerView Focus tests now pass
Change-Id: I7b0dfda295cd75e407bbd39a948b5585f8ed6e08
