- 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
By setting width to the ListView, the width of the containing text view
won't match with parent.
I locally verified this doesn't revive issue 27341560.
Bug: 28034210
Change-Id: I67886a752ef110d3433dddd6aa8447a9027f8e19
When dragging a selection handle, it moves to strange position in
scrolled TextView because scroll position isn't took into account.
This issue was introduced by rebase mistaking in
I2a7e87ad08416f4bd01a5f6.
Bug: 28008281
Change-Id: I6217483fcc0b9a7e661f02a1f276114ddd5031a4
This change essentially backs out ag/683646, which added an API to click
on ClickableSpans within a TextView. This API has the flaw, however,
that ClickableSpans are not parcelable, so they are not in general
reported to AccessibilityServices. That means that services will have no
idea what they are activating.
Since the API is not usable end-to-end, I'm backing it out before the
API is final.
Bug: 17726921
Change-Id: I541c6218f2899ff67a6b32a13fd9ae6f3b53b3c4
With Ic025c109539c3b59638, selection action mode is always started
when there is a selection. This makes it impossible to extend
selection using selection mode.
This blocks creating action mode when full screen extracted mode is
started with selection, but it's same as MNC's behavior.
Bug: 27988877
Change-Id: I9614cb16373029189bfc098b6c1d353326e6b518
Sets default gravity value to the aptly-named DEFAULT_CHILD_GRAVITY.
Also cleans up FrameLayout lint warnings, annotations, and whitespace.
Bug: 27576632
Change-Id: I457b13791ff85f2228e61e85e44a502a28439e01
Previously, hasTransientState returned true even when TextView has a
selection that hasn't been created by the user. This unnecessarily
prevents the TextView from being recycled.
This issue was introduced by Ib454b0fbbc2c2f8d198, which fixes that
setHasTransientState(true) is not always coupled with
setHasTransientState(false).
With this CL:
hasTransientState will get true when selection action mode is started.
hasTransientState will get false when selection is removed.
Note that hasTransientState intentionally continues to be true when
selection action mode is terminated with preserving selection.
Bug: 27913323
Change-Id: I960ddfd7221caeb676c23926af06a8a415dec288
In order to fix Bug 18920212, we have to track when a View enters
temporarily detached state and when it exits from that state. To do
that, ListView needs to use View#dispatchStartTemporaryDetach() instead
of directly calling View#onStartTemporaryDetach() because there is no
guarantee that existing applications have internally followed Call-Super
pattern.
With this CL, we are going to expose temporary detach state and its
dispatching methods as public APIs. Major changes are:
1. ListView's indirect children will start receiving temporary
dispatch callbacks. Previously only direct children have received
View#on{Start, Finish}TemporaryDetach() callbacks.
2. TextView can no longer assume that ListView never calls
View#View#dispatchStartTemporaryDetach() but directly call
View#onStartTemporaryDetach() instead. See the commit message
of [1] for details.
This also enables us to do the following fixes, which will be handled in
subsequent CLs.
A. ViewCompat support lib is finally able to rely on temporary
dispatch mechanism without reflection.
B. InputMethodManager is now able to ignore focus-in events from
temporarily detached Views. This will be done in the next CL [2].
[1]: a440b002aa
[2]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
Bug: 18920212
Bug: 27905921
Change-Id: If8f780f8b71754f7533a65097304113ae1f5cf12
