PhoneWindow, PhoneLayoutInflater and PhoneFallbackEventHandler decided
to @hide out over in the android.view package after the policy jar was
disbanded. Give them a more appropriate home over in framework that
doesn't imply that they should be accessed from other internal layers
of abstraction.
Bug 19606548
Change-Id: Id07b791d178fa447010b49b24726b52208838e88
Expose the new Builder pattern for creating StaticLayout. This allows
access to a number of features that have been available to TextView
through a hidden constructor. Some of these features have existed
for a while (mostly maxLines), while others are new (breakStrategy,
indents).
The builder is cleaner and has a better upgrade path than the old
pattern of lots of constructors with varying numbers of arguments.
Bug: 20190561
Change-Id: Ia3cd124825ab0cb469d22d1fc576ad26454545b8
Previously we'd return true from onIntercept and assume the DOWN event
was handled, then onTouch would return false and the host view would
receive the DOWN event. Now we consume the event in onTouch.
Bug: 19080751
Change-Id: I1bd35b4c25a0760f4248ade443d09b8ca4b71e7c
This is a follow up CL for Ia515fc576ddf2127b2f9863cc2652aeb619fff6e
for Bug 5420741, which had basically the same goal to Bug 20158984.
The goal here is to dismiss any popup window opened by the TextView
when the device is about to be rotated. This is important because
Window Manager and Input Method Manager Service are really sensitive
about which window is focused before and after the device is rotated.
In Ia515fc576ddf2127b2f9863cc2652aeb619fff6e, we tried to distinguish
two kinds of focus-lost. One is the true focus lost where suggestions
pop-up (if any) should be dismissed, and the other is an side effect
of showing the suggestions pop-up itself. We have used isShowingUp()
to distinguish distinguish one from the other. In short, it
indicates whether onWindowFocusChanged() is not called yet or is
called at least once.
In extract edit mode, however, it turned out that
onWindowFocusChanged() is never called (at least in recent builds).
As a result, the popup window is not dismissed when it should be.
One of the smallest solution would checking isShowingUp() only when
the target TextView is not ExtractEditText.
Adding unit test would be handled as Issue #20703391.
BUG: 5420741
BUG: 20158984
BUG: 20703391
Change-Id: I1706cf2ea0b0bdfe8894ab57fc3caa8ff12d8aab
Look down, back up, where are you? You're in a dialog with an
AutoCompleteTextView. What's on your screen? I have it, it's the
auto-completion results you could be seeing. Look again. The window
layout type is now TYPE_APPLICATION_SUB_PANEL and the auto-completion
results are visible.
Also adds API on ListPopupWindow to specify the window layout type
and changes the text editing handle to be type ABOVE_SUB_PANEL.
Bug: 18530738
Change-Id: Id5577c4892729920de5b73411e580e6b2b2401d0
This patch moves the Paint parameter from being an option set from
setPaint to being a required field passed into the obtain() method
of StaticLayout.Builder. Thus, it is now possible to get a valid
StaticLayout object just doing .build() on the Builder; all other
fields are optional.
This is in preparation for exposing the builder publicly, but that
is to be a separate CL.
Bug: 20190561
Change-Id: Iefd7800203004e565d068b0c76502cf7cf52d91f
Moves the queryHint to defaultQueryHint, specifies the override order
as queryHint > SearchableInfo > defaultQueryHint.
Cleans up annotations and comments for several related methods.
Bug: 20614122
Change-Id: Ib58ec309e6814cd512df147d789ec0cd546018af
Day validation moved from the PagerAdapter to the DayPickerView,
which is widget that actually handles the touch interaction and
disabled state for individual days.
Fixed disabled states for primary and secondary activated text
colors. Replaced old light/dark color state lists with themed
versions.
Removed conflicting view visibility changes for managing next and
previous arrows in DayPickerView.
Bug: 20630417
Bug: 20641013
Bug: 20641879
Change-Id: Icdaf02a3b57ec162169c31b8a27ebea908552321
NOTE: This is only done on ACTION_UP event since the toolbar is
going to be hidden while one is dragging the handles.
Change-Id: Id09fc076edb0117ebceb26395ac91ee4d2283c2d
b/20157498
ACTION_SCROLL_UP, ACTION_SCROLL_DOWN, ACTION_SCROLL_LEFT and ACTION_SCROLL_RIGHT
actionos were added in addition to ACTION_SCROLL_FORWARD/BACKWARD
Change-Id: I8d5182a8add32085a354b280496b3d38ec79be32
Selection handles were always shown when selection action
mode is started at first time. When the action mode is
started without a selection, only insertion handle must be
shown.
Bug: 20264980
Bug: 20407551
Change-Id: I630804e007f795d28f87e3fa6cba0de5bf588c78
HandleView#isVisible didn't use getHorizontalOffset; thus,
the position is always computed as if Gravity.LEFT is set.
As a result, isVisible can be wrongly false for the end
handle and the handle is dismissed.
Bug: 20480054
Change-Id: Ib3242000bb98ae28e0cb37bf5b05069754abbfc6
