If we intend to clip to the screen we can't pass NO_LIMITS.
Luckily the default behavior for LAYOUT_IN_PARENT_FRAME is to not
clip to the parent frame, so we don't have to do anything except
update our local flag we use for explicit size calculations.
Bug: 28194524
Change-Id: I1465efce7f5412cf646bccd83e23a4b049f4dbc4
This CL fixes a bug in list view where an unused
scrap view would stay in temporarily detached
state until it is re-used.
It is an invalid state for a view and to fix
that issue, I've changed AbsListView to fully
detached scrap views at the end of a layout
pass and also treat them as regular new views once
they are re-used after being fully detached.
Bug: 28672259
Change-Id: I6e3f4da29f8cbca32787862402f5c21f674a7145
ListView was leaving header and footer views
in the detached state, which is a problem because
no view should be left in that state after a layout
calculation. This was also causing the view to never
received detached-from-window callback if
the ListView is detached while the header is not
visible.
This CL fixes an issue by traversing fixed views
and removing the ones that match the criteria.
To keep the behavior as similar as possible,
we still do not call startTmpDispatch on
fixed views unless we'll remove them.
Bug: 24490656
Change-Id: I8acfbd1a9d9b8b24c1c4b7692ef82cfe0f4d43a8
Drag handles are blocked from being shown if batch edit mode is active
when onPreDraw is called; however, IME can start and end batch edit
mode regardless of onPreDraw timing.
As a result, drag handles are sometimes not shown even if selection is
created and text action mode is started.
With this CL, drag handles are shown after finishing batch edit mode
if the handles were blocked from being shown in the above case.
Bug: 28366507
Change-Id: I7f099d0626bee70a63bb14bc75eefc2551a52d53
Hour was not updated correctly when a new hour was selected using the
radial picker or when AM/PM was changed, which prevented programmatic
calls from working.
Bug: 28398738
Change-Id: I0c1ffd9f9e569d980e72e74dc62568a56930afc4
Touch position is adjusted in HandleView#onTouchEvent to snap to
ideal offset.
Previously, screen coordinate was used for input, but window
coordinate is used for the ideal offset. As a result, window adjusted touch
position will be adjusted to improper position and a handle being
dragged will get moved to unintended line.
Bug: 22308836
Change-Id: I4a5a3cc695a874c85aa341f06ffcba8b7f5e318c
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
