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
append() is used to optimized insertions in the array, but it must
preserve the order of the hashcode array; when it doesn't, it falls back
to append(), but it should not log a warning message
In particular, PendingIntentRecords might have different hashcodes
across different processes.
Fixes: 29912192
Change-Id: I0ab566249829ddb934fd51cf21399b68cb286bd5
Fixes a case where notification header text could go missing
if a notification view was recycled and previously had a header text.
Reapplying only hid the text without clearing it, so the extraction
logic thought it was still there and hid the text for the children
even though it was not showing for the parent.
Change-Id: I3f96e1e7bebb2f815020d278ad13b2b5d948e63c
Fixes: 29915184
Previously, since the assumption was that the string is passed down
to ICU4C for the iteration to run, a window of text was copied and
maintained. But now, we can just pass an iterator to the input
CharSequence directly to ICU4J.
Bug: 21832431
Change-Id: Ife5dfdb1d90b3eda2817d4d75747b7abc34a2299
This reverts commit c4b8f36de5.
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
Adds a new API that enables device-specific scheduler optimizations for
latency-sensitive VR threads.
BUG: 29163534
Change-Id: I58d7be0eb266eca452c804cd07004784fb7daf2b
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
This CL flushes the trusted cert cache of all active Network Security
Configs and their TrustManagers. Previously CA addition mostly worked
however removed CAs would remain cached in the X509TrustManager causing
the removed CA to still be trusted.
Change-Id: I0f5fd39932f8f8ed3ec5dfd088a82e982b366c43
