Also fixes progress bar sample tile to reflect density and ensures
that ProgressBar.tileify() clones inner drawables into the correct
density.
Bug: 31841123
Test: BitmapDrawableTest#testPreloadDensity()
Test: ThemeHostTest
Test: Visual inspection of ApiDemos
Change-Id: I9dcb9817d8d91d61ff0215987247e9e7fb089c46
A recent fix prevented developers from specifying Holo-style mode when
displaying a date or time picker dialog. This CL also cleans up unused
code in TimePickerDialog and documents how themeResId will be used.
Adds hidden @TestApi methods for use in CTS tests. These may be made
public later, but it's too late in MR1 for API changes.
Bug: 31586821
Test: Ice2e203983769f1ea1cfa93105eb97b6fa5176b9
Change-Id: I1b7512b7647ddd7ab987beac2c0aef4fe7cc16bc
Previously it would almost always force SearchView to become 0
when height mode was UNSPECIFIED.
Bug: 31302290
Change-Id: Icd2116b84951b1b967666147dbc5762d996408e6
getMaxAvailableHeight is ignoring the top insets, while
findDropDownPosition is not. This is causing getMaxAvailableHeight
to return a fits above position that findDropDownPosition will think
is too large.
Bug: 31048766
Change-Id: Ifa57cb4ebe0944c701a6f38b58d4f144d8b9199c
There may be a pending selection from a previous filter() call, but the
current filter() call may return an empty string without posting a new
pending selection.
Bug: 31049172
Change-Id: I2cb88b3283a3705b6c85d61f26951c35d2b0acd2
To address a security issue where a toast window can be
used by an app to overlay other apps without a permission
we now allow legacy apps to be able to put at most one
toast window on the screen to prevent adding the same
window over and over again to go around the new restriction
that toast windows are always removed after a timeout.
This change ensures that Toast removes its window immediately.
bug:31340854
Change-Id: Ia7f90844eb64b583321103d090e4407038b41547
(cherry picked from commit 1777c91f8f)
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: Ia1dae626bd9e22541be46edb072aa288eb1ae414
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
(cherry picked from commit 26489e1688)
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
First we restore the M semantics with respect
to DISPLAY_CLIP_VERTICAL, which we only applied
for drop downs, and omitted in the case of
showAtLocation. Further, we fix an error where
user specified gravity from showAtLocation is
erased when calling update() by storing the
gravity and including it in computeGravity().
Bug: 30445010
Bug: 30965176
Change-Id: I28a081e1237a8b41f2444717e0db21ef4181507b
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
