9f9afe526d1f8ad17c628fc9e1e839725ffe913e |
|
30-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Add IC#closeConnection(). 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 9d69ecbf61a4a142c3f4cbb9d5659faa6f85e832 Bug: 24688781 Bug: 25332806 Change-Id: I234309c5880c9fe0b299b8bd0f8862796d4dda0d
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
aaa38c9f1ae019f0fe8c3ba80630f26e582cc89c |
|
28-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Ensure IC#finishComposingText() is called on the correct Handler. 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 afb6558c8f5e0ee797b252558d7e529e3d946d8f [2]: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98 16e2c7b59aacf44df7aaa0d04e0228240907487f [3]: I66f51da1299532793ef8fa700f35b0811670f235 4e5184f929d2498714bc7734fe10b9b8810cb071 Bug: 27868748 Change-Id: If2a03bc84d318775fd4a197fa43acde086eda442
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
1fa5f594a26b00aa137703bb21e186910c1242c6 |
|
24-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Revert "Make sure to call back reportFinish() on the desired Handler." This reverts commit 16e2c7b59aacf44df7aaa0d04e0228240907487f. 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
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
16e2c7b59aacf44df7aaa0d04e0228240907487f |
|
23-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Make sure to call back reportFinish() on the desired Handler. 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 612cce92ad96eda1146c3abd2afa7aaa4d4f2b3f Bug: 25332806 Change-Id: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
d8636ea7ca78df83d6b04088eab7853f15f3e999 |
|
03-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
API Review: InputConnection This CL does nothing but rename some L API candidates in InputConnection class, as per requested. - requestUpdateCursorAnchorInfo() -> requestCursorUpdates() - REQUEST_UPDATE_CURSOR_ANCHOR_INFO_IMMEDIATE -> CURSOR_UPDATE_IMMEDIATE - REQUEST_UPDATE_CURSOR_ANCHOR_INFO_MONITOR -> CURSOR_UPDATE_MONITOR BUG: 17320996 Change-Id: I772c48ff18918e48a81e807b48ff907614485c09
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
72d35fa829549a138504dde35a42535a296f79cb |
|
29-Aug-2014 |
Yohei Yukawa <yukawa@google.com> |
Reject request when any unknown flag is speficied Currently EditableInputConnection#requestUpdateCursorAnchorInfo never returns false unless InputMethodManager is somehow unavailable. This is problematic, especifially when we add a new flag to EditableInputConnection#requestUpdateCursorAnchorInfo in a future release. With this CL, #requestUpdateCursorAnchorInfo does nothing and immediately returns false when one ore more unknown bits are specified. BUG: 17324806 Change-Id: I5601714b481e8efa0ad3337c0d093cfcf55eade3
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
a277db28e990d1f6f74ace0c32fe92401660a840 |
|
22-Aug-2014 |
Yohei Yukawa <yukawa@google.com> |
Remove CursorAnchorInfoRequest and related stuff This CL removes CursorAnchorInfoRequest and related stuff in favor of InputConnection.requestUpdateCursorAnchorInfo, which is more easy to understand. This CL also deprecates InputMethodManager#updateCursor and related stuff. Rationale: 1. The spec of #updateCursor says that it provides the cursor position in local coordinates, while the input method requires it in the screen coordinates. 2. #updateCursor has never been enabled in AOSP, because InputMethodManager#isWatchingCursor always returned false. 3. There has been no way to let InputMethodManager#isWatchingCursor return true. 4. In L, InputMethodManager#updateCursorAnchorInfo is introduced to address all the issues above. Given that we no longer need to support #updateCursor, CursorAnchorInfoRequest is overkill when we need to convey just a couple of parameters. BUG: 17185263 BUG: 17182367 Change-Id: I4a577bfd02b37b9e56c80b8b41bb25afa95dd8ef
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
ff328ae7438a9c5c2fe49c286833a30e25015e63 |
|
17-Jul-2014 |
Yohei Yukawa <yukawa@google.com> |
Add FLAG_CURSOR_ANCHOR_INFO_IMMEDIATE support in TextView This CL adds an initial support of CursorAnchorInfoRequest#FLAG_CURSOR_ANCHOR_INFO_IMMEDIATE for TextView. This implementation is not highly optimized yet, but it just works as it should. BUG: 16379288 Change-Id: Iecb32b4c4dcd7db14d8b2a0d929e1d64e161bc58
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
0023d0e0c4f5339b299d1eacbd4e7181c2fd271f |
|
10-Jul-2014 |
Yohei Yukawa <yukawa@google.com> |
Polish new IME API for L part 2: CursorAnchorInfo This CL addresses feedbacks from internal customers for new input method APIs that are mainly used for physical keyboard support in L. For performance reasons, #onUpdateCursorAnchorInfo is not called back by default and each input method has to enable this event notification explicitly whenever fine-grained character locations are needed. In L-preview, InputMethodSession#setCursorAnchorMonitorMode was introduced for this purpose. However, we got several feedbacks to be addressed. - The effect of #setCursorAnchorMonitorMode is not preserved during focus change. IMEs need to call #setCursorAnchorMonitorMode every time when #onStartInput is called. This is tricky and hard to understand. - As #onUpdateCursorAnchorInfo is a new API, not all applications/text editors have supported it. Therefore IMEs can't always rely on it. However, there is no way to query if the attached target is supporting this new API or not. It would helpful for IME authors if we can provide a reliable way to query if the attached input target is supporting the new API or not. In order to address these issues, the triggering method has moved from InputMethodSession to InputConnection in this CL, as an analogy of existing InputConnection#getExtractedText API, which has provided similar functionality including optional reactive event callbacks from the application to the IME. BUG: 15812658 BUG: 16118603 Change-Id: I3c6b69bd9d79b199afe68d838f25effa6048e5cc
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
9d69ecbf61a4a142c3f4cbb9d5659faa6f85e832 |
|
25-Feb-2012 |
Gilles Debunne <debunne@google.com> |
InputConnection is warned when finished As said in https://android-git.corp.google.com/g/#/c/155992 finishComposingText is indeed too broad of a method. Introducing a new dedicated method to warn the InputConnection. Should solve the problems with a negative counter value. Change-Id: I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
c478c171e92b2f255e9699d9c9306b001368ac20 |
|
20-Dec-2011 |
Gilles Debunne <debunne@google.com> |
Unbalanced batch edit begin and end leave TextView unresponsive This is a fix for http://code.google.com/p/android/issues/detail?id=17508 Adding some logs and a forced GC, I'm now reliably able to reproduce it. Here is the scenario. 1. The IME handles an event. It retrieves the current InputConnection (IC) using ic = getCurrentInputConnection() and calls ic.beginBatchEdit(); 2. The call is propagated to the UI thread and TextView's mBatchEditNesting is correctly increased through beginBatchEdit() 3. A listener calls setText(), which imm.restartInput(this); 4. As a result, the InputMethodManager creates a new ControlledInputConnectionWrapper with a new InputConnection from the TextView 5. A GC happens at that point. The previous InputConnection is no longeri referenced by the InputMethodManager's mServedInputConnection. The weak reference in the previous ControlledInputConnectionWrapper is nulled. 6. The IME thread finishes its process and calls ic.endBatchEdit(); on its version of the original InputConnection. 7. The message is passed through the InputConnect, but when the weak reference in the original IInputConnectionWrapper is dereferenced, we get a null InputConnection in executeMessage(). 8. As a result, the TextView's endBatchEdit() method is not called, leaving this TextView with a non zero mBatchEditNesting. 9. From now on, all edit actions on this TextView will be considered part of a nested edition and no invalidation is performed, which is the visible manifestation of this bug. The core problem is that the begin/end batch edit contract is broken when: 1. These are initiated by the IME thread (as opposed to the UI thread) 2. The input connection is reset between these calls 3. A GC happens in the mean time and the WeakReference is lost (otherwise calling endBatchEdit on a no longer active InputConnection is fine Solution to keep TextView's mBatchEditNesting balanced: - The IMM should notify the IC when it is no longer used. We're using the existing FINISH_INPUT_CONNECTION to do that. - The InputConnection should keep track of its nesting contribution to the TextView. When finished the IC makes sure its contribution is reset to 0. Moreover, further asynchonous calls to begin/endBatchEdit that may arrive from the IME should be ignored. This is achieved using a negative value as a flag. Notes: - finishComposingText may be too broad of a method to perform such a cleaning step but is seems to only be called in cases where the IC will not be used anymore. If that's too broad, we have to introduce a new method in the IC interface. - This is has been implemented in EditableInputConnection and not in a more general BaseInputConnection because this is where we have a notion of TextEdit, and the nesting problem is here specific to TextView. However, the same unbalanced begin/end problem will happen in these classes. They should override finishComposingText as has been done here if that matters. - We cannot re-use the TextView's mBatchEditNesting since it may take into account batch edit from various sources and resetting it on InputConnection close could then lead to an inconsistent negative count value. Patch Set 2: added synchronized blocks around mBatchEditNesting Change-Id: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
f9f01008624e2d28c15a90d942fa36f98c8c967d |
|
19-May-2011 |
satok <satok@google.com> |
Add Apis to send notifications when the suggestion was picked - Due to a strong request from VoiceIME Bug: 4443922 Change-Id: Ia539de0acf66053e0349daec459d75e36805f6bf
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
b3fc1a5b8b8f88eaf00b05957523cbdc0944b24b |
|
06-Apr-2011 |
satok <satok@google.com> |
Rename CorrectionSpan to SuggestionSpan Change-Id: I004b2e012b2de4de959a31da1f55b63ca7c14199
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
e3797a15fbf769a0abcbe121cfd33b4b658aea1e |
|
21-Mar-2011 |
satok <satok@google.com> |
Removed APIs for setCorrectionSpan from InputConnection ("setCorrectionSpan" was added in Id3abc9ea4d11753cd ) Also.. - Added a class java doc for CorrectionSpan - Removed FLAG_DEFAULT - Changed the return type of getSuggestions from Array<CharSequence> to String[] Change-Id: If5eb091e307a7a40c5b4a70ec1fe6059ecd9fb2d
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
adb435835fb9a5f2bb74d29930b239dde18504a7 |
|
09-Mar-2011 |
satok <satok@google.com> |
Add CorrectionSpan and APIs to pass a secure CorrectionSpan to TextView - CorrectionSpan is a span which has suggestions made by IME. This has a function to change the current IME to other IME specified in this span. For security reasons, only the current IME is allowed to use this function through InputConnection. (IME token is used for checking the validity of it.). - CorrectionSpan stores following information: flags, subtype Id, InputMethodInfo Id, suggests, locale, original string Change-Id: Id3abc9ea4d11753cdc4f483a2bb3128f49ba198a
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
b7fc63f7aac3689696f7f84953009b5928ac3db3 |
|
28-Jan-2011 |
Gilles Debunne <debunne@google.com> |
Fix for TextView's error popup behavior when using soft keyboard. Bug 3370191 The documented behavior is to hide the error when the text changes. However, this should not be the case if the error was reset by a text watcher. Comparing errorBefore and errorAfter as was done before is not sufficient in the case where the error is reset to the same value. String pool optimization will re-use the same Object and it will look like the error has not been modified (hence the blinking behavior reported in the bug). For this reason, TextView has a mErrorWasChanged flag. The fix is to export methods that can use this flag as in done inside TextView when a physical keyboard is used. These methods are hidden. Change-Id: Ie3ec59a368f3b1588b81242890b971ac48e8ff7e
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
a85467bc8da8d4cecd47ed30da04c72c4f7bd842 |
|
20-Jan-2011 |
Gilles Debunne <debunne@google.com> |
Error popup no longer flickers in TextViews. The removed lines were committed by the Android Open Source Project. Their intent was probably: the message was there before, it is identical after a text change, let's remove it to not annoy the user who already saw it. The behavior however is that the message is displayed then hidden, then displayed as the user types. Bug 3365016 Change-Id: Ie820f8e5465ad8ab5890272c42627686e0d7961b
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
cf9cf2f40efc4ccf3f73e6fdb07725d9c00c4f91 |
|
09-Dec-2010 |
Gilles Debunne <debunne@google.com> |
New API in InputConnection to signal IME's text correction. Scafolding so that the IME team can start working on this feature. The animation part in the TextView is missing. Change-Id: I8225538564370fba1500e3539742a8ab79bdd199
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
51bf077883df4f5cc816fbfec6d19eedffc26d70 |
|
25-Mar-2009 |
Dianne Hackborn <> |
Automated import from //branches/master/...@141004,141004
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
076357b8567458d4b6dfdcf839ef751634cd2bfb |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@132589
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
3dec7d563a2f3e1eb967ce2054a00b6620e3558c |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@137055
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
3001a035439d8134a7d70d796376d1dfbff3cdcd |
|
19-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@132276
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
f1e484acb594a726fb57ad0ae4cfe902c7f35858 |
|
22-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@127436
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
b798689749c64baba81f02e10cf2157c747d6b46 |
|
10-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@125939
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/com/android/internal/widget/EditableInputConnection.java
|