From its beginning, InputMethodService#onUpdateCursor has
provided the cursor position in local coordinates in the attached
view. However, the local coordinates is not useful for IMEs
to render a floating UI near the cursor because the IME is not
able to know the origin of the attached view.
With this CL, CURSOR_ANCHOR_MONITOR_MODE_CURSOR_RECT also means
that the IME will receive the cursor position in screen
coordinates. Because this is a new constant in the next release,
conditionally changing the coordinates never causes
compatibility issues as long as its behavior is well documented.
BUG: 14323360
Change-Id: I3acf2317ae1d763d11dae5ef73c2a1348b377c71
Also fixes row clipping and ripple alpha channel. Only supports showing
ripple on a single list row -- multiple rows for focus traversal and
drag-to-open are coming soon.
BUG: 13212804
BUG: 14257108
Change-Id: Ided15611dc868a513e8d2a994723cdf57b0d206c
Start ScrollView's nested scroll in onIntercept to signal nested
scrolling parents not to intercept along the vertical axis.
Change-Id: Ieb343ff6b8216b113d3876bf93a804e609257f2a
or, "Excuse me, Egon, you said crossing the streams was bad."
Add API for driving a nested scroll from the most deeply nested
applicable scrolling view. The deepest scrolling view dispatches
high-level scrolling events up to cooperative parent views.
Augment ScrollView to support nested scrolling. Next up, more public
framework scrolling views.
Change-Id: I53b5e207fcdece796e08c8592ddb4496b96f600e
The change adds the view cookies for the menus rendered in the action
bar. This enables the IDE to map the menu to the relevant XML Tag in the
menu xml and show the highlighting accordingly.
Change-Id: Idcfc263a8ebe0a4f25afa3a1eb085fa628fd03ca
If no IME was present, InputEvents such as KeyEvents
would simple be dropped instead of going through
to the Activity's View hierarchy.
Change-Id: I9de25bdbf5d1564b77b25679e19dae18591a8c1c
A TvInputService app developers sometimes want to draw UI above a surface
playing TV. For this purpose, we add a window in TIS and allow developers to
attach their customized view on the TV surface.
Change-Id: I65c3dffa17580b8d4c42fac58bbfc8dad338c185
Fixed a bug where a ViewGroup did not clip its children to the
set clipBounds unless willNotDraw was set to true.
Bug: 14104527
Change-Id: I4892639bb860c1767f1ae6892f3e69525691e55e
isRound allows a view to determine whether the window it is contained
within obscures the corners of the window content. This allows views
aware of this property to adapt their layout accordingly.
Switch ViewRootImpl to use dispatchApplyInsets instead of
fitSystemWindows.
Change-Id: Ic3e3936b73815b2593cb9720af1a309fbd18406e
Conflicts:
core/java/android/view/ViewRootImpl.java
isRound allows a view to determine whether the window it is contained
within obscures the corners of the window content. This allows views
aware of this property to adapt their layout accordingly.
Switch ViewRootImpl to use dispatchApplyInsets instead of
fitSystemWindows.
Change-Id: Ic3e3936b73815b2593cb9720af1a309fbd18406e
Applying insets is now handled by:
* WindowInsets class - Encapsulate system insets and local decor
insets into a single object, written specifically so that new inset
categories may be added later. Apps cannot construct their own
WindowInsets, only clone with optional modifications. This is to
prevent losing data in the event of new insets added in the future.
* onApplyWindowInsets - Actually perform the application of insets.
* OnApplyWindowInsetsListener - Allow an app to use a separate
Listener object to apply insets to a View. This allows for things
like support lib integration in custom views written for older
versions where the verifier would otherwise complain about the use
of the new WindowInsets class as a method parameter. It also allows
for applying insets in a custom way without writing a custom view.
* dispatchApplyWindowInsets - Dispatch the call to self and children
in turn, if applicable. An OnApplyWindowInsetsListener will override
the behavior of the view's default onApplyWindowInsets method; a
listener wishing to call down to the 'superclass' implementation as
part of its own operation should call view.onApplyWindowInsets. App
code should generally not override this method and instead override
onApplyWindowInsets or provide a listener.
Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.
Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105
Bug: 14052927
destroyCanvasAndSurface() needs a fence as when it returns the
underlying BufferQueue is going to be released from under
the render thread.
Change-Id: I0147a1d5ec5adf0239c761ef22f65cd8c8a137df
Previously, the view hierarchy would suppress drawing whenever the
PowerManager.isScreenOn() method returned false. However, this method
really describes the interactive state of the device rather than the
actual display state. This is especially a problem when there are
multiple displays but it also breaks drawing while in doze mode.
This change makes the view hierarchy consider the actual state of the
display instead on an individual basis.
Bug: 13133142
Change-Id: I69870b6b14a3504607a30562aa48c3452f777c1f
