The lights-out shadow view is now the same height as the system bar.
This makes for a better looking animation (no cropping) and positions
the dots in the right place.
Bug: 6722791
Change-Id: Ifc2cc1586cd72a81a7bb801442be4fa4e03da2a5
Protect tablet users going through the initial setup wizard from trapping
themselves in Settings before the setup wizard is complete. A similar change
was already made for phones, so use the same logic.
Also hide quick-settings button (another way to get trapped in Settings) and
associated panel click handler. Remove clear button since we're no longer
showing notification items.
Bug: 6704080
Change-Id: If7148cde9d18f493627f8367fd4b39d22e0d5ef1
Fix a bug where a newly added group had no supported types at the time
of callback dispatch, meaning that no registered callbacks would be
invoked.
Fix a bug where subscribed type flags were not updated properly when
re-adding a callback for new types.
Change-Id: I7d9f11b363ebdca692786cec1d432600946e5721
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
Bug 6720224
When a window dies it's possible to receive a lingering ACTION_CANCEL
event to the SeekBar for volume. Be sure that we don't try to mess
with something that's already gone by that point.
Change-Id: I4f6119718fc21204d9013d591bc984b785b698b4
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
Bug 6521608
When there are no custom views or other actionable views next to the
action bar's home/up affordance, expand the touch target by a generous
slop value. This helps frustrating cases where a user accidentally
hits just to the right of Up and nothing happens.
Change-Id: I09ef604ce70ad380aab62a373b04c4b02007c644
In the course of the window manager refactoring into a separate
layout state, we introduced a bad interaction between the two
sides of the world. This resulting in multiple hops needed between
the two sides after an application has said it is finished drawing
its window, until the window/app transition is actually started.
Especially since these hops require going through the anim side
which is vsynced (so will delay its operation until the next frame),
this could introduce a notable delay until the window is first shown.
Fix this by re-arranging the code to make one straight path from
when a window reports it is shown to us starting the app transition
that is waiting for it. This change also includes various improvements
to debugging code that was done while working on it.
Change-Id: I7883674052da1a58df89cd1d9b8d754843cdd3db
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
We should just say Tablet or Phone when selecting the local
playback instead of Tablet speakers or Phone speaker.
Change-Id: Ia6c439f711bacb7b1e70fbcf4887df8141f91b61
Fix a MediaRouteButton bug where group item counts weren't taken into
account when deciding whether to toggle between two available groups
or show the chooser dialog.
Change-Id: I6400ffd4cfe80c8072c5be360264b8ca91d71c41
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
