When launching only core apps, the wallpaper service
is not started. Without this change the WM waits
up to 30 seconds for the wallpaper window to be created even
though it will never happen. This introduces a significant
delay before the boot animation is dismissed so the user can
enter a decryption password.
Bug: 6263070
Change-Id: Ia975127a0bf09cf99818f7cc4fd6c0264b740ec6
The Starting window was being made visible early because the app
token had the dummy animation set. When the real animation started
the Starting window picked it up and became transparent causing
the underlying window to become visible again => jank.
Fixes bug 6691421.
Change-Id: I95fe88d2887760e6da3adedeb6be300eb6755283
Set up the Choreographer call from the animator, not from the
layout side. Introduce new class for transferring information from
layout to animator.
Change-Id: I7da032990f4b5eaeefcf92185901d896f25db3d2
Three problems fixed:
1. When one Activity took over for another Activity not all of the
starting window state was being copied over. Now copying over more
parameters.
2. When the visibility of an Activity was being changed the dummy
animation was overwriting the existing animation. If that animation
was the starting window animating then it started over when the
dummy animation was assigned. Now the dummy animation no longer
replaces an existing starting window animation.
3. The test for whether to animate away the starting window only
looked to see if the Activity had already drawn a window but did
not include the starting window. This caused the starting window
to immediately be hidden when the Activity was removed if no
windows were drawn, thereby exposing the fading window behind.
Now the starting window is included in the hasAppShownWindows test
and is animated away if it is exposed.
Fixes bug 6691421.
Change-Id: I4d32a1546c201652574a44d9e7f2752f1f1eb5a6
This normally shouldn't noramlly happen, but it can in the case of
bug 6647334 (crash in LoadedApk.makeApplication) where the package
manager information becomes inconsistent, and it could also happen
if an app was uninstalled or started updating at just the right
time during a launch.
Bug: 6647334
Change-Id: Iba22efe1d646cdac46099b2135466309577dfa54
...lock screen does not response to onNewIntent()
We now keep activities stopped even while the lock screen is
displayed. (We used to keep them stopped while the screen was
off, and then resume the top activity when the screen was turned
on even though they are covered by the lock screen.)
When a new intent is being delivered to an application, if it
is not resumed it is held in a pending list until the next
time the activity is resumed. Unfortunately that means for
the case where the activity is being held stopped due to the
screen off or lock screen, it will not receive any new intents,
even though it is at the top of the stack.
Fix this by adding an additional condition that allows the new
intent to be delivered immediately if the activity manager is
sleeping and the target activity is at the top of the stack.
Also some debug output improvements, since pending new intents
were not being included in the debug output, making it impossible
to see we were in that situation.
Change-Id: I5df82ac21657f1c82e05fd8bf21474e883f44e6f
...or settings from lock screen
When a window is drawn, the code to determine whether it should now
be shown was calling WindowState.isReadyForDisplay(). Part of the
condition of this function is that it is not ready if a policy is
forcing the window to be hidden -- which is the case when the lock
screen is shown. As a result, we wouldn't show the window at that
point, so wouldn't tell the activity manager that the token's windows
are visibible, and wouldn't tell the lock screen to go away.
This adds a new variation WindowState.isReadyForDisplayIgnoringKeyguard(),
which is the same as the original method but ignores the policy visibility
for app windows. This allows windows to be go through the complete
path of handling when the window is finally drawn and telling the
activity manager about it, even if behind the lock screen. By making it
a separate function, we don't impact any other code that is calling the
old function and may be relying on its behavior.
Also cleaned up a little of the dumpsys output. Most important, the
new ANR section is now moved to the top, since we want
"adb shell dumpsys window" to still give a nice summary of what we
normally care about -- the window stack and important global state.
Change-Id: Ica3ea85ce46f3f5f5cd2cc30fbd9de13d3885a57
This fix adjusts the sensitivity of the gesture recognizer by
eliminating gesture rotation in the recognition process.
Bug:6697119
Change-Id: Ic767f513c05210b27e583338c4f0adcaa1c4c625
