Account for how much of first / last row is visible to make a
better estimation of how many screens we need to travel to
reach our target row.
Bug: 30390402
Change-Id: If38419b2ff94424ba4cbb8127f21f34904df8f44
To address a security issue where a toast window can be
used by an app to overlay other apps without a permission
we now allow legacy apps to be able to put at most one
toast window on the screen to prevent adding the same
window over and over again to go around the new restriction
that toast windows are always removed after a timeout.
This change ensures that Toast removes its window immediately.
bug:31340854
Change-Id: Ia7f90844eb64b583321103d090e4407038b41547
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
