Bug #6120957
Using this new callback, views can interrupt and resume their
animations or other periodic tasks based on the current state
of the display.
Change-Id: I398f4abd421e9c5f207107bf1009a7b92cf45daa
When WindowManagerService's events are enabled/disabled, the state of the
display is dispatched to the known windows. This allows ViewRootImpl to
ignore draw requests until the screen is turned back on. This can potentially
lead to significant battery savings. For instance, a launcher widget showing
a repeating animation will cause the CPU and the GPU to wake up regularly
without this change.
(Change submitted by Intel and merged manually)
Change-Id: I7f93b0e60c3e6de1705f619e80860c36b1cdb978
The black frame is now a separate animation element. This allows us
to have it move through the aspect ratio change, without the old
and new screen elements doing weird aspect ratio scalings. This
makes the animation generally look different (more like a reveal),
not sure if it is better or worse, but definitely has less artifacts
in things like the gallery.
Also tweaked the animation definitions a bit.
Change-Id: I94c274ba04bbc7a675946dc6c1778e19386e4a66
Modify test so that rotation animation is entered one final time after rotation completes. This last time causes mUpdateRotation to be set true forcing a test for orientation change.
Fixes bug 6109189.
Change-Id: I25475f336a3439a56b1c540205d09ee48c1d2b7c
Previous approximations weren't indicating completion and windows weren't being layered correctly as a result.
Change-Id: I08fcd278485bb87dc10bca257b9f8073108753f3
Two things: (1) make sure the boot message is always positioned within
the entire unrestricted display, and (2) allow the dim background to go
on top of the nav bar when being used for the boot message (this latter
is really a hack that should be more generally fixed in the future).
Change-Id: I7261b044eb802a39cadff931b50a679ff18781d6
- Move mPolicy.startAnimationLw and mPolicy.finishAnimationLw into same method as mPolicy.animatingWindowLw.
- Fix first parameter of performLayoutLockedInner(initial, ...) to pass true on initial pass.
Change-Id: If1b47bb8a7e03cf427769c657e371abc0910b3e3
There are occasional races during application shut down where the
input dispatcher will close an input channel before the application
has finished its last event. So just ignore EPIPE.
Also tweak the logging for failed input event injection to make
it clearer which pid was trying to perform the injection.
Bug: 6013004
Change-Id: I7bbb01441d41762b03eafd4d39dcf0323e1cadf3
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
If we went through the update loop multiple times, and had finished
animating the first time, we would blow away that information the
second time and never kill the animation.
Also moved killing the animation back up to the animation step --
this involves destroying surfaces and such, and so really should
be done as part of the surface transaction. We can also consider
the screen rotation animation object to be owned by the animation,
so it can destroy it when done.
Change-Id: If24356c509c66d046f2ddfd9ad5bfe12504d7716
Enabled by setting system property ro.config.headless to 1
This will allow the framework to run without starting activities,
system UI and the keyguard.
Framework can still run services, content providers and broadcast receivers.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Conflicts:
policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
services/java/com/android/server/PowerManagerService.java
services/java/com/android/server/am/ActivityManagerService.java
This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
This is an update to a previous CL; this approach uses the WindowManager
to store the animator scale settings, instead of SystemProperties.
Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
This is between the two previous attempts. I returned the part from the
original that was breaking gallery, but have some new code to detect when
something about the window params has changed that would require a
layout pass to make sure we still do a layout then, even if the window is
not currently visible.
Change-Id: I07745e1f66022583e3076b84cc8bbe8bd2acd48f
We now have an animation that can start as soon as we detect to
rotate the screen, and have a different phase once the new UI
is ready to complete the transition into it.
Change-Id: I05b9c12a699232acbddc36b4a994a4452db71476
This increases lock screen's thread priority from THREAD_PRIORITY_FOREGROUND
to THREAD_PRIORITY_DISPLAY to ensure it runs before other activities that
might stall lock screen when the screen turns on.
Change-Id: I14cf9f3f5c092817bc6cf2d0a254001a5d34f744
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
This fix does not include the change to ignore app tokens that are
hidden. This causes problems in some dialogs that stay hidden until
their app is ready to display, but need to perform a series of relayouts
during that time to get to the right size. Dropping this part of
the change still (mostly?) seems to allow us to avoid the bad states.
Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
Also don't consider windows a candidate for layout if their app token
is hidden. This fixes a transient state where we are preparing to
unhide the window but have not done so yet.
Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency
optimization.
This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.
Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
Make surface management between SurfaceView and the window manager
much more controlled, to ensure that SurfaceView always gets to report
the current surface is destroyed before the window manager actually
destroys it.
Also a small tweak to allow windows that have a wallpaper background
to still have a preview window. This makes launching home after it
has been killed feel much more responsive.
Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
