List items are always positioned using the divider height, even if there
is no divider drawable, so we should account for that when calculating
list height.
Bug: 28402970
Change-Id: I14b8d3b04a369749ff4b7e6f1e6e003ac08f6b7f
Restrict restoring the selected position when AdapterView
gets restored for Spinner instances only.
Bug: 26991402
Bug: 23619366
Change-Id: Ib002eac5ed0b8810a3e9988ad36f03450cb03b9b
A text filter may shorten the text, so we need to use the text
that's actually in the View, not the text we requested, to move
the selection.
Also removing the override of performAccessibilityActionInternal,
which should have been done as part of adding text actions initially.
Bug: 28253708
Change-Id: I184f49dcba0238f4ccc222597cefca258393b263
The PackageInstaller app manages side-loading apps as well
as permission management. It should be updatable, hence
should rely on system APIs to talk to the platform. This
is the first step of defining an API boundary.
Change-Id: I9814eafd0b22ae03b4b847a7007cdbf14c9e5466
Unexpected truncation happens again after [1].
This is fixed by setting match_parent into the container LinearLayout.
For the unexpected truncation of Holo Theme is came from other but
related root cause. To calculate the window and container width,
need to add container padding in addition to the maximum width of
the text view. Otherwise the width of the container view will be
shrunk and the contents will be truncated. This only happens on
Holo Theme since the padding of the container is zero on Material
Theme.
I manually confirmed this CL doesn't revive following issues
- 28034210
- 27341560
[1]: I67886a752ef110d3433dddd6aa8447a9027f8e19
[2]: I69b258687b4bf5510d9b2c3e690c88106bf893f5
Bug: 28266493
Bug: 28281740
Change-Id: Ie6d274714ac08080dc22aeb8ecd8b7729cb634cd
Also fixed a few more issues with the header util that could
lead to wrong states.
Change-Id: I95c3479f5d9e5221ee9e91120271e7957b887607
Fixes: 28295743
We recently added the width/height <0 check to prevent
passing unresolved widths in to tryFitVertical or
tryFitHorizontal and produce strange behaviors. This made
more sense than the code before it but still not that much
sense. We need to treat MATCH_PARENT and WRAP_CONTENT differently
as the documentation suggests.
Bug: 28267951
Change-Id: I6f2f248c8d1f63d31bdd75c24f7250c28381c712
When TextView is in a layout with weight params (i.e. LinearLayout) and
the width is set to 0, do not try to prevent requestLayout.
Bug: 27995311
Change-Id: Idfe9d8d0b595a6db95beb1afd83ca96a2bd46546
- Allow SearchView to expand to 48dp height if possible.
- Make the search clear button have 48dp height if possible.
- Expand the search TextView touch target height to 48dp is possible.
Framework version of patch ag/912646
Bug: 19479861
Change-Id: Ibaaef2afa20b8c05eaac8f028df4f616f2f96eb1
If the thread a toast is shown on is shut down,
the attempt to post the hide message to it's handler
will fail and it will never request removal. If this was
only some application background thread we will also not
receive a death notification. It seems best to use a timeout
to ensure we don't need the clients cooperation, espescially
as toasts can keep the screen on.
Bug: 21693547
Change-Id: I1d6e54ded5b9e2050daedc4d263e2e21fbe69862
In findDropDownPosition it's entirely possible for width/height
to be -1. If this is so, and the popup is anchored to the right,
we could fail to see that it is offscreen (since we think the width
is -1), and so fail to do our position adjustment to move it to the
left. I think this was previously covered up by window manager bugs
with child windows that requested coordinates outside of their
parent frame. To fix this, we ontinue to pass the same value to
the window manager, but use the width/height we expect to receive
for local layout calculations.
Bug: 28085451
Change-Id: Ia04ca3fcd17ad8819615b5ff42f7923462ce4b42
The existing logic just doesn't make sense for a display frame with
nonzero top. Consider if we were docked on the bottom of a 2560 tall
display and so had say a display frame top of 1280. Then if the anchor
were 80 pixels in to our window it's top in screen would be 1320.
When we would add these two we would end up a value greater than the
entire screen height as the possible space above the anchor. Instead
subtract the display frame, to only consider the possible space above
the anchor, within the display frame.
Bug: 26255254
Change-Id: I95d7575a12a4e319f85c1cf6778970ff37918045
Fixed crash of a widget that uses TextClock and belongs to a work
profile when is being added to the dash board.
BUG:27035203
Change-Id: I70c66cb792d159d2527050db820e7154784148a2
Window manager factors in the surface insets when calculating the
right crop for a window surface. Without the surface insets been
updated and new param forwarded to window manager, the window crop
will not be the right size and the window drop shadow might not show.
Bug: 27364161
Change-Id: Ieefeb8435543f3137672a065269cdeefca371111
