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/android/view/inputmethod/InputConnectionWrapper.java
|
19a80a1e807acd00bec999eaac7812da6ffce954 |
|
15-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Tell IMS about missing InputConnection methods. 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
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
1d1c21c9cb7911d74fe1859ba9f03fcd2edab262 |
|
01-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Add more JavaDoc to InputConnectionWrapper. This CL makes it clear that InputConnectionWrapper cannot be used to emulate the behavior when a null InputConnection is passed to the system. We should provide some guideline for developers about how to deal with bugs like crbug.com/571229, but as explained in the previous CL [1], changing the behavior of InputConnectionWrapper could be a bit risky at this point. Hence we put more cautions in JavaDoc instead. [1] I8bc84d484ab0b27a02e74f11110430f70646e69a abc4b8f035c491f976be736373f50c3cac33a7a6 Bug: 27407697 Change-Id: I98d1fc096c108603647a85bb0ba045b5dd23d37b
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
abc4b8f035c491f976be736373f50c3cac33a7a6 |
|
29-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Revert "InputConnectionWrapper never supports null target." This reverts commit 90bd36363c5738b3f526aa1f1d44f432236300a0. Seems that the semantics of InputConnectionWrapper#setTarget() is more complicated than I thought. At least the following cases have worked fine. case 1: InputConnectionWrapper wrapper = new InputConnectionWrapper(null, false); wrapper.SetTarget(ic); ... case 2: InputConnectionWrapper wrapper = new InputConnectionWrapper(null, true); wrapper.SetTarget(ic); ... case 3: InputConnectionWrapper wrapper = new InputConnectionWrapper(ic, true); wrapper.SetTarget(null); wrapper.SetTarget(ic2); ... The previous code did not intended to break existing code. Let's revert it we decide how to deal with above cases. Bug: 27407697 Change-Id: I8bc84d484ab0b27a02e74f11110430f70646e69a
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
90bd36363c5738b3f526aa1f1d44f432236300a0 |
|
29-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
InputConnectionWrapper never supports null target. This CL makes it clear that InputConnectionWrapper does not support null target. In other words, the semantics of null InputConnection can never be emulated by a non-null InputConnectionWrapper. This is particularly problematic when app developers are just forwarding the return value of super.onCreateInputConnection() to InputConnectionWrapper or its subclass, because there are many chance that super.onCreateInputConnection() starts returning null, e.g. when: A. the application is extending a Framework class, and the Framework class is updated by OTA. B. the application is extending system WebView, and the WebView is updated. C. the application is extending a 3rd party library, and the app developer creates a new build with a new version of the 3rd party library. To make it easy to catch these kind of bugs, this CL lets the constructor of InputMethodWrapper throw NullPointerException when target is null. Bugs like crbug.com/571229 should be caught by developers more easily. Bug: 27407697 Change-Id: I83875bea886d4784f9507c930050efc29708d9db
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
612cce92ad96eda1146c3abd2afa7aaa4d4f2b3f |
|
12-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Introduce InputConnection#getHandler(). Currently there is an internal hidden class named ControlledInputConnectionWrapper which works as a proxy in the application process to receive incoming binder calls from input method and dispatch those method calls again on an appropriate thread. Although this is a kind of implementation details, basically you can see the same design everywhere in the Android. Currently ControlledInputConnectionWrapper is initialized with view.getHandler(), where the view here is the View which was used to call View#onCreateInputConnection(). This is actually a reasonable behavior because we have generally assumed that there the only reasonable way to implement InputConnection is to extend BaseInputConnection, which is designed to be able to work only on the UI-thread associated with the target view. However, on Android N and onward, we are going to ensure that BaseInputConnection can be re-implemented on top of public APIs [1]. Although most of applications should not try to do that, for certain applications such as web browsers and WebView it may make sense to let custom InputConnection implementation run with a custom Handler so that the application can respond to the IME without blocking the UI thread. To do that, this CL introduces a new method InputConnection#getHandler(), which changes nothing as long as it returns null, but if it returns non-null Handler, InputMethodManager will use it to initialize ControlledInputConnectionWrapper. Note that InputConnection#getHandler() is not for IME developers. It just returns null when called in the IME process. [1] See Bug 24688781 for details. Bug: 26945674 Change-Id: Id9e579bb3e2966986cdcb1c34bc8cacfeca2e1a9
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
c89e22a6ff227089fde26daea186346029d1b32c |
|
14-Jan-2016 |
Yohei Yukawa <yukawa@google.com> |
Introdude IC#deleteSurroundingTextInCodePoints(). This CL introduces a API variant of IC#deleteSurroundingText(), named IC#deleteSurroundingTextInCodePoints(). Major differences from the existing one are: - The lengths are supplied in code points rather than code units. - This API does nothing if there are one or more invalid surrogate pairs in the requested range. (Failure Atomicity) Note that due to the asynchronous nature of the input method architecture in Android, implementing the same logic in the input method side basically ends up with unreliable and unpredictable results. Bug: 6526420 Change-Id: I7f6a2c5d3d52079ae71623fd5e40d60c688dd5fb
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
3fadee479107f0494e1e190aba2a1eea12cb0a75 |
|
08-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
API Review: Clean up removed APIs This CL removes old API signatures marked as @removed in the follow CLs. - Ic8c6fab58c01206872a34e7ee604cdda1581364d - Ia8cbb9f6b41cd9509fc0147fd68763dfde593ffc - I772c48ff18918e48a81e807b48ff907614485c09 This is just a clean-up CL. No behavior change is intended. BUG: 17200900 BUG: 17320996 BUG: 17365414 Change-Id: Ibfbd5cc1cdebb8851c73477cff55c9b2d631fdea
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.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/android/view/inputmethod/InputConnectionWrapper.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/android/view/inputmethod/InputConnectionWrapper.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/android/view/inputmethod/InputConnectionWrapper.java
|
0c95dd3f4f02564fab9b86a221bbcbb4aafc2981 |
|
24-Jan-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug # 5863709 API request: Change param names of deleteSurroundingText to "before" and "after" Change-Id: I727fad9a59cda915899674569bfabd29b9f5da60
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.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/android/view/inputmethod/InputConnectionWrapper.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/android/view/inputmethod/InputConnectionWrapper.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/android/view/inputmethod/InputConnectionWrapper.java
|
a90b7f0125389b9e1040d2be82aad4ef74ea6071 |
|
26-Aug-2010 |
Amith Yamasani <yamasani@google.com> |
Add methods to InputConnection: setComposingRegion() to select a region of text for correction, and getSelectedText() to return the selected text. setComposingRegion: The TextView may choose to highlight the text in some way (underline for now) to indicate that the text is selected for correction, if the IME wants to provider alternatives. Choosing an alternative in the IME can then call IC.commitText() to replace the highlighted (not selected) text with a different candidate. This change also ensures that any existing spans/styles are not wiped out. So we can now correct rich text as well. getSelectedText: This is a convenience to get the selected text instead of using extracted text that is more heavy weight. Existing getTextBeforeCursor() and getTextAfterCursor() fail to retrieve the selected text, only what's before and after the selection. Change-Id: Ieb5ecd5ff947ea04958589f501e7bd5228e00fb5
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
51bf077883df4f5cc816fbfec6d19eedffc26d70 |
|
25-Mar-2009 |
Dianne Hackborn <> |
Automated import from //branches/master/...@141004,141004
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
b2a3dd88a53cc8c6d19f6dc8ec4f3d6c4abd9b54 |
|
09-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@137197
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
f1e484acb594a726fb57ad0ae4cfe902c7f35858 |
|
22-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@127436
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
b798689749c64baba81f02e10cf2157c747d6b46 |
|
10-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@125939
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/inputmethod/InputConnectionWrapper.java
|