A final layout pass should be done whenever the status bar has
completed its incoming animation.
Fixes bug 10387660.
Change-Id: I48c19015c53116b58cf73e20be32d1f64dd682ca
When the contextual action bar is not in overlay mode,
the screen layout is a linear layout. (screen_simple.xml)
Ensure the standalone CAB appears below the status bar,
consumes the top offset (to avoid content application below it)
and fill in the status area with a guard view for background
protection.
Bug:10014069
Change-Id: I614f16dfa77367a94808aef54710ffebd66e1ca8
Although the IME windows are now allowed to extend into
the nav bar, some IMEs were making assumptions about
computed insets based on the height of the content view.
So our navigation bar view (opaque view blocking the nav bar
area to avoid the island effect when transparent) needs to live
above the content view in the hierarchy, making the content view
the same height as it was before.
A surgical spot to put the guard view is up at the root view
(PhoneWindow.DecorView). fitSystemWindows is always called since
this view is not recreated, and the layout is stable: waiting until
the IME is attached to the window is too late to add a guard view.
This is above the screen_* layouts, so will work without having to
touch all of them. And it only affects windows of TYPE_INPUT_METHOD.
Bug:11237795
Change-Id: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
While under heavy system load, keyguard was able to create widgets before
before ActivityManagerService was ready. The result was a race
between keyguard adding widgets and ActivityManagerService being
ready to send broadcasts.
This fix provides keyguard with an additional signal to know when
the system is booted and widgets are safe to load.
Fixes bug b/11217169
Change-Id: I7a714d65b068678f961e52bdde4e1c20f9c287f0
If the keyguard is the wallpaper target the wallpaper cannot sit at
the bottom of the stack and must be directly beneath the keyguard.
Otherwise keep it at the bottom of the window stack.
App animations when the keyguard is showing should not be disabled if
the keyguard is also animating.
Fixes bug 10858941.
Fixes bug 10932680.
Change-Id: I8399837f6510ea16003f68b165e67439f3571ef4
Setting config_enableTranslucentDecor to false will not
prevent clients from adding FLAG_TRANSLUCENT_NAVIGATION or
STATUS to the window or using the TransluentDecor themes,
but it will prevent View.STATUS_BAR_TRANSLUCENT and
View.NAVIGATION_BAR_TRANSLUCENT from being propagated to the
SystemUI so these requests will not be honored.
Bug: 11182618
Change-Id: I8be6a3a565acf0987ff12f18f1c7e67c96d563c3
Migrate transient bar mode to IMMERSIVE_STICKY, and
introduce new behavior for IMMERSIVE: namely the
opaque bars are revealed by clearing the flags on swipe.
Remove low-profile optimization that confuses api demos
and other apps using low-profile as a signal.
TransientNavigationConfirmation renamed to
ImmersiveModeConfirmation, and its associated resources,
since the confirmation is now shown when the nav bar is
shown in either of the two immersive modes.
Remove unused Toast.makeBar and associated hidden framework
bits now that the confirmation uses a cling instead.
Bug:11062108
Change-Id: Iae49d31973940b9bee9f5b1827756db5eaa76aa3
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
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
Instead of keeping a single global system decor rect around
in WindowManagerService, calculate and store policy-defined
system-decor frame for each window.
The per-window decor rect is useful for smooth transitions, since it
determines window cropping during transition animations.
Bug:10938001
Change-Id: Ice6652aa5946027c45c0b7ab4e46473a0f8e3f90
Since binder call permissions are not transitive by design,
the proper way to fix this is to have the call talk directly
to keyguard from the navigation bar.
Fixes bug 9409008
Change-Id: Ibd90a79bb638c969b514455a2ad93c6ff668222d
- add accessibility descriptions to camera and search light
- add new onClick handler to simplify launching search and camera
- plumb camera launch through KeyguardService interface
Fixes bug 10914360
Change-Id: Ic85eda9afadba7381be78b477180f7204030cd17
Sysui vis needs to be recomputed in the same code path as showing/
hiding the system bar (code path = finishPostLayoutPolicyLw) so
it can perform the new fade in/fade out to transparent modes at
the correct time.
Turns out no new state tracking is required, we already keep track
of this window as mTopFullscreenOpaqueWindowState.
So prefer mFocusedWindow when computing sysui vis as before,
but if null fallback to mTopFullscreenOpaqueWindowState.
Bug:10561554
Change-Id: I492766989a67fdac4f030451dcf00f6741a556c0
This adds a camera button on phones that can be used to show
and launch the camera.
- Minor refactoring of touch event dispatch in PagedView.
- Disables usability hints when keyguard loads.
- Only add a touch handler for camera icon once during layout.
- Update after review.
- Updated with latest UX camera and camera background assets
Change-Id: I09cd5cb0e501fd0f4659bea96d00c92b07f805c4
1. Decrease transient navigation confirmation annoyance.
- Only use the power-key as a signal if we detect a screen-off
screen-on within a short threshold value.
- Auto-confirm if user performs the indicated gesture.
- Remember confirmation across reboots.
2. Update wording to new final wording. Remove now obsolete
short + long versions. Decrease message font temporarily
until the new platform toast redesign is finalized.
3. Remove pre-ship ImmersiveModeTesting debug helper.
Bug:10602929
Change-Id: I0bff826391058c7b282eeb61817b93b79de84893
Part 1 of 2: Ignore remembered sysui visibility transparent flag
value when computing global content frame.
Since this fixes a visible window layout glitch, get this in asap.
Bug:10561554
Change-Id: Ia3fd69ee65eb3f34fb3a684b697c98e37fabc0b0
Move all visual application of the legacy lights-out behind
a new mode managed by BarTransitions for better coordination.
Remove unused "hidden" state in NavigationBarView.
Improve window state (showing/hiding/hidden) calculation,
affecting whether or not sysui thinks it should animate.
Removes invalid interim mode changes causing needless
flashing during some transitions.
Consider WINDOW_STATE_HIDING a state in which we ought to animate,
since at least part of the window is visible throughout.
Make the status/nav bar transition helper classes real boys.
Animate KeyButtonView drawing alpha transition, cancel existing
animations when resetting to avoid needless and unsightly "recovery".
Bug:10746803
Change-Id: Ibd883da9041d071b6a4ff5b42cf96efba7696e9c
Provide a softer transition to the overflow-everywhere world for
devices with menu keys. The panel menu will still be used on these
devices in response to a menu key press even in the presence of an
action bar with overflow.
Fix a few lingering bugs around dispatching the open-overflow
transition that caused problems with this along the way.
Change-Id: I9d77c70f6d15c47160ac06292984101d619c44e6
java.lang.SecurityException: Operation not allowed
There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.
To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.
I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.
Also improve the security exception throw to have a more descriptive
error message.
Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
Fetching current user id from activity causes a deadlock when
holding the window manager lock.
Fixes bug 10555852.
Change-Id: Ib7911ef28b81aaf7f02cce311be193b36677a26d
And decouple it from the status bar opaque-on-interaction logic.
It's still important to track nav bar interaction for hideybar
suspension purposes.
Also fix a sysui NPE that can occur when restarting SystemUI
(vs the shell).
Bug:10606136
Change-Id: I66a15e02cff352e26b25aebc1c42fb58c042effa
