summaryrefslogtreecommitdiff
path: root/core/java/android/view/WindowManagerPolicy.java
Commit message (Collapse)AuthorAgeFilesLines
* WM: Move WindowManagerPolicy, DisplayFrames and WindowManagerInternal into ↵Adrian Roos2017-11-231-1776/+0
| | | | | | | | | | services Splits WindowManagerPolicy into a framework and a services part, preventing concepts that are internal to the window manager from leaking out into the framework. Test: make droid Change-Id: I7b6a54f55f76f6fbb5f27090981b8f1d4d8be88b
* Re-implement Z-ordering based off SurfaceControl hierarchy.Robert Carr2017-11-201-8/+0
| | | | | | | | | | | | | | | | | First steps in using the SurfaceControl hierarchy pervasively through the WindowManager. For each level of the WindowContainer hierarchy we instantiate a buffer-less SurfaceControl which is used to apply constraints to all of it's children. For now we use full-screen surfaces at every non-leaf level and so the only constraint we apply is Z-ordering. Calculation of Z-ordering is done through the WindowContainer#assignLayers pass and begins with DisplayContent. Changes are accumulated in-to a pending transaction which is applied as part of prepareSurfaces (which now applies to each level of the WindowContainer hierarchy rather than just windows). Bug: 64815723 Test: Existing tests pass. go/wm-smoke. ZOrderTests. Change-Id: Ib31bc3107c7fa398cf2ed72430fcb7596fad6fd5
* Support insets on secondary displaysWale Ogunwale2017-11-141-46/+16
| | | | | | | | | | Indroduced DisplayFrames object to track frames used to calculate window insets per display vs. at a global level in PhoneWindowManager. Bug: 64148922 Change-Id: I19f166920eba0a4f933a223a77e096bcc8dab0c1 Test: bit FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests Test: go/wm-smoke
* Revert "Support insets on secondary displays"Wale Ogunwale2017-11-131-16/+46
| | | | | | | | This reverts commit 9bc2692939d4dececbfde5ea67df4594a7842bd1. Change-Id: Ia065372e9e220e653b4729a290663c3536d99307 Fixes: 69241956 Bug: 64148922
* Support insets on secondary displaysWale Ogunwale2017-11-101-46/+16
| | | | | | | | | | Indroduced DisplayFrames object to track frames used to calculate window insets per display vs. at a global level in PhoneWindowManager. Bug: 64148922 Test: bit FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests Test: go/wm-smoke Change-Id: I4a668d6c2dd0bfa666cb6acecf663cf83545ea87
* Support for WM.LayoutParams.PRIVATE_FLAG_IS_SCREEN_DECOR.Wale Ogunwale2017-11-051-3/+4
| | | | | | | | | | | Allow any process with the STATUS_BAR_SERVICE permission to add a window that would be considered a screen decoration by the system similar to the nav bar or status bar. Test: bit FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests Bug: 68002203 Bug: 64148922 Change-Id: I8c78b82c10c638b54a528a77b96f5bf8dd18bf6f
* Removed remaining use of static stack ids.Wale Ogunwale2017-10-111-5/+2
| | | | | | | | | Replace by windowingMode and activityType. Test: Existing tests pass. Test: go/wm-smoke Bug: 64146578 Change-Id: I2ff026de3ead1a3e7136df17c68ed37d7aae5495
* HOME_STACK_ID, ASSISTANT_STACK_ID, and RECENTS_STACK_ID be gone!Wale Ogunwale2017-09-271-2/+3
| | | | | | | | | | Replaced usages with ACTIVITY_TYPE_HOME, ACTIVITY_TYPE_ASSISTANT and ACTIVITY_TYPE_RECENTS. Test: go/wm-smoke Test: Existing tests pass. Bug: 64146578 Change-Id: I62c55c99df86dba8c9ba9d9986049de1b1083234
* Improve WMP dumpsys readability.Michael Wright2017-09-181-0/+62
| | | | | | | | | | It's hard enough to read bugreports without having to decipher all of the various IntDef's littered around; let's go ahead and just translate them to something readable. Bug: 65563703 Test: adb shell dumpsys window policy Change-Id: Iea6cd309eb3411a65e54217fef814a66107a8e31
* Merge "Sleep activities with AOD" into oc-mr1-dev am: f1ef6ef742Jorim Jaggi2017-08-241-2/+9
|\ | | | | | | | | | | am: 2b99571564 Change-Id: Iae4b6dd49ba82cff1ba17b0d1265a085e1ad459e
| * Sleep activities with AODJorim Jaggi2017-08-231-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously in the last release we started sleeping as soon as the device was not interactive anymore. However, this caused issues with ambiactive activites on Android Wear. Instead, we introduce a new private flag on a window that signals that all activities should be put to sleep. We use this flag in SystemUI as soon as SystemUI is "dozing", which means its ambient display is showing. This flag gets set before we request PWM to wake-up, so it's ensured that this will not cause any spurious lifecycle events. Test: go/wm-smoke Test: android.server.cts.KeyguardTests Change-Id: I20f6dd4bfde220f945ef94d2ac1b89dd3694de32 Fixes: 64940094
* | Update WindowManager to output dumpsys in protobuf formatSteven Timotius2017-08-141-0/+9
|/ | | | | | | | | Implement enough functionality in protobuf dumpsys to replicate old functionaltiy in android.server.cts.WindowManagerState Test: cts-tradefed run commandAndExit cts-dev --module CtsWindowManagerHostTestCases cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases Change-Id: Ib527ab3f44620a08cf03b77c37c2bae883d90e13
* Fix keyboard focus in VRTarandeep Singh2017-08-021-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Consider this VirtualDisplay (VD) scenario: HostActivity creates a VD which holds SettingsActivity. When EditText on SettingsActivity is tapped, it gains focus. On eventual taps, it loses focus i.e. the Window in VD loses focus and the host activity in primary display gets the focus instead. This happens because WM's TaskTapPointerEventListener.onPointerEvent() is called on the default display only. Root cause: 1. Tap detector isn't registered for non-default display. 2. Tap detector has no info on which displayId touch was received. 3. InputFlinger doesn't deliver InputMonitor events for non-default displays (fixed in a separate CL) Fixing above results in onPointerEvent(MotionEvent) to deliver the Touch events successfully to VD. We restrict these changes to physical multi-displays and VR VirtualDisplays (which uses virtual touch device). [VrManagerService calls WMInternal.setVr2dDisplayId(int)] In future, displayId should be part of InputEvent. Bug: 64258305 Bug: 62033391 Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests Change-Id: I3626f4de5aa9bcf905da9abd39f3ab1baefc4c48
* AOD: Prevent animations and rotations while going to sleepAdrian Roos2017-07-201-5/+4
| | | | | | | | | | | | | | A recent change allowed animations while the screen is turning on, but not fully turned on; this allows rotations while the device is going to sleep though. To prevent that, we now disallow animations if the device is going to sleep too. In addition, we also prevent the rotation animation when the screen is not fully on or non-interactive. Change-Id: I9b84f68a02a07067e48b11c008bcaf4bcb7c41a0 Fixes: 63760853 Test: Turn phone to landscape on an app that can rotate. Press power button. Verify AOD shows without a rotation; go/wm-smoke
* Position app with short aspect ratio opposite of nav barAndrii Kulian2017-07-121-0/+13
| | | | | | | | | | | | | | When an application doesn't support tall aspect ratio of the screen where it's displayed, it should be positioned on the opposite side from navigation bar. It's supposed to create an effect of extended black nav bar. Bug: 62893418 Test: go/wm-smoke Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarBottom Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarLeft Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarRight Change-Id: I2cd3d236ee8d0cc263fee4c0a436d78c755eb9b7
* AOD: Skip window animations while dozingAdrian Roos2017-07-061-0/+9
| | | | | | Fixes: 37245619 Test: go/wm-smoke; Go to home, turn off phone, observe that during the transition to AOD the navigation bar hide animation does not play. Change-Id: I9a2fce4295900648a680e8e7e8fee0fbb447dd3d
* Fix window affecting SysUi visibility for once and allJorim Jaggi2017-05-231-0/+7
| | | | | | | | | | | | | | This unforunately introduces another quasi-visibiltiy method but I think this is the best solution, as the code is pretty clean. Test: Navigate through, settings, make sure no flickering Test: Launch music from notification Test: Launch United app Test: Go settings -> app -> settings repeadetly 100 times, make sure light bar transition is always clean Fixes: 38216281 Change-Id: I0b97334dea3bfef2966ad0c7dd8bbd9907f2574c
* Merge "Wait for keyguard draw before stopping boot animation" into oc-devKeun-young Park2017-05-191-0/+12
|\
| * Wait for keyguard draw before stopping boot animationKeun-young Park2017-05-191-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add check for keyguard drawn before stopping boot animation. Otherwise blank screen can happen. - Bind to keyguard service when sysui is launched to reduce waiting time later. - Increase keyguard timeout to 5 secs if it is not boot completed. Otherwise (= normal screen on), keep the current 1 sec. This timeout can still lead into blank screen so use bigger timeout during boot-up to prevent such case. bug: 37867510 Test: many reboots Change-Id: Ibfdc42d295bb1d3f5b4ea316fe5aca9ab875e4be
* | Take snapshot when screen is turning offJorim Jaggi2017-05-191-0/+23
|/ | | | | | | | | | | | | | | | | | | | | Since we can't take a snapshot when screen is turned off, we need to snapshot before we are turning the screen off. For this, we - Add a callback from DisplayPowerController to give policy a chance to do something before display will be turned off. - Implement this callback by taking snapshots of all visible tasks. Test: Inspect logs/traces about screen off blocking to make sure callback is working correctly. Test: Insert artificial 500ms delay in onScreenTurningOff and make sure we are unblocking screen off when turning on screen in the meantime. Test: Open Maps, go to recents, open maps again, scroll to another location, toggle power button, make sure the old location isn't shown during unlock. Change-Id: I489f31358f838d418f894f996495946084f136a4 Fixes: 37107783
* A new power button mode to hide the IME when shownYohei Yukawa2017-04-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in Bug 33038203 on certain platforms there is a demand that the power button can change the behavior depending on whether an IME window is shown on the screen or not. The behavior requested here can be summarized into two parts: * Hide the IME window if it is shown [1] * Go to the home screen if no IME window is shown This CL implements the above request by introducing a new config mode for config_shortPressOnPowerBehavior. Note the definition of when an IME is shown is often tricky than people would expect. The way this CL is implemented is to propagate IME window state from InputMethodManagerService (IMMS) to PhoneWindowManager via WindowManagerService regarding when the back button on the NavBar for phones/tablets should be shown as an IME dismiss key [2]. [1]: Even with this CL the IME still is allowed to ignore the request to hide the software keyboard. Currently there is no official protocol to forcefully hide the software keyboard. How to deal with such a situation is a long standing TODO task. [2]: Internally this is controlled by the following IMMS fields: - InputMethodManagerService#mImeWindowVis - InputMethodManagerService#mBackDisposition Note that those fields rely on self-report from the IME. To be precise, the base implementation of InputMethodService is responsible for report back its internal state to IMMS when necessary. The important point is that, although this could allow a malicious IME to confuse the system UI to some extent, supporting malicious IMEs is not clearly a goal of Android. Anyway, the definition of when an IME is shown is a kind of hot topic in several system services recently. Hopefully we can come up with better definition and reliable mechanism in a future release. Fixes: 33824860 Test: Manually verified as follows 1. Change config_shortPressOnPowerBehavior to "5" 2. Rebuilt the OS image and flash it to the device 3. Make sure that the power button works like a home button if software keyboard is not shown. 4. Open dialer and focus in to the text field shown on top 5. Make sure that the AOSP keyboard is shown. 6. Run 'adb shell dumpsys input_method' to observe the following line: mImeWindowVis=Active|Visible 7. Tap the power button to make sure that the AOSP keyboard gets dismissed. 8. Tap the power button again to make sure that it works as if a home button. Test: Manually tested as follows 1. Open dialer and focus in to the text field to show an IME 2. Run 'adb shell dumpsys window policy' to make sure mDismissImeOnBackKeyPressed=true 3. Tap the back button to dismiss the IME 4. Run 'adb shell dumpsys window policy' to make sure mDismissImeOnBackKeyPressed=false Change-Id: I20721547c73360a70b5fc5cbe06824d577d1768a
* Ensure we show the PiP menu in response to KEYCODE_WINDOW.Winson Chung2017-03-311-1/+1
| | | | | | | Bug: 36687605 Test: android.server.cts.ActivityManagerPinnedStackTests Test: #testWindowButtonEntersPip Change-Id: I0bb35fd666eb6a438e4676267f6726b44bffb3db
* Set oom adj for processes displaying app-overlays to PERCEPTIBLE_APP_ADJWale Ogunwale2017-02-121-3/+3
| | | | | | | | | | | | | For processes with a window of type TYPE_APPLICATION_OVERLAY adjust their oom importance to PERCEPTIBLE_APP_ADJ to reduce the chance of them getting killed by the low-memory-killer since they are displaying something that is perceptible to the user. Also z-order TYPE_DREAM windows above alerts windows. Bug: 33256752 Test: cts/.../run-test CtsAppTestCases android.app.cts.AlertWindowsTests Change-Id: I4c05a9fee6fad61399bf4d10c8647467cc596ca6
* Alert Windows behavioral changesWale Ogunwale2017-02-021-9/+217
| | | | | | | | | | | | | | | | | | | | - Introduced TYPE_APPLICATION_OVERLAY window type. Can be used by apps to display windows on top of other app windows, but below critical system windows. - Deprecate alert window types TYPE_PHONE, TYPE_SYSTEM_ALERT, TYPE_SYSTEM_OVERLAY, TYPE_PRIORITY_PHONE, and TYPE_SYSTEM_ERROR. Apps should now use TYPE_APP_OVERLAY for this. - Apps targetting O or greater are not allowed to add the old alert window types. Apps targetting less than O can still add the old types. Apps with permission INTERNAL_SYSTEM_WINDOW (system signature apps) can still add the old types. - Z-order old alert windows types below TYPE_APPLICATION_OVERLAY if they are added by an app without the INTERNAL_SYSTEM_WINDOW permission. Test: android.server.cts.AlertWindowsTests Bug: 33256752 Change-Id: I12170955a7a333151d3387c169b51c53c32164fc
* Set permissions for launching on private displaysAndrii Kulian2017-01-201-1/+2
| | | | | | | | | | | | | | | | - System UIDs must be allowed to launch anything and everywhere. - Display owner must be allowed to launch activities on it. - Apps that are already on target display must be allowed to launch there. - All other apps mustn't be allowed to launch on private displays. Bug: 34230873 Test: android.server.cts.ActivityManagerDisplayTests Test: #testPermissionLaunchFromSystem Test: #testPermissionLaunchFromAppOnSecondary Test: #testPermissionLaunchFromOwner Test: #testPermissionLaunchFromDifferentApp Change-Id: Ic98005649a6368370c512e822cba4e9decc18ae9
* Initial implementation of snapshotsJorim Jaggi2017-01-121-24/+8
| | | | | | | | | | | | | | | | | | | | | | All this functionality is hidden behind a flag. If this flag is active, we disable the regular screenshots. Instead, we take a screenshot when an app transition for which a task is disappearing is starting. The screenshot gets stored into a gralloc buffer. SystemUI uses a new method to retrieve a snapshot gralloc buffer and then draws it using GraphicBuffer. createHardwareBitmap(). When starting an existing activity in an existing tasks, or when bringing an existing tasks to front from recents, we add a new snapshot starting window. For that, we reuse the existing starting window, but when creating the window, we use a fake window that draws the contents of the starting window. Test: runtest frameworks-services -c com.android.server.wm.TaskSnapshotControllerTest Bug: 31339431 Change-Id: If72df07b3e56f30413db5029d0887b8c9665aaf4
* Clean up starting window to prepare for saved surfacesJorim Jaggi2017-01-101-9/+18
| | | | | | | | | | | | - Move all starting window logic to AppWindowContainerController - Use startingView to hold any kind of contents for startingWindow - Remove some conflicting code which looks very old and doesn't apply anymore. Test: Make sure starting window still works. Bug: 31339431 Change-Id: I018dd013ab7e64a44932b6d54ae9bb4a47f315d3
* Light navigation bar support (1/2)Jorim Jaggi2016-12-081-0/+5
| | | | | | | | | Test: Open an app that has this flag set. Test: android.systemui.cts.LightBarTests Bug: 29058491 Change-Id: Idaff65fdd5c59b68ae9920726c9ea50b53f96675
* Revert "Allow power button to close an input method" am: 28f0e5bf48Mark Renouf2016-12-071-10/+0
|\ | | | | | | | | | | am: fc526f6e84 Change-Id: Ifcf2f842c91677128e458dd7256013263543937f
| * Revert "Allow power button to close an input method"Mark Renouf2016-12-061-10/+0
| | | | | | | | | | | | | | | | This reverts commit d28e907183fe48afc1ea0cb4f939b738cbcc2506. Test: manually tested BUG: 33038203 Change-Id: I7a4c6e95a69abb2e40df73509b6e67b93eacf6ff
* | Allow power button to close an input method am: d28e907183 am: 8da4ced46cMark Renouf2016-12-011-0/+10
|\| | | | | | | | | | | am: 9a21708ec6 Change-Id: I63d939d4dbd889cbd6f83ef101d817ccd561d707
| * Allow power button to close an input methodMark Renouf2016-11-301-0/+10
| | | | | | | | | | BUG: 33038203 Change-Id: I5c44dc49db6b960b4e3e42545bfbbab62f357f08
* | Add explicit method to dismiss KeyguardJorim Jaggi2016-11-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The flag is a bit clunky for most cases, and a method is more clear. Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts.KeyguardTests Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts.KeyguardLockedTests Test: runtest systemui -c com.android.systemui.keyguard.DismissCallbackRegistryTest Bug: 30961403 Bug: 27422134 Change-Id: I39de90c7cfecd99350a74f72cd76418e337f2b79
* | Don't include sysUI insets on secondary displaysAndrii Kulian2016-11-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there is a single instance of WindowManagerPolicy used in Window Manager and it is configured according to primary display settings. Because of that it reports display size with navigation bar insets even for secondary displays. This CL adds displayId param, so it can adjust reported metrics correctly when requested. Bug: 32910901 Test: android.display.cts.DisplayTest Change-Id: I14967fc13907c4fde17aed6a769d03cbde3ec1be
* | The big Keyguard transition refactor (8/n)Jorim Jaggi2016-11-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Don't force mKeyguardGoingAway, as this never recovers. Make sure to only show the dismissing Keyguard activtiy and recover the state when trusted state changes. Test: Make sure Keyguard is in a trusted state, start an activity with FLAG_DISMISS_KEYGUARD from FLAG_SHOW_WHEN_LOCKED activity and make sure there is no flicker. Bug: 32057734 Change-Id: I5d212f6f9d5430250b22c8370f45dc95756432d2
* | Get rid of Keyguard visibility modifiers on WindowStateJorim Jaggi2016-11-031-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Not needed anymore \o/. Also fixes a flicker when transitioning between two activities that both set FLAG_LIGHT_STATUS that was somehow introduced recently. Test: - Start an light status bar activity from another activity that already has light status bar, ensure there is no flicker. - Open IME and make sure the content gets resized like before. Change-Id: Ie9c9e1cd40f909c449d36ae436250063af20539e
* | The big keyguard transition refactor (3/n)Jorim Jaggi2016-11-011-0/+7
| | | | | | | | | | | | | | | | | | | | | | Notify activity manager when dreaming showing state changed so KeyguardController can update the occluded state when the device is dreaming. Test: Set dreaming while charging, wait until screen times out, make sure that dream is occluding Keyguard. Bug: 32057734 Change-Id: Ied6f485d9b4a1526cb4cd5f0701f86b1ea05830a
* | The big keyguard transition refactor (1/n)Jorim Jaggi2016-11-011-42/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The heart of this change are two things: 1) Instead of using the force hide mechanism to hide windows behind Keyguard, we actually make the activities invisible in activity manager. 2) When Keyguard is going away, we change the visibilities in activity manager and run an app transition. At the very core we move the responsibility of hiding activities to ActivityStack, which checks whether Keyguard is showing, and then hides all non-show-when-locked activities. For that, we need to check whether any window of an activity has SHOW_WHEN_LOCKED set. We introduce a callback from WM -> AM in case these Keyguard flags have changed. Furthermore, we decide whether to occlude Keyguard in KeyguardController, which just checks whether the top activity has SHOW_WHEN_LOCKED set. When this state changes, we prepare an occlude/unocclude app transition, and in PWM we just inform the Keyguard about the animation so SysUI can play along this animations in a mostly synchronized manner. Since we now use an app transition when unlocking the phone, we get lockscreen launch animations for free - window manager automatically waits until the activity is drawn, or directly executes the transition if there is nothing to animate. Thus, we can remove all the infrastructure around "waitingForActivityDrawn". The logic to show/hide non-app windows is moved to policy, and we add the ability to run animations on non-app windows when executing an app transition. Test: 1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests 2) Manually test unlocking Keyguard: 2a) Without security 2b) With security 2c) With security but trusted 2d) Portrait while activity behind is in landscape 3) Test launching things from Keyguard 3a) Without security 3b) With security 3c) Launch camera without security 3d) Launch camera with security 3e) Launch camera with securtiy and trusted 3f) Launch voice affordance 4) Set no notifications on lockscreen, drag down, make sure you get the correct animation 5) Test clicking "emergency" on bouncer 5b) Test "Emergency info" on emergency dialer 5c) Test clicking edit button on emergency info, should show pattern on Keyguard Bug: 32057734 Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
* | Merge "Adding PIP input consumer."Winson Chung2016-10-141-1/+1
|\ \
| * | Adding PIP input consumer.Winson2016-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | - This CL provides the framework for manipulating the pinned stack using an input policy (to be determined later) provided by the SystemUI. Test: android.server.cts.ActivityManagerPinnedStackTests Test: #testNonTappablePipActivity Change-Id: I025c41fff26ed05a35d68e59f10330680ed11ea8
* | | Fix import statement in view|transition|animation packages.Aurimas Liutikas2016-10-121-1/+1
|/ / | | | | | | | | | | | | This change also remove trailing whitespace. Test: code still compiles Change-Id: I7eff4546320d67d2bae58d31bad0625ea0791b8f
* | Removing private system ui flags from status bar flags logic. am: ab216609f1 ↵Winson2016-09-211-0/+10
|\| | | | | | | | | | | | | | | am: b7a673ed95 am: dccfd4394e Change-Id: Ie8bbbfb5c24957f64036e8de23d6a29e6669ea18
| * Removing private system ui flags from status bar flags logic.Winson2016-09-191-0/+10
| | | | | | | | | | | | | | | | | | - Prevent third party apps from inadvertently changing internal SystemUI flags through a call to setSystemUiVisibility(). These flags are only set in the individual SystemUI components and can be updated in WMS directly. Bug: 29875297 Change-Id: I5ea238c8fb16a0eccd6e993d95a912acb359cee6
* | resolve merge conflicts of c5bafe2 to masterJorim Jaggi2016-08-311-0/+5
|\| | | | | | | Change-Id: I19dd5c88c664313c2f8b47d8f8fd556f630c8bf1
| * Add animation when unoccluding windows (1/2)Jorim Jaggi2016-08-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before there was a jump-cut when a window that was occluding Keyguard was going away, leading to an ugly flicker. To fix this, we do the following. - Always show windows with FLAG_SHOW_WHEN_LOCKED above lockscreen, even if they don't "match" the currently occluding app (which is null in the animation case) - Move wallpaper behind last window that is not hidden by policy, so the window doesn't get occluded by the wallpaper. - Add a flag in the setOccluded call whether to animate or not. SystemUI then plays a nice animation when it's set. - Override the animation to always be the animation that happens when we exit a window which is revealing the wallpaper behind, to make it consistent with the home screen case. Fixes: 30829255 Change-Id: Ib3fe20fc9003a0f9f291c974740f044ed8707e75
* | resolve merge conflicts of f95418e to masterColin Cross2016-08-131-0/+1
|\| | | | | | | Change-Id: If2b4d34b3ba64f61214b72fd71f8767500e68a53
| * Add restart to GlobalActions.Alison Cichowlas2016-08-121-0/+1
| | | | | | | | | | | | | | | | Update power icon in GlobalActions for consistency with new restart icon. Bug: 30395806 Change-Id: I5ab20c15c889384fb685fc678fbf9ed912fcde5d
* | Add support for custom user-switch UIEvan Rosky2016-08-081-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | Given config_customUserSwitchUi, AM/UserController will not show any UI during user-switch (no dialog or screen-freeze). Provides a mechanism (WM.setSwitchingUser) by which a custom user-switch UI can notify WM/Keyguard when it expects a user-switch operation to be running. Bug: 29329555 Change-Id: Ic903fc251d7ec3a54bc6a77906d3afa45a6a5fac
* | Keyguard: Refactoring for improving trusted unlock while occluded am: ↵Adrian Roos2016-08-051-0/+6
|\| | | | | | | | | | | | | | | d88eb2693b am: cb5642afae am: bfe5166ac3 Change-Id: I760b5f4d780231b06ec8ef733a8a002c3dd2420d
| * Keyguard: Refactoring for improving trusted unlock while occludedAdrian Roos2016-08-051-0/+6
| | | | | | | | | | | | | | | | | | - Adds a trusted signal from Keyguard to PhoneWindowManager - Allows PhoneWindowManager to exempt DISMISS_KEYGUARD windows from force hiding - Allows PhoneWindowManager to dismiss Keyguard while occluded Bug: 27410215 Change-Id: I3ad490b64a5805b6f3888a9f37fcfbdd0116395e
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-22 08:58:23 +0000