History log of /frameworks/base/core/java/com/android/internal/inputmethod/IInputContentUriToken.aidl
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
79d1c75a3f774bd8c4742f9d7bbd29161c3f1f68 30-Jun-2016 Yohei Yukawa <yukawa@google.com> Revert "Remove InputContentInfo#requestPermission()"

This reverts commit c4b8f36de5523366e354fc01b6cba81ad72f6423.

Having InputContentInfo#requestPermission() should not hurt developers,
but we can polish the behavior in a subsequent CL without changing
the API.

Bug: 29450031
Bug: 29892936
Change-Id: I1b43c19417b643d0c269af860db2d309b73a90d5
/frameworks/base/core/java/com/android/internal/inputmethod/IInputContentUriToken.aidl
c4b8f36de5523366e354fc01b6cba81ad72f6423 30-Jun-2016 Yohei Yukawa <yukawa@google.com> Remove InputContentInfo#requestPermission()

It turns out that requiring editor authors to call
InputContentInfo#requestPermission() as needed is just confusing and can
cause compatibility issues, because if an editor author forgot to call
that method then there would be no way for IME developers to prevent
permission denial except for relaxing the default permission of the
ContentProvider just because of such an application. This is not what we
want to see.

My conclusion is that the system should automatically call
InputContentInfo#requestPermission() (or do any equivalent operation)
when InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION is
specified, like we have done in Context#startActivity().

With this CL, the system automatically grants a temporary URI permission
to the target application when the IME calls
InputConnection#commitContent() with
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION, and the
temporary permission will be revoked by any of the following events:
- InputContentInfo#releasePermission() is explicitly called by the
target application.
- The target application returned false in
InputConnection#commitContent().
- All the InputContentInfo instances copied from the original one are
GC-ed.

Bug: 29450031
Bug: 29892936
Change-Id: I37fb744e4d3d1c59177fb0a9be4ef5c325c9a39f
/frameworks/base/core/java/com/android/internal/inputmethod/IInputContentUriToken.aidl
25e0813e6eb6315b1016db805fa9b791b4ae5cc2 23-Jun-2016 Yohei Yukawa <yukawa@google.com> Add InputMethodService#exposeContent()

This is a follow up CL to my previous CLs [1][2] that introduced
InputConnection#commitContent(InputContentInfo, Bundle) API to enable
IMEs to send a content to the target application.

With this CL, IME developers are able to temporarily expose
InputContentInfo object to the target package without permanently
granting URI permission. Although calling IMS#exposeContent() is
allowed only for the IME that is currently selected, the client is able
to request a temporary read-only access even after the current IME is
switched to any other IME as long as the client keeps InputContentInfo
object.

Here is a sample code snippet about how to use this mechanism.

[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
exposeContent(contentInfo, getCurrentInputEditorInfo());
getCurrentInputConnection().commitContent(inputContentInfo, null);

[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}

[1]: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
152944f4909c47917473293b258d266435c6ab35
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588b098a1af678d4e33a234ef1ce783b2

Bug: 29450031
Change-Id: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
/frameworks/base/core/java/com/android/internal/inputmethod/IInputContentUriToken.aidl