am: ac94586
* commit 'ac945867145c571506a211ccb0a87a3402c4d745':
Refactor usages of Picture In Picture and Multi Window (1/4)
Change-Id: I34a274c3eca15546d7be85fbb30ac072ff03db7f
am: 394d3df
* commit '394d3dfb2d9ccd2ca2fd7aad06ef2e9a8458a0c7':
Hide children in ViewGroup.createSnaphost via internal flag and add test for it.
Change-Id: Iab1265b6a4c4ff5291259f7e5d9b96c217ee3141
This is an input consumer similar to the one used when hiding the navbar,
but placed above wallpapers. It might be useful for processing touch
events over "desktop" in freeform MW mode.
Bug:26688904
Change-Id: I9d6d28a624f750ad48fc39f9b149dd1f989cceba
am: 6bb61e2
* commit '6bb61e25a2831dc14b604327a995c36309dfcbc9':
Revert "Run cleanup before end actions of ViewPropertyAnimator."
Change-Id: I2254f4f2dfa19711fac8ed90e72addb94f4e26b8
This reverts commit e9a4f87852.
This revert is to test to see if the gralloc lock problems are caused by this CL.
Change-Id: I395fd3675dd430c44a5d29b050ba248f3f2bf4cd
It turns out that BaseInputConnection has still depended on a private
API named BaseInputConnection#reportFinish(), which was introduced
4 years ago to work around a UI freeze due to an unbalanced batch edit
count [1]. Note that such an unbalanced batch edit count cannot always
be avoidable. It can easily occur in the following situations.
- The current IME crashed during batch edit.
- The user changed the View focus during batch edit.
- The current IME called IMM#switchToNextInputMethod() during batch
edit.
The remaining problem is that #reportFinish() is still an internal API
and only subclasses of BaseInputConnection can implement it, and IMM
calls it when and only when the current InputConnection is
BaseInputConnection or its subclass. InputConnectionWrapper and any
other InputConnection implementations will never receive such a callback
to clean up InputConnection#{begin, end}BatchEdit(), which is considered
to be a major contributor to UI freeze.
To address the above issue, we unhide BaseInputConnection#reportFinish()
as InputConnection#closeConnection() so that application developers can
receive an appropriate callback to clean up internal state including
unfinished batch edit.
[1] I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
9d69ecbf61
Bug: 24688781
Bug: 25332806
Change-Id: I234309c5880c9fe0b299b8bd0f8862796d4dda0d
The extras may contain custom Parcelables which aren't in the
system's default classpath, so touching them would end up clobbering
the contents.
Update code to leave the parcelled data untouched inside the bundle
until someone tries reading the extras.
Bug: 27897919
Change-Id: I99381dd50c9a0e8887667076362ea98805f0437c
We need to change the SurfaceView size from the UI thread
so that we can appropriately deliver the SurfaceChanged
callback. We also need to not preserve geometry
in this case, as if we don't update the surface
and layout size together we could get scaling. This still has
some potential for holes, as transactions are not synced with
the parent renderer, but we have other methods to avoid
these in the case of resizing. This fixes the remaining
issues with content sizing and surface view "out of sync".
Bug: 27780983
Bug: 27687126
Bug: 27676101
Change-Id: Idd7864f00e5cf7a4eb32dd66c0b389292a788069
am: 58cf2c3
* commit '58cf2c3da028c9e091eed03868eaaa38625b12b7':
Run cleanup before end actions of ViewPropertyAnimator.
Change-Id: I4ea31dc25223445e2aab2f2ab0c69030a53b57f3
This reverts commit 3127c2a471.
The original CL caused various issues for which we don't have the
time/not willing to take the risk.
Bug: 27864389
Bug: 27451341
View.hasOverlappingRendering() is an important performance tweak that
subclasses can override to do the right thing return false when appropriate
to avoid expensive operations when view is translucent).
But this requires subclassing View to get this behavior.
This new API allows the property to be set from outside, enabling
standard views to have this behavior set. When the new method is called,
the behavior will derive from whatever it was set to. Otherwise, it
will default to the old/overriden behavior.
Issue #16561361 Make hasOverlappingRendering settable from outside/XML
Change-Id: If0fbc8667cdb82b1d85e795e782716a07196f3c0
Bug 27788719
The end action of a ViewPropertyAnimator may do anything,
including starting a new animator. If the next animator has
started prior to cleaning up the previous one, it will capture
the dirty state as the final state. This CL runs the cleanup
Runnables before running the end actions so that any captured
state is the clean state.
Change-Id: Ib005b817d420e79b636e61987669a852e15df9ce
Currently the default implementations just swallow
the calls. This CL fixes this by re-dispatching
them up the tree by default.
BUG: 27611756
Change-Id: Ib31938dca34cd956e78d746321716a51cbd9dcd6
- Cache shouldAlwaysConsumeNavbar so it doesn't get reset when
insets == null
- Remove logic with frame comparison when determining whether to
consume nav bar. Not sure how that ever worked.
- Make sure shouldAlwaysConsumeNavBar survives when consuming
insets.
Bug: 27157904
Change-Id: I35f209ab27cc12240038da7efa9e79c95f70c6ce
- Also get rid of USE_MT_RENDERER, because there is no point in
having a flag if the other path never gets tested.
Bug: 27738239
Change-Id: Ic76115962940e72f2c59b8d291d078d15f8d493c
- Ensure initial magnified and available regions are set
- Correctly offset magnified bounds by left coordinate
- Cancel ongoing animations before unregistering callbacks
Bug: 22718911
Bug: 27871383
Change-Id: Iaff63be856598d1f8edb2d94158bbd75045c86ec
This is a preparation CL to fix Bug 27858665. In order to debug issues
like this, we want to record following information about View.
- Whether the View is focused or not.
- Whether the Window to which the View belongs is focused or not.
- Whether the View belongs to a Window or not.
This CL has no impact on production build where IMM#DEBUG is false.
Bug: 18920212
Change-Id: I06bcd5e42d55f96a9e916eb34ed7785cfe14c96f
With the previous commit [1], now Bug 27868748 is fixed and Bug 6789252
is no longer reproducible even without a workaround [2] for that. Hence
this CL logically reverts [2] in favor of simplicity.
[1]: If2a03bc84d318775fd4a197fa43acde086eda442
aaa38c9f1a
[2]: I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929
Bug: 27868748
Change-Id: Ic59af43343eb44d1d2c23a3f4018565e7a75b143
This attempts to reland previously reverted CLs [1][2] due to an
unexpected regression (Bug 27824691).
The Bug 27868748 we want to address by this CL is that currently
InputConnection#finishComposingText() can be called on the root view's
Handler no matter what Handler is associated with
ControlledInputConnectionWrapper. Actually the root cause of
Bug 6789252 is the same, but there we worked around it by not calling
InputConnection#finishComposingText() in certain situations [3].
With this CL we should be able to logically revert that workaround.
This CL also removes redundant IMM#mServedInputConnection. This is safe
because the following two fields have the same lifetime.
- InputMethodManager#mServedInputConnection
- InputMethodManager#mServedInputConnectionWrapper
We do not need to maintain both of them. This also allows us to use a
strong refecente in IInputConnectionWrapper#mInputConnection instead of
a WeakReference. To understand why this is safe, we need to understand
how things previously worked, which is as follows:
1. InputMethodManager#mServedInputConnection becomes non-null.
-> IInputConnectionWrapper#mInputConnection.get() is guaranteed to
be alive.
2. InputMethodManager#mServedInputConnection becomes null or another
object.
-> IInputConnectionWrapper#mInputConnection.get() may not be alive.
Since we know exactly when InputMethodManager#mServedInputConnection is
updated, in theory we do not need to use WeakReference here, and
with this CL we do not use WeakReference anymore. Actually the initial
commit [1] accidentally removed the last strong reference to the active
InputConnection and WeakReference could be null at any time, which was
what we observed in Bug 27824691.
[1]: I1181e067aa5bedbdf0c7ec1bcec479257aea511c
afb6558c8f
[2]: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
16e2c7b59a
[3]: I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929
Bug: 27868748
Change-Id: If2a03bc84d318775fd4a197fa43acde086eda442
