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
- 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.
This is a safe refactoring to remove an unnecessary int to String
conversion in TextServicesSettings.
Settings.Secure.SELECTED_SPELL_CHECKER_SUBTYPE is a integer value that
indicates subtype ID (or SpellCheckerSubtype#hashCode() if the subtype
ID is not specified), and we can just rely on
Settings.Secure#putIntForUser() rather than converting int to String
by ourselves then pass it to Settings.Secure#putStringForUser().
Note that this change is still OK for existing users because
Settings.Secure#putIntForUser() has been internally doing exactly the
same thing.
Bug: 27687531
Change-Id: Ibcf12746f1295c12bec095300ea7f6ced0a51d09
It's easy for apps to throw custom Parcelables into Bundles, but
if the system tries peeking inside one of these Bundles, it triggers
a BadParcelableException. If that Bundle was passed away from the
Binder thread that delivered it into the system, we end up with a
nasty runtime restart.
This change mitigates this trouble by "defusing" any Bundles parsed by
the system server. That is, if it encounters BadParcelableException
while unpacking a Bundle, it logs and delivers an empty Bundle as
the result.
Simultaneously, to help catch the system process sticking its
fingers into Bundles that are destined for other processes, a Bundle
now tracks if it's "defusable." For example, any Intents delivered
through ActivityThread are marked as being defusable, since they've
arrived at their final destination. Any other Bundles are considered
to be "in transit" and we log if the system tries unparceling them.
Merges several Parcel boolean fields into a flags int. Add better
docs to several classes.
Bug: 27581063
Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
Change the args for onVisibilityAggregated to a single boolean for
visibility to the user. Also fix an ordering bug that could trigger a
view background drawable call to setVisible before the view would
respond true to verifyDrawable, which caused issues with some apps.
Bug 27461617
Bug 27689884
Change-Id: I58bdc7c4364264f7fa0863689ba2b76df904ef81
