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
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
This reverts commit afb6558c8f.
It turns out that this CL caused a serious regression Bug 27824691.
Bug: 25332806
Bug: 27824691
Change-Id: I16312592743a6673449c492ee5ba533256d343ea
This reverts commit 16e2c7b59a.
It turns out that I1181e067aa5bedbdf0c7ec1bcec479257aea511c caused
a serious regression Bug 27824691. To revert that CL, we have to revert
this one first.
Bug: 25332806
Bug: 27824691
Change-Id: Iadfc226eb91cc969b77c9d98e04ec3c76fe86ead
This changes the current API given app feedback received. In order to use
keycodes as well as chars we also must implement a mapping of Keycodes to
Display labels as only keys with a single char representation are provided
by KeyCharacterMap.
Bug: 27409783
Change-Id: I3da653adc4b8cbc66a4d1aa24a5f9181f71e83c3
Before exposing #reportFinish() as a public API, we have to fix an
existing bug that my previous CL [1] for Bug 26945674 forgot to take care.
Currently BaseInputConnection#reportFinish() is always called by using
the root view's Handler. We should move the logic to call
BaseInputConnection#reportFinishInputConnection() from ViewRootImpl to
IInputConnectionWrapper to make sure that the method in question can
always be called on the desired Handler.
To make things simple, instead of explicitly calling #reportFinish()
from IMM, this CL let ControlledInputConnectionWrapper#diactivate()
internally call #reportFinish() as needed. This makes it easier to make
sure that #reportFinish() is called after all the queued method calls
are handled.
[1]: Id9e579bb3e2966986cdcb1c34bc8cacfeca2e1a9
612cce92ad
Bug: 25332806
Change-Id: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
Following two fields have basically the same lifetime.
- InputMethodManager#mServedInputConnection
- InputMethodManager#mServedInputConnectionWrapper
Hence we do not need to maintain both of them.
This is a preparation CL for Bug 25332806 and does not change any
user-visible behavior.
Bug: 25332806
Change-Id: I1181e067aa5bedbdf0c7ec1bcec479257aea511c
In framework views where we're handling the new visibility aggregated
call we only update the drawable visibility when we're attached to a
window. For old outgoing drawables being replaced, gate this on
whether the drawable is already marked visible instead.
This catches a case where views being inflated might set drawables in
in a superclass constructor and have them replaced in a later
constructor. Gating the call into a drawable that might invoke its
callback (the view being constructed) avoids potential problems where
overridden methods are called unexpectedly on a view subclass that has
not finished running its constructor.
This is a better check than isAttachedToWindow, as isAttachedToWindow
will return false if the view has been temporarily detached from its
parent by a view-recycling container. In those cases, the view would
not correctly update the outgoing drawable.
Bug 27461617
Change-Id: I733a2dd3e3df0a8d80d5dc542ca7b30064159d5d
This causes scaling to be applied in the relayout window since the
requested size won't match the window size. Apply the requested size
in repositionChild instead.
bug: 27676101
Change-Id: I03beee2b9fe118a6be329b5fd1338d54e48d9a22
enableAccessibility is refactored from EnableAccessibilityController to
AccessibilityManagerService. Also added are 2 methods disableAccessibility,
and isAccessibilityEnabled.
Bug: 27645255
Change-Id: I32d75ed6617b8bcf82bbee0dd5ee776f430fb386
(cherry picked from commit 84da556422d50e43eb674061cc454f331104d493)
The root cause of memory leak crbug.com/595613 was that Chromium and
WebView have called InputMethodManager#showSoftInput() with
ResultReceiver thta has a strong reference to application logic class
named ContentViewCore. In this particular case, ResultReceiver in
question will be copied to InputMethodManagerService and the current
InputMethodService, which means the original receiver object will not be
collected until the copied objects in other processes are GCed.
Probably there might be several ways to oprimize the performance in
Framework side because the corresponding ResultReceiver objects will be
always handled within the Android Framework unless IME developers
explicitly override the following method.
InputMethodService#onCreateInputMethodInterface()
Anyway, it is probably a bit too late to do such an optimization in N,
and application developers need to support existing versions of Android
anyway. For N, probably making it clear in JavaDoc would be the only
realistic improvement we can do.
Bug: 27658034
Bug: 27727645
Change-Id: I6fc6b88c91a4b1e0a29e94b99a9f0e35605c01b2
attachViewToParent is generally used for finishing a temporary detach
of a view as seen in ListView, etc. Have it dispatch aggregated
visibility to the newly added view so as to correctly update the view
as to its new state.
Bug 27702014
Change-Id: Ie8a67c78d3edf401641d52ce10bddf7cb49796fe
* changes:
Add more @NonNull/@Nullable to TextServicesSettings.
Remove an unnecessary int to String conversion.
Add more @NonNull/@Nullable to InputMethodSettings.
