If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Background padding should be used only and only if
- no padding is already defined into a layout file
- an explicit call to setBackground() / setBackgroundDrawable() has been done
Change-Id: I0a732c61b898e006ee86377bcbe7691740d68111
Merge GlRenderer and Gl20Renderer
Move GLRenderer to its own file
Move native methods from HardwareRenderer to GLRenderer
Change-Id: Ib4680b03dd98101b2a428062cc94774ff73baa75
This change adds a new media router service whose purpose is to track
global state information associated with media routes. This service
publishes routes to the media router instance in application processes
and handles requested state changes such as selecting or unselecting
global routes. The service also binds to remote display provider
services which can offer new remote display routes to the system.
Includes a test application for manually verifying certain aspects
of the operation of the media router service.
The remote display provider interface is essentially a stripped down
media route provider interface as defined in the support library
media router implementation. For now, it is designed to be used only
by first parties to publish remote display routes to the system so
it is not exposed as public API in the SDK. In the future, the remote
display provider interface will most likely be deprecated and replaced
with a more featureful media route provider interface for third
party integration, similar to what is in the support library today.
Further patch sets integrate these new capabilities into the System UI
and Settings for connecting remote displays.
Bug: 11257292
Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
Add a window feature for content transitions. This implicitly creates
a Scene for each setContentView operation and runs the appropriate
transition. Applications can specify a TransitionManager XML in their
theme that will apply the appropriate transitions when these implicit
scene changes occur. Apps can specify a "to" with no "from" in a
transition to request an entrance transition for the given
content. This lays the groundwork for further full content
change/activity to activity transitions.
Change-Id: Ic815d9e0b9ce958152d70bf6ee01be075aa9fe88
When we dispatch input events into the actual application, make sure
the input invariants we rely on haven't changed. If they have, we
drop the event and log why.
Bug: 11399505
Change-Id: Id772e41ca41dc332bb02725ab486e3b10a73c220
Target the two biggest offenders:
- Coalesce keyguard setHidden(false) calls during unlock.
- Make sysui->WM call async.
Found during investigation into b/11221659.
Bug: 11221659
Change-Id: Icab48376bc356a933e0f9940bc2f924e2e77ab22
With the new tuned vsync offset, vsyncs are likely to occur shortly
after the input is received, meaning we will empty the input queue,
and thus won't schedule input consumption until more input is
received. If an application then speculatively posts draw commands to
the main looper faster than 60 hz, it will eventually end up blocking
in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't
even schedule consumption until after the current frame (8-16ms), and
it's entirely likely we won't actually get around to consuming input
until after the next frame (another 16 ms of latency). This means we
can often go 16-32ms without processing any input events, causing
very noticeable amounts of jank.
Rather than waiting for the next input event to schedule input
consumption, speculatively schedule it every frame as long as we've
consumed some motion batch during this frame.
Bug: 11398045
Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
