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
Now that we have APIs to query all interactive windows and allow
an accessibility service to put accessibility focus in each of
them we have to guarantee that there is a single accessibility
focus. This is required for correct operation of the touch
explorer as on double tap in clicks in the center of the focused
area, hence having more that one focus is an issue. Also the
system is maintaining a single input focus so now accessibility
focus behaves consistently with that.
bug:13965563
Change-Id: I0b5c26dadfabbf80dbed8dc4602073aa575ac179
