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
There's a common misconception (even across the framework) that
View#onVisibilityChanged determines and reports visibility on 'this'
up to the changed view and the total visibility within the
window. Knowing this is useful for things like starting/stopping
animations. onVisibilityChanged only reports the visibility for the
specific changed view, not the effects that would have down the tree.
Add onVisibilityAggregated to report what some code thought it was
getting already, and move ImageView and ProgressBar over to using it.
Bug 27461617
Change-Id: I433f41de453e27a53f907f1d9805350f30f31de9
Summary:
This CL introduces a unified mechanism to deal with the situation
where the application directly implements InputConnection but some of
methods are not implemented. Note that there should be zero overhead
when the application extends BaseInputConnection or
InputConnectionWrapper.
Background:
When ever we add a new method to InputConnection, there has been a
risk that existing applications that directly implement
InputConnection can get java.lang.AbstractMethodError exception at
runtime, because older SDKs do not require the application developer
to implement the methods that are newly added in later SDKs. Because
of this we strongly discouraged developers to directly implement
InputConnection interface, and encouraged them to subclass
BaseInputConnection or InputConnectionWrapper instead. That said, as
requested in Bug 26945674, there is a certain demand to be able to
implement InputConnection without depending on BaseInputConnection.
The goal of this CL is to provide a reliable and sustainable solution
to above missing method scenario in InputConnection.
One of the reasons why dealing with missing InputConnection methods is
so difficult is that what InputMethodService receives to communicate
with the target application is actually a proxy class
com.android.internal.view.InputConnectionWrapper
that runs in the IME process and immediately returns true for most of
methods in InputConnection such as #commitText() and
#finishComposingText(). Because of this asynchronous nature, it is
too late to change the actual return value that the IME receives when
the application receives those one-way asynchronous IPC calls.
Solution:
To handle those cases, this CL checks the availability of
InputConnection methods that did not exist in the initial release
before the target application calls startInput(), and let the
application to send its availability bits to IMMS so that
InputConnectionWrapper running in the IME process can be initialized
with such availability bits. Note that we do know that
BaseInputConnection and its subclasses support all the InputConnection
methods, hence for most of applications we can just assume that all
the methods are available without reflection.
With such availability bits, InputConnectionWrapper is now able to
gracefully return failure code to the IME because the availability of
those methods is immutable, except for a tricky case where the
application relies on a proxy object that dynamically changes the
dispatch target.
Here is the list of APIs that we start checking the availability in
this CL.
[API Level 9+]
- InputConnection#getSelectedText(int)
- InputConnection#setComposingRegion(int, int)
[API Level 11+]
- InputConnection#commitCorrection(CorrectionInfo)
[API Level 21+]
- InputConnection#requestCursorUpdates(int)}
[API Level 24+]
- InputConnection#deleteSurroundingTextInCodePoints(int, int)
- InputConnection#getHandler()
Ideas alternatively considered: Default methods in InputConnection
We once considered having default methods in InputConnection but
abandoned this idea because it does not directly solve the problem
about how to tell the that the API does not take effect.
Also having default methods would make it difficult for application
developers to be aware of newly added methods in InputConnection.
Bug: 27407234
Bug: 27642734
Bug: 27650039
Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64
Hides the wallpaper when it's not needed and fixes
the unlock animation to not unnecessairly show the
wallpaper if neither the Keyguard nor the underlying
app need it.
Also fixes a bug where the enter animation had a background
set, which led to uglyness when no wallpaper is involved.
Bug: 27533740
Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
FLAG_LAYOUT_NO_LIMITS allows a window to extend its dimensions outside
the screen area by setting the display frame to a really big value.
We don't want this in multi-window mode since all window frames should
be limited to their parent task/stack dimensions.
Bug: 27577275
Change-Id: Ie0a8b8c13de91561e06dadc27aac3a5ba209d05b
