This helps reduce the pressure on framework.jar, and makes it clear
that it should only be used by the system_server.
Bug: 7333397
Change-Id: I0858904239535380fbf30562b793e277d8c3f054
Do not treat a window that is animating as being onscreen until it
has been drawn. The indication that a window was "gone" was occurring
too soon resulting in windows appearing before the status bar came
back and having to be drawn twice, with and without the status bar.
By waiting for the window to be drawn the status bar appears and the
window does not have to get redrawn.
Bug 7696315 fixed.
Change-Id: Ic93bf6eed03cf12a92a656791725a6d26e0ad0e9
RecentsActivity screenshots are called for very quickly after
WindowStateAnimator prepareSurface(). Without enough delay the
Surface.setLayer call does not propagate to the SurfaceFlinger
and the screenshot is incorrect (black) because it stops sampling
the layers too early.
This fix calls Surface.setSize() for each sampled Surface in
screenshots. setSize forces the SurfaceFlinger to process all
transactions queued before returning from closeTransaction.
Bug 7552304 fixed.
Change-Id: I1911dfa0b09cab713c55f5ba0c612496337a77df
Conflicts:
services/java/com/android/server/wm/WindowManagerService.java
Improves the throughput of IME event handling by ensuring that
input events do not get serialized behind UI traversal and
drawing messages such as when the UI is animating.
Added support for creating an asynchronous Handler as part of a
HandlerCaller. It turns out we should be using an asynchronous
Handler not only in IME dispatch but also in accessibility and
wallpaper events where HandlerCaller is used. So fixed those
services to also use an asynchronous Handler.
Change-Id: I0b19140c9d5ca6ee300c1a150c48312fd55ed8eb
Optimize for updating mNetworkPreference according to device's networkAttributes
setting from overlay config.xml when connectivityservice start.
Change-Id: I90286332d4f453038f1ddac7dd9d1265d96b4859
Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
Cherry-pick I88b419c92940b7e536d48b26e5fc0f72f3c9e73d
This is a more complete solution for this issue that disables
location providers when expiring their last request *and* adjusts
update intervals when expiring any request. This should help
further limit battery drain when a high-frequency-update app
exits, as it allows the system to throttle the update interval
back down to something appropriate for the remaining listeners.
Bug: 7611837
Change-Id: I7629a90f4c693be4bf96d662bd3a8b06dae0b089
This is a more complete solution for this issue that disables
location providers when expiring their last request *and* adjusts
update intervals when expiring any request. This should help
further limit battery drain when a high-frequency-update app
exits, as it allows the system to throttle the update interval
back down to something appropriate for the remaining listeners.
Bug: 7611837
Change-Id: I88b419c92940b7e536d48b26e5fc0f72f3c9e73d
Do not pass the pending layout changes from animation to layout.
Simply assign them to the DisplayContent.
Change-Id: I72e48753db509023e5df70513a87e26998ec699f
Load animation parameters dynamically and synchronously rather than
asynchronously. Eliminates storing parameters and cross-barrier method
calls.
Change-Id: Ia9162f0cb3fe60da35fd9fb5f24f31f88891b950
Cherry-pick of Id48151eb7de40164258cde7da220a4d6bb34b89a
Location providers were not being notified of the change in status
when the last UpdateRecord was removed due to numUpdates exhaustion
or request expiry. Oops! Enjoy some free battery life!
Bug: 7611837
Change-Id: I66303b355be4e4a56a81efb5406c9353b2588595
Location providers were not being notified of the change in status
when the last UpdateRecord was removed due to numUpdates exhaustion
or request expiry. Oops! Enjoy some free battery life!
Bug: 7611837
Change-Id: Id48151eb7de40164258cde7da220a4d6bb34b89a
If a rotation occurred while the electron beam surface was showing,
the surface may have appeared in the wrong orientation. We fix this
problem by adjusting the transformation matrix of the electron beam
surface according to the display orientation whenever a display
transaction occurs.
The rotation itself is allowed to proceed but it is not visible
to the user. We must let this happen so that the lock screen
is correctly oriented when the screen is turned back on.
Note that the electron beam surface serves two purposes.
First, it is used to play the screen off animation.
When the animation is finished, the surface remains visible but is
solid black. Then we turn the screen off.
Second, when we turn the screen back on we leave the electron beam
surface showing until the window manager is ready to show the
new content. This prevents the user from seeing a flash of the
old content while the screen is being turned on. When everything is
ready, we dismiss the electron beam.
It's important for the electron beam to remain visible for
the entire duration from just before the screen is turned off until
after the screen is turned on and is ready to be seen. This is
why we cannot fix the bug by deferring rotation or otherwise
getting in the way of the window manager doing what it needs
to do to get the screen ready when the screen is turned on again.
Bug: 7479740
Change-Id: I2fcf35114ad9b2e00fdfc67793be6df62c8dc4c3
