| 3933a6e0c358238302e07bc8782d65f672b88e7b |
|
10-Nov-2016 |
Yohei Yukawa <yukawa@google.com> |
Support content URIs w/ userId in IC#commitContent
With this CL, one can specify a content URI with an embedded user ID to
InputContentInfo, like such a URI is supported in
Context#grantUriPermission().
Note that such a scenario is actually possible when 1) an application
running as User X sets a content URI to the system clipboard then 2) the
IME runing as User Y who share the clipboard with User X obtains the
content URI from the system and tries to create a new instance of
InputContentInfo.
Bug: 32427307
Bug: 32778718
Test: 'adb shell dumpsys activity permissions' with a custom IME that
instantiates InputContentInfo from the content URI obtained from
the clipboard.
Change-Id: I7918c0a379b8f3e7e64b106447b42447876f9057
/frameworks/base/core/java/android/view/inputmethod/InputContentInfo.java
|
| 16e67edb366ad9a65d67b473ecc52a2d9e22f060 |
|
10-Nov-2016 |
Yohei Yukawa <yukawa@google.com> |
Fix up content URI for different users
Currently Commit Content API work only when the content URI provided by
the IME is accessible to the target application. This is non-trivial if
the target application is running as a different user (profile) and it
is actually a possible scenario when managed profile is enabled.
This CL takes care of such a situation, by fixing up the content URI
when and only when InputContentInfo#getContentUri() is called from a
different user than the owner of the content URI.
This CL also makes it clear that we currently do not support content
URIs that already have embedded user IDs. Since
IActivityManager#grantUriPermissionFromOwner() does not support such
URIs, we should have had a special handling for such a case, which will
be addressed in a subsequent CL.
Bug: 32427307
Bug: 32778718
Test: Made sure that Commit Content API works as expected on a managed
profile created by
https://github.com/googlesamples/android-testdpc
Change-Id: I19d87fc19beea248f49b59ec5a5711b95bcbb466
/frameworks/base/core/java/android/view/inputmethod/InputContentInfo.java
|
| f3806f57a59ede663f3fa2ad1f5080bdbf20e372 |
|
01-Jul-2016 |
Yohei Yukawa <yukawa@google.com> |
Automatically grant URI permission as needed.
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. 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.
If we do not do this and there is an application that forgot to call
that method then there is no way for IME developers to prevent
permission denial from happening in the application except for relaxing
the default permission of the ContentProvider just because of such an
application.
Although application developers are still expected to explicitly call
InputContentInfo#{request,release}Permission(), forgetting to call
InputContentInfo#requestPermission() does not hurt the user anymore.
With this CL, calling InputContentInfo#requestPermission() after calling
InputContentInfo#releasePermission() is also allowed.
Bug: 29892936
Change-Id: Id955435dd2e72549ee7134f46b3c6951581694ad
/frameworks/base/core/java/android/view/inputmethod/InputContentInfo.java
|
| 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/android/view/inputmethod/InputContentInfo.java
|
| 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/android/view/inputmethod/InputContentInfo.java
|
| 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/android/view/inputmethod/InputContentInfo.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/InputContentInfo.java
|