Some apps rely on their drawables not getting not-visible hints via
setVisible when the window visibility changes. This manifests as
additional animations, such as crossfading from placeholders when the
window becomes visible again.
Apps should be able to handle this case in the future now that we have
more detailed reporting via onVisibilityAggregated, but to keep
existing apps working as-is, ImageView now operates in a compatibility
mode for targetSdkVersion < N and will only dispatch visibility
signals based on the same triggers used in M. New apps get the more
detailed signals.
Fix a bug where window visibility dispatch via onVisibilityAggregated
would double-dispatch "not visible" when the window is transitioning
from GONE => INVISIBLE or INVISIBLE => GONE.
Make the growing set of compatibility check fields in ImageView
static, matching the pattern from View.
Bug 30216207
Change-Id: I88875260bf6aaa23687c7d51353de8d633383531
Fix a regression where some drawables would not be correctly updated
with their visibility state if set while an ImageView was not attached
to a window.
Bug 30216207
Change-Id: Ia30326a78168141c8f85bad9c782710f965623b7
Which for en_US would be something like "Friday August 5th 2016" but may
be re-ordered for other locales. Dates are hard.
Bug: 30682782
Change-Id: I015d293526592add27ce8fada12cd58bcc274ccf
Currently we are only appending the DISPLAY_CLIP_VERTICAL
if the API user happens to call update() after showAsDropDown().
This fixes that behavior, and fixes a RTL issue (START v. LEFT).
Unblocks a CTS test I am working on.
Bug: 30578621
Change-Id: Ibf838544d453986b66eb223e2ac0f7d909fe5630
(cherry picked from commit 8367c50972)
Prior to N, our widgets were not converting MarginLayoutParams
properly between ViewGroups. The fix intrudced some issues in
older apps as the broken conversion code would hide developer
errors. This CL guards the change with a target API check so
that we don't affect older apps.
Bug: 30378230
Change-Id: I215281d261b553c3b4cedcd29ea0a861df809471
Previously AbsSeekBar always rounded up, which resulted in poor handling
of touches near the edge of a progress value. We fixed this but forgot
to adjust RatingBar for the new behavior.
Bug: 30558586
Change-Id: I634fa7a0b98568093e16279ef5a80abe08d2e2fe
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 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.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Icc8f8dbd060762ae1a7b1720e96c5afdb8aff3fd
Preferences lack a title on watch type devices due to lack of ActionBar
support. A custom ListView was added to use a custom wrapper adapter to
add a persistent header view at the top of the ListView that developers
would not be able to remove via the ListView API.
Bug: 27962897
Change-Id: I6bccecf85592d9507e0c7a04c9a035617001e9ef
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
