Now that non-null window tokens are coming in in additional situations
(ag/372453) we have to look at whether the keyguard is hidden before
deciding to wait for it.
Fixes bug 1187500.
Change-Id: Ie89d5334ab3d0f5b8f2cf8c87fef84a9b6392b72
When the user plays media remotely, and presses on the volume
keys with the screen off, verify whether not only local playback
is active, but also if remote playback is active to see if
the volume should be adjusted.
When adjusting the volume with screen off, adjust the remote
volume if applicable.
When controlling volume, give priority to local media playback.
Bug 11169862
Change-Id: I88a8c003969177d50d4c1569ec6cd2a7c153a341
- Include dreams in the conditions that disable transition animations.
This way there is no visibility of activities that are closing
behind the keyguard when an activity that dismisses the keyguard
starts up.
- Do not notify the keyguard mediator when the keyguard is dismissed
because a dream is starting up. This keeps activities from resuming
just because the keyguard is being dismissed.
Fixes bug 11064847.
Change-Id: I9d32fc96d518b1cdab511e187226a3cb889cf6d4
Make sure the dock rect in PWM takes the nav bar height
into account when translucent. This forms the basis of
many other window calculations, and has multiple downstream
effects.
Fixing this exposed the fact that the Keyguard was not allowed
to fall into the LAYOUT_HIDE_NAV codepath (since it's not an app
window) - so add TYPE_KEYGUARD to that path.
Bug:11157555
Change-Id: I6b1fc4da973a246b80ec108a561e06f6d8a6a92b
Instead of a custom onDraw in order to stay 100% in sync with abrupt
layout changes.
Also use the unrestricted layout bottom to avoid unnecessary
fitSystemWindows churn.
Bug:11162351
Change-Id: If9bb9a52d503e348d642bf1238f75c4a418ad805
Layout IMEs below the nav bar, offset by bottom padding and
associated guard rectangle with a black background to ensure
they do not appear as islands during transitions.
This makes it safe to remove the SystemUI forced opaque transition
when showing an IME, making the overall transition less expensive,
quicker and smoother overall.
Bug:11058746
Change-Id: I460912ee7c117480c57b947ed31eca330819f32c
The requirement that a window that is invisible will not be drawn is
incorrect. In particular the test fails before a surface has even been
added (mHasSurface == false) or shown (mPolicyVisibility == false).
This was causing the screen to turn on before Keyguard had been drawn
and exposing surfaces that would have normally remained hidden.
Also, don't pass null into KeyguardServiceDelegate.onShown() or we
will immediately turn the screen on before Keyguard is drawn.
Fixes bug 11062635.
Change-Id: I964c7ef186d0a94678020b9c27ca6b79e5433350
If a view triggers showContextMenu while a context menu is already
shown but contributes no items to the menu the menu dialog would
become empty. Simply close the dialog if this happens.
Bug 11063885
Change-Id: I9e7c96073318c94eda5f1e1c4beb596b3d9da781
Recently removed when they went private, but that was wrong:
they still affect layout.
Bug:11128955
Change-Id: Ic94230732a6b2ff3dcaa79b03e181a4e46585902
They can affect the system decor state, cropping to their
current requested state is too aggressive.
Bug:11079003
Change-Id: Ifec576d41cdefd1b851463d4b12311f1a8e27b3d
Specifically, ignore any flags that alter the visibility of the navigation
bar and transparency.
BUG: 11082573
Change-Id: I17264dc55a1c6c3cb9b9cf92d5121799cecee5b8
Migrate View.SYSTEM_UI_FLAG_TRANSPARENT_(STATUS/NAVIGATION) to
WindowManager.LayoutParams.FLAG_TRANSLUCENT_(STATUS|NAVIGATION).
Add associated public attrs for both new window flags:
windowTranslucentStatus
windowTranslucentNavigation
Introduce convenient four new themes that set translucent decor:
Theme.Holo.NoActionBar.TranslucentDecor
Theme.Holo.Light.NoActionBar.TranslucentDecor
Theme.DeviceDefault.NoActionBar.TranslucentDecor
Theme.DeviceDefault.Light.NoActionBar.TranslucentDecor
Update PhoneWindowManager mechanism to plumb these values back to
SystemUI to drive bar mode state.
The new translucent flags come from the top fullscreen window, not
the focused window, so translucency does not change when opening
dialogs.
Imply some window-level system-ui visibility if one or both of these
new flags are present, specifically:
FLAG_TRANSLUCENT_STATUS implies LAYOUT_STABLE, LAYOUT_FULLSCREEN
FLAG_TRANSLUCENT_NAVIGATION implies LAYOUT STABLE, LAYOUT_HIDE_NAV
Rename all associated variable & resource names to use the term
translucent instead of transparent. (Retain the term semi-transparent
for the transient bar style).
Recents activity allowed to inherit translucent decor state via the
new PRIVATE_FLAG_INHERIT_TRANSLUCENT_DECOR. Compensating changes
to use the full screen area more appropriately.
Update keyguard to use new WM flags.
Update docs and various api artifacts.
Sanity-check fixes:
- Toasts and alerts given stable layout.
- Suppress nu-gradient when in transient (hidey) mode.
- New translucent flags use top-fullscreen window, dialogs don't clear.
Bug:10674960
Bug:11062108
Bug:10987178
Bug:10786445
Bug:10781433
Change-Id: If667a55bea4cf5e008549524b9899197fab55ebe
