It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout like toasts are.
Now to add a toast window one needs to have a special
token. The token is added by the notificatoion manager
service only for the lifetime of the shown toast and
is then removed including all windows associated with
this token.
This prevents apps to add arbitrary toast windows. The
token is passed in the app domain in the request to
construt and add the toast window which allows a bad
app to add arbitrary toast windows. However, this is
fine since the token will be invalided and all of its
windows removed after the toast for which it was
create times out.
We do not care of braking apps that add toast windows
directly due to the security and privacy implications
of arbitrary UI redressing. Also we have dedicated
Toast APIs which are the way to add this time of UI.
bug:30150688
Change-Id: I65372c81a791489de89fb2886cc96392c28680bb
View attachment calls jumpDrawablesToCurrentState(), so the view state
needs to be set up prior to attachment. For views that are already
attached but are being moved to a new position, manually jump.
Cleans up comments in methods that were modified.
Bug: 29978498
Change-Id: Ica27b2c60ad7ee98b9d1e4912c4f8b8c248af88d
When we want the WindowManager to clip our requested width/height
to the display frame, we need to pass DISPLAY_CLIP_VERTICAL/HORIZONTAL.
It seems this behavior was unintentionally applied without this flag
in previous releases.
Bug: 29602363
Change-Id: Ib98060e36efde0dbaabb59a758da5374035dbb62
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
25e0813e6e
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
Caused by super constructor calling non-final methods
which Toolbar overrides, and then tries to reference
final variables.
BUG: 28806107
Change-Id: Ieaf5f7611dbbf954e49c31e604aa2f7627248615
At the point of showDropDownPosition measure
may have not yet been called and we can't try
and resolve WRAP_CONTENT. ViewRoot will do it for us
and set requestedWidth/Height at an appropriate point.
Bug: 29496188
Change-Id: I99f26612bec800f3e321495b3df3e37b5ffb3152
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
For the setClipToScreen case we need constraint to
the available display area, but not to the parent window.
If we don't pass FLAG_LAYOUT_NO_LIMITS, we will be constrained
to the parent window. However when we do pass it, we will
not be constrained to the system insets. So, we can pass
FLAG_LAYOUT_NO_LIMITS and constrain ourselves to the insets
via getWindowVisibleDisplayFrame. We also need to avoid
calling setWidth/Height with these resolved values
so we can preserve the indeterminate values in case
layout changes (e.g. rotation).
Bug: 29166136
Change-Id: I4c7c6204e6bc1cdcf4ad86f7e99e3511d4312ae4
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
This CL fixes a bug in AbsListView where it was not invalidating
children's bounds when AbsListView's bounds change. This was
triggering bugs where if you set padding on a list view, it would
not resize its children.
Bug: 28800232
Change-Id: I81a4e9ea234c395de80efea5ef5e47a71cb95136
am: 361f03c4e2
* commit '361f03c4e2c774c074ef98ab2631e28288690034':
Set StaticLayout.maxLines only when ellipsize is set
Change-Id: I15d616a7b448dc8e63c1a7d0ac136be98669a869
