With I63af3a6ecbf92, we create RenderNode lazily, but
blocks containing contents that protrude from line top or
bottom cannot be simply lazily redrawn after edit or
scroll.
With this CL, we check if the contents protrude from line
top or bottom by comparing the text bounds with relevant
font metrics values and we always redrawn such blocks after
edit or scroll.
Bug: 27889485
Change-Id: I666da5eeb39f780c341597f347bfcba21eb34295
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
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
These classes are mostly undocumented and, in some cases, completely
unobvious in what they do or how to use them. In some cases, I added
docs to explain the API. In other cases (ProgressDialog, ZoomButton,
DialerFilter), I deprecated the classes because there are far better ways
to accomplish that functionality with today's platform.
Issue #2164052 Underdocumented classes in Eclair
Change-Id: Ief0e7267852c2cb3c5ae604b3d902d66c89f4cd3
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
Change default scrolling containers not to request a reveal (parent
scroll) on focus, and to be focusable in touch mode. This helps watch
devices with other input mechanisms that rely on view focus.
Since there's no attribute for the reveal on focus hint, set that in
code. Set focusable in touch mode on the default styles for
ScrollView/HorizontalScrollView. AbsListView already sets this
historically anyway.
Change-Id: I74760f6d523874127da6f6134f0461cc59ce189a
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
Moves the ClickableSpan GestureDetector creation into
TextView#onTouchEvent only on ACTION_DOWN if a ClickableSpan
was targeted. This allows constructing TextViews outside the
UI Thread.
Bug: 30929474
Change-Id: I7f4442f0faee51d3c395fbde1ce32bdf909a18fb
All I've done is change the order in which the textview's attributes
are being checked. Not sure if this breaks anything but nothing jumps
out as something that can break from a brief inspection of the code.
I'll revert this changelist if something breaks as a result of this.
Bug: 30874589
Change-Id: I0e2411eab6e952a0d10eedd8c2d3d073ea436f56
