67e2ae86396c6d0f989285275cbf908dee5e71f7 |
|
12-Oct-2016 |
Aurimas Liutikas <aurimas@google.com> |
Fix import statement in view|transition|animation packages. This change also remove trailing whitespace. Test: code still compiles Change-Id: I7eff4546320d67d2bae58d31bad0625ea0791b8f
/frameworks/base/core/java/android/view/inputmethod/InputConnectionInspector.java
|
45700fa135e83ed44e4b69ca60cf12960a5898d7 |
|
24-Jun-2016 |
Yohei Yukawa <yukawa@google.com> |
Use a flag to grant a temporary URI permission. It turns out that we can let the system to call InputMethodService#exposeContent(InputContentInfo, EditorInfo), which added in my previous CL [1], during the IME is calling InputConnection#commitContent() as follows. [IME] InputContentInfo contentInfo = new InputContentInfo( contentUri, new ClipDescription(description, new String[]{mimeType}), linkUrl); getCurrentInputConnection().commitContent( inputContentInfo, InputConnection.INPUT_CONTENT_GRANT_READ_URI_PERMISSION, null); [App] try { contentInfo.requestPermission(); // Load inputContentInfo.getContentUri() here. } finally { contentInfo.releasePermission(); } This gives us flexibility to let InputConnection#commitContent() do all the magic for IME developers like other APIs such as Context#startActivity(), rather than asking them to call one more API to grant a temporary URI permission like a scenario where Context#grantUriPermission() is used. [1]: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6 25e0813e6eb6315b1016db805fa9b791b4ae5cc2 Bug: 29450031 Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
/frameworks/base/core/java/android/view/inputmethod/InputConnectionInspector.java
|
adebb52588b098a1af678d4e33a234ef1ce783b2 |
|
17-Jun-2016 |
Yohei Yukawa <yukawa@google.com> |
API Rename: IC#inputContent to IC#commitContent. As shown in below, we have already used commit* naming convention in InputConnection. - InputConnection#commitCompletion(CompletionInfo); - InputConnection#commitCorrection(CorrectionInfo); - InputConnection#commitText(CharSequence, int); Hence renaming IC#inputContent() to IC#commitContent() would make the new method more consistent. Bug: 29450024 Change-Id: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
/frameworks/base/core/java/android/view/inputmethod/InputConnectionInspector.java
|
152944f4909c47917473293b258d266435c6ab35 |
|
11-Jun-2016 |
Yohei Yukawa <yukawa@google.com> |
Add InputConnection#insertContent(). Providing an official protocol for IMEs to insert an image to the application is something that has been requested from many IME developers to Android OS. With this CL, IMEs are able to ask applications to insert a content including image files as follows. 1. An application that opts in to this protocol specifies a list of supported content MIME types in EditorInfo#contentMimeTypes. 2. When an IME is actively interacting with such an application, the IME can call InputConnection#insertContent() with a InputContentInfo that contains content URI, metadata (ClipDescription), and an optional link URI. 3. The application can read the stream data from the given content URI to insert the content into somewhere in the application. Detailed design background can be found in the JavaDoc of InputConnection#insertContent(). Bug: 22830793 Change-Id: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
/frameworks/base/core/java/android/view/inputmethod/InputConnectionInspector.java
|
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/InputConnectionInspector.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/InputConnectionInspector.java
|