ListView adds children without requesting a layout for them.
This creates a problem if the child does not request a
layout because we reset the child's RTL properties when
addViewInner is called.
A proper solution would be to call resolve when child is
being measured (and ignore cache if it resolves) but
a change like that is too risky for MR1. This CL will
fix ListView portion of the issue.
On master, we'll solve this in View level.
Bug: 30132566
Change-Id: I0b131ac1086b1d32146f3c93d1323050873293d3
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
