b597ba3ab8d229011382bd05fe28bbe7bef853e4 |
|
23-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix window affecting SysUi visibility for once and all 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 (cherry picked from commit 23cc9aa50a1afb4ab4834b04c5c051b5b55747a0)
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ff4cc4ebb516a39c6f3252a240a57646c3354484 |
|
19-May-2017 |
Keun-young Park <keunyoung@google.com> |
Merge "Wait for keyguard draw before stopping boot animation" into oc-dev
|
4136d2d54b986a09b237aee30974d3c00d308338 |
|
08-May-2017 |
Keun-young Park <keunyoung@google.com> |
Wait for keyguard draw before stopping boot animation - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
51304d7380b6122ac55645fd9085ba071b04afa9 |
|
17-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Take snapshot when screen is turning off 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d6475a682d9651a651f60856baef9b17b4633b13 |
|
17-Apr-2017 |
Yohei Yukawa <yukawa@google.com> |
A new power button mode to hide the IME when shown 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ac52f2892d5c72c26387d510093ddfc741a8a632 |
|
30-Mar-2017 |
Winson Chung <winsonc@google.com> |
Ensure we show the PiP menu in response to KEYCODE_WINDOW. Bug: 36687605 Test: android.server.cts.ActivityManagerPinnedStackTests Test: #testWindowButtonEntersPip Change-Id: I0bb35fd666eb6a438e4676267f6726b44bffb3db
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d993a573d7fcf1a69d35528cae4dd96581c9aacd |
|
05-Feb-2017 |
Wale Ogunwale <ogunwale@google.com> |
Set oom adj for processes displaying app-overlays to PERCEPTIBLE_APP_ADJ 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
5cd907d3d6ceebf8731ef1f69347cce6f76109e9 |
|
26-Jan-2017 |
Wale Ogunwale <ogunwale@google.com> |
Alert Windows behavioral changes - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
fb1bf69d5d7fc8c45e3ddbb8916e21ae57432ff1 |
|
17-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Set permissions for launching on private displays - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
02886a82d876aa5e31a92444fec70208599c509c |
|
06-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Initial implementation of snapshots 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ba41f4b9e3629c097cdd7b6538c5bcf4602728b8 |
|
15-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Clean up starting window to prepare for saved surfaces - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
40db029cfeb263b5b672ca687c347e58ed2ad2ae |
|
28-Jun-2016 |
Jorim Jaggi <jjaggi@google.com> |
Light navigation bar support (1/2) Test: Open an app that has this flag set. Test: android.systemui.cts.LightBarTests Bug: 29058491 Change-Id: Idaff65fdd5c59b68ae9920726c9ea50b53f96675
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
cb566f368bc3b83640f3f75f64c1e29641e362df |
|
07-Dec-2016 |
Mark Renouf <mrenouf@google.com> |
Revert "Allow power button to close an input method" am: 28f0e5bf48 am: fc526f6e84 Change-Id: Ifcf2f842c91677128e458dd7256013263543937f
|
28f0e5bf48e2d02e1f063670e435b1232f07ba03 |
|
02-Dec-2016 |
Mark Renouf <mrenouf@google.com> |
Revert "Allow power button to close an input method" This reverts commit d28e907183fe48afc1ea0cb4f939b738cbcc2506. Test: manually tested BUG: 33038203 Change-Id: I7a4c6e95a69abb2e40df73509b6e67b93eacf6ff
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
cf952e74b0079f3ff0b8cf5351bbf1bebfb06617 |
|
01-Dec-2016 |
Mark Renouf <mrenouf@google.com> |
Allow power button to close an input method am: d28e907183 am: 8da4ced46c am: 9a21708ec6 Change-Id: I63d939d4dbd889cbd6f83ef101d817ccd561d707
|
d28e907183fe48afc1ea0cb4f939b738cbcc2506 |
|
29-Nov-2016 |
Mark Renouf <mrenouf@google.com> |
Allow power button to close an input method BUG: 33038203 Change-Id: I5c44dc49db6b960b4e3e42545bfbbab62f357f08
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
241ae10b2189f449e57d8d660235ac56d8fb1b80 |
|
03-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add explicit method to dismiss Keyguard 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
db8e106fa35ca75f4a8bf9795edc7676fbf8e003 |
|
16-Nov-2016 |
Andrii Kulian <akulian@google.com> |
Don't include sysUI insets on secondary displays 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e69c93181f1f313dcedd07f677af1cea953fdf16 |
|
01-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big Keyguard transition refactor (8/n) 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
b0d273427b3edf074a2c927b4f7e5d53fca2168a |
|
02-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Get rid of Keyguard visibility modifiers on WindowState 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
77e104322920cb93c0ac3d5f101115826728d3d1 |
|
27-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (3/n) 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
fe762344f4475a3a336bb46aef2d59c1fabf32ab |
|
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (1/n) 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
011c85729ae5799b85c694b831ad6a8e632878cd |
|
15-Oct-2016 |
Winson Chung <winsonc@google.com> |
Merge "Adding PIP input consumer."
|
412754816d2b8e83f0f5f860b13f09f53d2da05f |
|
11-Oct-2016 |
Winson <winsonc@google.com> |
Adding PIP input consumer. - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
67e2ae86396c6d0f989285275cbf908dee5e71f7 |
|
12-Oct-2016 |
Aurimas Liutikas <aurimas@google.com> |
Fix import statement in view|transition|animation packages. This change also remove trailing whitespace. Test: code still compiles Change-Id: I7eff4546320d67d2bae58d31bad0625ea0791b8f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
329011cf402666678c47cd238a5170208a5bbc27 |
|
21-Sep-2016 |
Winson <winsonc@google.com> |
Removing private system ui flags from status bar flags logic. am: ab216609f1 am: b7a673ed95 am: dccfd4394e Change-Id: Ie8bbbfb5c24957f64036e8de23d6a29e6669ea18
|
ab216609f1608e61827d955fcc9fd0560bc52e4d |
|
09-Aug-2016 |
Winson <winsonc@google.com> |
Removing private system ui flags from status bar flags logic. - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
32cbdcc8c098b4a42212b3da345b929abad8ad6e |
|
31-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
resolve merge conflicts of c5bafe2 to master Change-Id: I19dd5c88c664313c2f8b47d8f8fd556f630c8bf1
|
6626f54e658e3da44fab8a5cd6d9d3d4852e2cd1 |
|
22-Aug-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add animation when unoccluding windows (1/2) 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2c5439972f308995f14c3744db12248f1a9a48fc |
|
13-Aug-2016 |
Colin Cross <ccross@android.com> |
resolve merge conflicts of f95418e to master Change-Id: If2b4d34b3ba64f61214b72fd71f8767500e68a53
|
f8eca405c1140691cb7cb8ab8f3dc05e05cb7955 |
|
05-Aug-2016 |
Alison Cichowlas <asc@google.com> |
Add restart to GlobalActions. Update power icon in GlobalActions for consistency with new restart icon. Bug: 30395806 Change-Id: I5ab20c15c889384fb685fc678fbf9ed912fcde5d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
1839645126c8e7e0909e8ed8f0686c2122ba6078 |
|
28-Jul-2016 |
Evan Rosky <erosky@google.com> |
Add support for custom user-switch UI 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
92c9c4f3e6932958f5728705cb7ce1c255aa4a43 |
|
05-Aug-2016 |
Adrian Roos <roosa@google.com> |
Keyguard: Refactoring for improving trusted unlock while occluded am: d88eb2693b am: cb5642afae am: bfe5166ac3 Change-Id: I760b5f4d780231b06ec8ef733a8a002c3dd2420d
|
d88eb2693b6a70af0f5fbc5881ce855e28de33aa |
|
04-Aug-2016 |
Adrian Roos <roosa@google.com> |
Keyguard: Refactoring for improving trusted unlock while occluded - 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
8942204d935c5417154a8dd3cb90db3f47193d63 |
|
01-Jul-2016 |
Robert Carr <racarr@google.com> |
Merge changes I38cff63b,Id3739bbc,If052cd8c into nyc-mr1-dev am: 30efa24b11 am: 0dbe6db014 Change-Id: I3f0fd113bf9dc063f3bc60301f9a7ddf7d16581d
|
fd10cd1989966d01011a0cf75f3282f3e12ca5a6 |
|
30-Jun-2016 |
Robert Carr <racarr@google.com> |
Force CROSSFADE rotation when launching from double tap gesture. When activity transition triggers a rotation change, the starting window will normally be the top window at the time we try to select the window animation. However, these layout params won't have the apps rotation animation set (as the client code will set that on the real window, not the starting window). Eventually we would like to add API to specify rotation animation via manifest to solve this problem cleanly. In the mean time, we can force a specific rotation animation from the double tap gesture, and clean up some camera ugliness. We accomplish this by attaching an animation hint to ActivityOptions. Bug: 28838855 Change-Id: If052cd8cbae76651da43f3b4c590cd9dcc1afc0f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0db4052d51fb48b6a19a72f75b49103054ff4219 |
|
22-Jun-2016 |
Robert Carr <racarr@google.com> |
resolve merge conflicts of 79116da to master Change-Id: Ia6e42d99097da86e23b9d33659259d264a365c45
|
6da3cc0237d2483ead16a7013d1326bccc5112af |
|
17-Jun-2016 |
Robert Carr <racarr@google.com> |
Implement seamless rotation mode. Add a rotation mode which does not require freezing the screen. For situations like Camera where only small elements move on screen, this allows for seamless changes of display orientation. This is achieved by transforming the windows with their current buffer in the same transaction that we rotate the display. We set things up so the windows are frozen this way until they submit buffers in the new orientation. There is a special case in the Camera window itself, and it's use of NATIVE_WINDOW_TRANSFORM_INVERSE_DISPLAY. In this case the buffer contents are rotated by SurfaceFlinger and will never resize, for these windows we just need to update the scaling matrix. Bug: 28823590 Change-Id: I52dc6a86fcb3c08f736f0977ba3975a24fb8136c
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3a14fb79163d0e1d8c9882d720a10c6a0ecd419e |
|
17-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Handle multi-window for inset hint am: 23bf5462f0 am: b7bd18bdc6 am: bf9a7566df * commit 'bf9a7566df02f7754ffeeba523cc904f73c0a45c': Handle multi-window for inset hint Change-Id: I033c6ad295bf235d181ad0fbfe5025cdcad5b4c2
|
23bf5462f05b33ce4390d8370520e43b74dbec09 |
|
14-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Handle multi-window for inset hint We need to incorporate task bounds when calculating the inset hint so we don't specify something wrong to the client which we correct immediately after. Bug: 28697105 Change-Id: I23cec7d6cc62a4d982e0796a867e803d4cce0803
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
10b889de7d0c9271e3fb47c87a8ed140bee9c271 |
|
12-May-2016 |
The Android Automerger <android-build-merger@google.com> |
stephenli Manually merge commit '68fffa5' * commit '68fffa5': (23 commits) Fix smallest width configuration calculation docs: DoDS, wearable reference docs Switch the default text selection handles to Material style. docs: Noted minor API changes in release notes docs: added "billions" doc in Distribute>Essentials Remove wear design pages redirecting to design/wear correct the support library redirects to redirect whole path Stop saving ActionMenuItemView state. Fix iterator double-advance in ContentObserverController TIF: Remove the uniqueness check for track ID from notifyTracksChanged Update and add attributes to the JavaDoc for VectorDrawable Use Q=100 JPEG instead of PNG for wallpaper display Fix issue #28400000: Settings memory UI still showing z-ram... docs: Updated support library revision history for 23.4.0 docs: Updates to notifications for DP3 docs: Added emoji section to api overview. Fixed a bug where the QS was animating wrong when closing Fix KeyguardManager.isSecure() to observe work profile cherrypick from mnc-docs docs: Updated APK Signature Scheme v2 doc. Docs: Added new Whitelist feature to Data Saver for DP3 ...
|
e4044bb617ea849939058d953e250fcd540c75cc |
|
11-May-2016 |
Jim Miller <jaggies@google.com> |
Fix KeyguardManager.isSecure() to observe work profile The fix passes the calling userId instead of the current userId to allow apps running as managed profiles to work. Fixes bug 28666104 Change-Id: I9f8676ab11bd581d9e67b2b9f385036d4d3576ee
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2c0d6dcc8c5b66021642a036a3b31b393b707c79 |
|
29-Apr-2016 |
Tony Mak <tonymak@google.com> |
No keyguard should be shown after reboot if it is in kiosk mode 1. we disable keyguard before KeyguardServiceDelegate connect the KeyGuardService and the request is ignored. We now remember the request and redo it after connected 2. Instead of checking PRIVATE_FLAG_KEYGUARD flag, use isKeyguardShowingAndNotOccluded to check is keyguard showing. Bug: 28164604 Change-Id: Ib02b5fc9dcc6e8d9934309f1e540ece4d845363d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3eefb4c313d0269f7e8bd226bdcc2d039f9e5608 |
|
19-Apr-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Use right starting window resource in multi-window mode." into nyc-dev
|
dfc18623edfd35778c1f2c8efab12dfeff98ded7 |
|
17-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Use right starting window resource in multi-window mode. Use the override configuration for the task the app is contained in to generate resources for the starting window. Bug: 28220001 Change-Id: I6fdf39a6d6de41287b44b25861a76f58fe58dd53
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
681fc7b2670542aae0f3b9ef8f6c7a88db984ea9 |
|
15-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix wrong transition when dock minimized and docked app launched When having an app docked and then going home, and then launching the app from the homescreen, we had a wrong transition because getTopMost task was already set to the launched app, because getRunningTasks doesn't exclude the docked stack. Instead of adding flags for getRunningTasks, which sounds risky, we just pass a "force" value when we launch recents in this state. Bug: 27154882 Change-Id: Iee4512fed13115dbbe8b74413ff1fa9b87afa0ef
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
11c62e17af9096f76d4532f26cacd809c3a5ef53 |
|
06-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Dynamic density change handling - In PWM, make sure to read the height values after the new configuration has been applied. - Reset all navigation bar button icons when density changes. - Adjust height of notification bar. - Reload divider height values in SysUI and WM. - Snap divider handle to a new position after loading the new configuration, as the snap points change. Bug: 26844819 Bug: 27450471 Bug: 27921696 Change-Id: I9e28f0c49f6367c5fcfac010e7a6e98a42e85996
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
933076d80561751618f462b26309ce9e4c3ff3bf |
|
30-Mar-2016 |
Andrii Kulian <akulian@google.com> |
Refactor usages of Picture In Picture and Multi Window (1/4) Bug: 27365860 Change-Id: I1590e430a12ceb84cb83da295e0bf7e4378fea96
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
7400f82699c76618d5ca24d6528580afb4695dbf |
|
15-Mar-2016 |
Adrian Roos <roosa@google.com> |
Merge "Don't show wallpaper when backdrop is visible" into nyc-dev
|
d5c2db630fc816e2d9154a61ccbd6770bc57cff8 |
|
09-Mar-2016 |
Adrian Roos <roosa@google.com> |
Don't show wallpaper when backdrop is visible Hides the wallpaper when it's not needed and fixes the unlock animation to not unnecessairly show the wallpaper if neither the Keyguard nor the underlying app need it. Also fixes a bug where the enter animation had a background set, which led to uglyness when no wallpaper is involved. Bug: 27533740 Change-Id: I667c6f7ca6c0e1ff7e9f793c6ddc13f6da8387b1
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9185fb07c4df49fe604f9535505634f86aeac1c4 |
|
12-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Disable FLAG_LAYOUT_NO_LIMITS window flag in multi-window mode FLAG_LAYOUT_NO_LIMITS allows a window to extend its dimensions outside the screen area by setting the display frame to a really big value. We don't want this in multi-window mode since all window frames should be limited to their parent task/stack dimensions. Bug: 27577275 Change-Id: Ie0a8b8c13de91561e06dadc27aac3a5ba209d05b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
94ce94e96069ab6c2ece4864ba4c7692f3168352 |
|
25-Feb-2016 |
Muyuan Li <muyuanli@google.com> |
Allows components to register shortcut key. The registered shortcut will be called from PhoneWindowManager, before dispatching Change-Id: If26128939b45a639c8895719a7a23ca433f39fd9 (cherry picked from commit 4da863c5a8872dcabb179a978a2b2157d9081679)
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0ffd49cbe0ab4c13fd5528abacade898a8cff481 |
|
13-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Always consume bottom insets when navigation bar is force shown When an app requests SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION but we force show the navigation bar, we need to treat for the app like there is no virtual navigation bar on the device. Because if you combine it with FLAG_HIDE_NAVIGATION, you'd expect the navigation bar gets hidden but it doesn't, so there could be content that overlaps with the navigation bar. Bug: 27157904 Change-Id: I088e02eae2e723c35e9cb4873de6b1325458533b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
5060bd891068b78bcbe72e1d8b61efac2da02c20 |
|
20-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Restrict dock sides after rotation Bug: 27167078 Change-Id: If51626b75321eebc277eb2399ee753ffe489642b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
82c9dc951e8e19b9eab6120b6465e08c5d69beba |
|
06-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix configuration calculation when task is non-fullscreen Apparently only the navigation bar is excluded when calculating Configuration.screenLayout. Make the calculation for non-fullscreen tasks consistent with fullscreen tasks. Change-Id: I027e41e49ffe95245116f3d134e0bc93af0ee450
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
86905582411c5c77a3e7641589cf206c6e5770f5 |
|
10-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Handle light status bar for split-screen In split-screen the light status bar flag for one side of the status bar can be different from the other side. SYSTEM_UI_FLAG_LIGHT_STATUS_BAR is now reported for both the fullscreen stack and docked stack, but not anymore in the "default" SysUI visibility field when reporting a visibility change to SystemUI. The change also reports the docked stack and the fullscreen stack bounds, so SystemUI can guard tinting the icons on whether the icon is one of the areas. When calculating the light status bar flag in PWM, we keep track of the top fullscreen opaque window state for the docked and fullscreen stack separately. Bug: 24365214 Change-Id: Id2240a86d75bf96e0138ec7652a4793859f56e3c
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
81ba11eccbc2519338782100c13cf4a5909ad6be |
|
04-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Put dismiss end target at navigation bar This makes the animation when exiting docked mode a bit nicer when you fling the divider towards to the navigation bar. However, since the divider ends at the navigation bar, we need to immediately dismiss it instead of fading out when the divider is fully occluded by the navigation bar. Change-Id: Ic5432fd118cb71be36485667b2c537caf5065ce5
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d5f7ed9fe9dc3590f6ef9cb7470e29e836a95907 |
|
19-Jan-2016 |
Michael Wright <michaelwr@google.com> |
Switch and store keyboard layouts based on IME subtype. Rather than associate the keyboard layout solely with a specific hardware model, we should also associate it with a given IME subtype. This lets users switch between various languages and have the keyboard change in unison with them so they can use the appropriate layouts for each language. This change adds initial support for associating IME subtypes and keyboard layouts. We still need to: - Remove support for the old style of layout association once the Settings apps begins to use the new APIs - Automatically select an appropriate layout based on the given subtype (or set a reasonable universal default such as QWERTY) Bug: 25752812 Change-Id: Ie88ce1ab77dbfe03ab51d89c1dc9e0a7ddbb3216
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3e8747414520ee348cf4b9c4a6afd9ff80b5a8f8 |
|
07-Jan-2016 |
Winson <winsonc@google.com> |
Improving drag and drop animations. - Expanding drop targets to indicate the size of the to-be docked window - Fixing animation when dropping task - Fixing drag view z order - Fixes issue where the dock divider position in WM is not exact - Requiring user to move the slop distance before accepting drops Change-Id: I2f6eab504db7126c19e0c680629e89a39e7512e3
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
737af724eb31f513386e91ee5510cc6991350937 |
|
31-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Snap docked stack after screen rotation - Move DividerSnapAlgorithm to com.android.internal, also move some utility stuff into DividerUtils which is used from both SystemUI and window manager - When the screen rotation changes, rotate the stacks like before but then also snap the docked stack to a valid snap position. Change-Id: I9e1aa13f42f398a25c9016e6f20395ee212e405b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3dc52ed1799f96deaf802a5304f7301463dec58f |
|
11-Jan-2016 |
Winson Chung <winsonc@google.com> |
Revert "Snap docked stack after screen rotation" This reverts commit e65d6bb2072471e63b93aa14a288bc59ed86208f. Change-Id: I245aa9be3ea98ff742e02b02f6f1d344bc2e8182
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e65d6bb2072471e63b93aa14a288bc59ed86208f |
|
31-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Snap docked stack after screen rotation - Move DividerSnapAlgorithm to com.android.internal, also move some utility stuff into DividerUtils which is used from both SystemUI and window manager - When the screen rotation changes, rotate the stacks like before but then also snap the docked stack to a valid snap position. Change-Id: Ifb0c65dfbdfca2343a76b12de982c0701fe0c3ab
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9ebbe6afe7a433f78ca3d30c9f215c53212c34ac |
|
17-Nov-2015 |
Sriram Viswanathan <tvsriram@google.com> |
Changes to support navigation bar system UI in car mode. The change has all the platform changes required to support modifications in the navbar dimensions and custom icons in car mode. The UX is not frozen yet, but have placeholder resources provided by android auto UX engineers. The change assumes that the car mode configuration is known to the WindowManagerService and uses its current ui mode to request the latest from the policy (PhoneWindowManager.java). The change is modeled on the way rotation is handled, where the Policy knows the different view attributes for uiMode and just returns back the window sizes based on the current uiMode requested. The policy does know the current uiMode, but the order of when that changes is not deterministic [from logs it does happen before any request to update UI occurs, but guess that could change]. Bug: 25996809 Change-Id: Ia46cbe5096382d26c9eb8ec74cf59a059b767edb
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ae61f7118a92e097e854c840d5726c0920f5db0e |
|
09-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Rotate IMEs (subtypes) by Meta+Space. With this CL, PhoneWindowManager starts monitoring Meta+Space to trigger input method rotation. Note that InputMethodManagerService currently supports only one way rotation. Currently there is no difference in the behavior between Meta+Space and Shift+Meta+Space. Reverse rotation will be supported in a subsequent CL. Bug: 25753404 Change-Id: I4005692215edfcf8bed3e86b1e07000148f986f5
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4407cbde63db301dc6383bc47b6dc95fa55fffaa |
|
08-Dec-2015 |
Michael Wright <michaelwr@google.com> |
Merge "Add support for locking the screen when the lid is closed" am: 9dc3c36c9c am: 4d9e6190b1 am: 37c8bcbcc9 * commit '37c8bcbcc9f5098a2a7fde91a3b112abd35a85ad': Add support for locking the screen when the lid is closed
|
7def60daa049271c0d595d2ff566965693ee88cd |
|
13-Nov-2015 |
Edward Savage-Jones <edward.savage-jones@sonymobile.com> |
Add support for locking the screen when the lid is closed This commit adds configurable support for lockscreen behaviour when the user has a device cover/lid. This is intended for lids with a viewing window so that the user can see the time and interact with apps via the window. Change-Id: Id71883f66d1a180c4732912b3b59cabf9f4d7b6e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
14b4e57c1ba427f07186dbff8491242162028c71 |
|
04-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove blink during the freeform -> recents transition. We achieve the desired result by prolonging the last frame of the animation until recents tells that it drew its content. The CL also includes cleanup that moves code that depends heavily on WindowState fields into that class. Bug: 24913782 Change-Id: I5ee5b18504dd4a86c24033d17eca21cd31936bca
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2a6a2c2de8ce2743679f488f056f22cd1adfd726 |
|
14-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Change WindowState.mShownFrame to WindowState.mShownPosition. We never use this field as a rectangle, we only depend on its left-top corner. Using a frame is only confusing about the purpose of this field. Change-Id: I5d6e6321db4fa3203bb7e0f1975ae6ddd1ec09bb
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0d210f6395072db4a4c53d4cb8fac4a59a3965b4 |
|
10-Jul-2015 |
Jorim Jaggi <jjaggi@google.com> |
Animation for touch, wake and unlock - Add callback to inform SysUI when the screen has been unblocked and turned on. - Cleanup inconsistent messaging about device interactive/screen on and off. - Add callbacks to inform SysUI about screen states - Implement a quick fade for the scrim after touch, wake, and unlock. First, start with a black scrim on top of everything, and then fade it out. - Make sure we play the normal unlock animation when device is pulsing - Override navigation bar animations for touch, wake and unlock: Fade in the same manner as the scrim. Bug: 22571198 Bug: 21855614 Change-Id: I8ff08d72cced1e0f03c78d71ff710d8a4f6b848c
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
76d2fe42880bd37b80c01fb68c31a4c619ddfdeb |
|
09-Jul-2015 |
Adrian Roos <roosa@google.com> |
Fix black keyguard / missing status bar The status bar window was stuck in the READY_TO_SHOW state because it was not policy visible, whereas the policy was waiting for the window to become HAS_DRAWN. Now BarController also updates states if the window is READY_TO_SHOW, which in turn allows the window to become visible and HAS_DRAWN. Bug: 22072099 Change-Id: I1836c276723ee2205d7d5759be079f02aaa23e2e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d40c423b1cdccd61ed411b0b9e3fbefd47e99f9c |
|
01-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "resolved conflicts for merge of 300ccf4a to mnc-dev" into mnc-dev
|
d1a092218b4b40cfd53a643e0ae01095815f4b30 |
|
01-Jul-2015 |
Yohei Yukawa <yukawa@google.com> |
Reland "Fixed constant window switching on lock screen..." This is a manual reland of I3680256d41793f62def42fda00e26db1dcc9, which was certainly merged into lmp-mr1-dev then auto-merged into master but silently lost there for unknown reasons when I8c42a1e6091b0fe1253e90265ac248087e was auto-merged into master. Changes in WindowAnimator.java was already covered by I2933eaf0ab55fe31cb382c46c411033e33a756e0 so this CL does not include that change. Bug: 18021493 Bug: 22158649 Change-Id: Ib1bf9f5bef44d0400230afc32231f7d1f3a1c98b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2987f616faca534a792686a53304c9932634310c |
|
01-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
resolved conflicts for merge of 300ccf4a to mnc-dev Change-Id: Ia315e314bfde0c066a2c25d93f8cbdc71fee0a14
|
0ec1328f85a08a610868856c688ebb8196c79c17 |
|
25-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Calculate outset hint when adding window. Outsets aren't dynamic so they are a great candidate for a hint when the window is added through the window manager. Thanks to this during first view hierarchy measure or wallpaper window layout they are immediately available and don't require multiple measure/layout passes. Bug: 21593814 Change-Id: I573c15ffbbe4fcd8a6ed9c5e4fcd6cfbbcd7434f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
461829d607b32ee492b6123043ae4232ed82ae93 |
|
03-Jun-2015 |
Adrian Roos <roosa@google.com> |
Prevent windows below the keyguard from showing Fixes a bug where windows below the lock screen could become visible if a SHOW_WHEN_LOCKED activity hides the status bar. Bug: 21450145 Change-Id: Ie660394cb96d7e6839bd4fb7c2729133bac2dfc5
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
99bcc3eee23ed8bd15bd108d068d6f9f694e4393 |
|
01-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Revert "Revert "resolved conflicts for merge of 47249f2a to mnc-dev""" into mnc-dev
|
cb81d183672a3d9858ade10a997990c5d66a1be3 |
|
30-May-2015 |
Jeff Brown <jeffbrown@google.com> |
Merge "Tell PhoneWindowManager when we start/finish interactive changes." into mnc-dev
|
416c49c4049f572134273e228d7988904a51b990 |
|
27-May-2015 |
Jeff Brown <jeffbrown@google.com> |
Tell PhoneWindowManager when we start/finish interactive changes. Added some new callbacks that can be used to more precisely trigger certain behaviors that need to happen around the time the device is put to sleep and locked. Fixed an issue where the going to sleep signal might be sent too early on devices that don't support ambient mode due to the extra wakefulness change between DOZING and ASLEEP. We are now track the early / late interactive change work separately from the rest. Bug: 21375811 Change-Id: I95387195e216ae92a6e45485bd1bd362e41aa45a
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2217f61e51ba4b19c56b19297c1e9cf74d7d860f |
|
26-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Revert "resolved conflicts for merge of 47249f2a to mnc-dev"" This includes the fix for the broken dialog windows. The outsets will only be calculated and applied if the window is full screen, since they don't make much sense otherwise. This reverts commit 4bb6b751fbbb218e8a298db4aa008472a0aa8d31. Change-Id: I977a85a78c990c1840784dc0be0dddd5a6d84e6b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d6623618b28906d058ac61623e11853ebe9ad1de |
|
23-May-2015 |
Selim Cinek <cinek@google.com> |
Fixed logspam and handling subwindows with the input consumer Bug: 21402648 Change-Id: I4c1c73487dfd19ba452ff2077d8541547f149c3b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4bb6b751fbbb218e8a298db4aa008472a0aa8d31 |
|
23-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Revert "resolved conflicts for merge of 47249f2a to mnc-dev" This reverts commit c7becb7ee78881646251ff4846e63eb6b96bf7ec, reversing changes made to 8562b08f04c1309cf40db1e749d612b6824f1d12.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c7becb7ee78881646251ff4846e63eb6b96bf7ec |
|
21-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
resolved conflicts for merge of 47249f2a to mnc-dev This is a merge of chin support. Change-Id: I436b751b3c4aaa6b46cfcdb475e02eedfa5a5635
|
f83e824216435e45f36a3587e269888f791b2a01 |
|
20-May-2015 |
Selim Cinek <cinek@google.com> |
Fixed that touches where incorrectly consumed when fullscreen The fake window that was added when View.SYSTEM_UI_FULL_SCREEN was set consumed all touches, even those going to the SystemUI and not just those of windows below. The input consumer is now correctly positioned in the window order to only capture the right touches. Clicks to the volume panel and the heads up now correctly go to the right place instead of just unhiding the SystemUI bars. Bug: 21089476 Change-Id: Ib53dfc0b33b70084ca607d0f044db30b6e6c91d6
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3e11bf33a6094da92d97702213aa12c67b21c4d1 |
|
20-Apr-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Support for devices with a chin. Information about the chin is now part of the config.xml instead of the theme. It is retrieved by WindowManagerService and passed to the clients as insets. Clients can adjust their behavior in a way that makes it invisible to the user, that part of the surface doesn't actually exist. Bug: 19908853 Change-Id: Iedf57bf3c848201b854f91ffeb3b59187d375c1f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
cd3884dfb246855c059e15db376f0935af68d949 |
|
18-Feb-2015 |
Adrian Roos <roosa@google.com> |
Set the light status flag based on right window The flag needs to be set based on the top window that is either reaching beneath the status bar or is dimming. Bug: 19233606 Change-Id: I7b97f6869e3b7d5ae2b7030122b311ee9e13871f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f5a3fee9d6d116754be4ce8746465c202a07c499 |
|
07-Feb-2015 |
Bryce Lee <brycelee@google.com> |
am 1d97aa4d: Merge "Allow single press of physical button to go home without sleeping." into lmp-mr1-modular-dev automerge: d1444b6 * commit 'd1444b63a173ce21f8588e09fd17f3cc83528c24': Allow single press of physical button to go home without sleeping.
|
01b0c5f55b57f97389ab4e85da5310da7145c6ce |
|
06-Feb-2015 |
Bryce Lee <brycelee@google.com> |
Allow single press of physical button to go home without sleeping. Bug: 18921423 Change-Id: Ic7ee7daeaf1b4e08a7c53451615736ee7a08fb61
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
165be0c70d128f0ece876d54e1c7e95ef04c6960 |
|
28-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Remove TYPE_UNIVERSE_BACKGROUND from system An experiment that is over and has been occupying space. Fixes bug 18088522 item #7 Change-Id: Ib0fcaa24243ed9b0581143e1d5114c1fd2b0aa6e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
37d7a68de7e353c31a3a4736054cd86f0e002eaf |
|
06-Nov-2014 |
Adrian Roos <roosa@google.com> |
Fix inset hinting when adding window Windows with FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS were getting an incorrect content inset hint, because the hinting didn't see the adjusted systemUiVisibility. Also adds hinting for the stable insets. Bug: 17508238 Change-Id: If9647277feb6811b15665b801accd896c51dbd12
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3ee549ca2404067bb8b2fcbaa741ec118c76bf3e |
|
23-Sep-2014 |
Jeff Brown <jeffbrown@google.com> |
Fix window manager policy state when waking from doze. Once upon a time when the world was fresh and new, the heavens had an easy rhythm. Day and night. Night and day. In the day, the pixel fairies would cavort and play in the bright gardens with narry a mark of shadow or gloom. In the night, they would rest peacefully, dreaming no dreams and knowing no fear. Then one night a fairy dreamed the first dream. At first the dream was peaceful, full of colors and delight, hopes and memories. Then all at once, jarringly, it awoke in bright daylight. The pixel fairy knew fear, for the world had changed and it was unprepared. Time passed and the pixel fairies grew accustomed to their fate, day and night, night and day, sometimes dreaming, until there came a night when a fairy did not sleep. It roamed the land in a dreamless doze, lost and afraid amid a grim haze of grey and darkness. The fairy despaired. It wanted no part of this place. It pretended for a time to be awake but the bright daylight would not come. It pretended for a time to be dreaming but the colors and memories would not come. That is when the fairy wished for oblivion. Then just as suddenly, it awoke in the daylight. It fell to the ground, stunned as if it had forgotten how to walk in the too bright daylight. Though the world again grew softer and kinder in time, the pixel fairies were never the same. For the night is dark and full of terrors. --- It used to be easy. Screen on and screen off could explain almost everything about the state of the device but it's different now with ambient display. We need to be able to wait for all windows to be drawn even in the case where the device is still nominally asleep. In truth, the window manager policy which drives a lot of these interactions is a thicket of outdated assumptions. Added a new method to tell the window manager policy when the screen is being turned off so that it can correctly account for changes to the interactive state (wakeUp and goingToSleep) and screen state (screenTurningOn and screenTurnedOff). Now we can independently poke keyguard during interactive state changes and we can apply screen on blocking during screen state changes. Moved the code which manages screen on blocking (which is what ensures the UI has fully drawn before revealing screen contents) from the power manager to the display manager since the display manager is in a better position to accurately track the state of the screen, particularly when the screen is being turned off. Fixed a bunch of synchronization issues. Previously some work had been moved to a handler without considering what might happen if it became reordered relative to other work happening elsewhere. Documented the desired behavior in the code to prevent this from happening again. There's still a bunch of stuff in here that isn't quite right, particularly the assumption that there's only one screen, but it's good enough for now. Hopefully there aren't too many bugs. Bug: 17605802 Change-Id: Ic7319e09948c8a3cda014d7e169c964a3ad86f14
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
36c4db8bd3bd7dad4b6cb8abd9cdc1a627fe3bbc |
|
19-Sep-2014 |
Jeff Brown <jeffbrown@google.com> |
Decouple turning screen on from waking up in policy. This allows us to ensure windows are fully drawn before unblocking screen on while dozing. Bug: 17516245 Change-Id: Ibe63c212b8db855ce26a34a8169f33764b266ee6
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
7d7808fcf8e6a1c27d52375210f9da2705d5f590 |
|
12-Sep-2014 |
Craig Mautner <cmautner@google.com> |
Show all windows from activity that hides keyguard Popup windows from the activity hiding the keyguard weren't being shown. This change retrieves that activity from PhoneWindowManager and applies the show or hide call to the windows that match the activity. Fixes bug 16479813. Change-Id: Ia6fe97240aec85c5233eee9038138f7d48095a6e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
a6863ad62296a5280504165a1fbc70523940a9c8 |
|
05-Sep-2014 |
Michael Wright <michaelwr@google.com> |
Merge "Allow for event dispatching when in non-interactive states." into lmp-dev
|
70af00abf73160235d4efe114fcf4753007a8ff3 |
|
04-Sep-2014 |
Michael Wright <michaelwr@google.com> |
Allow for event dispatching when in non-interactive states. We need to allow for event dispatching in non-interactive states so that we can enable a richer set of interactions when a device is dozing (i.e. is in a low power state with an Always-on-Display). Bug: 17167296 Change-Id: I8ae0f544a8106cb91ff38c2309b8b57cbe2f2c72
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3818c9261ceaa3a700ff984fbcd245faeede38d7 |
|
02-Sep-2014 |
Michael Wright <michaelwr@google.com> |
Add support for SW_CAMERA_LENS_COVER. This allows for magic cover type accessories to launch the camera application. Bug: 16034563 Change-Id: I0a46ef885737d964a1482c99f41145053d559faf
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
84a3e7aacf6dbeccf4afb36a29f2f069dca7d486 |
|
13-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Use different unlock animation when going to full shade Also fixes a bug that the notify flag was not reset, and fix the transition for the phone/camera affordance (in these cases, no animation is needed). Bug: 15991916 Change-Id: Idbb4fa40f86bda597cd66cc38da838ef4f75514d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
8de4311c51229efbe2f2d0afbf298982c5cadd96 |
|
11-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Lockscreen launch animations - Get rid of ActivityManager.dismissKeyguardOnNextActivity, which was used for two different things: Dismiss keyguard from somewhere else (not really necessary anymore), wait to actually dismiss keyguard after the window behind is drawn. Instead, introduce keyguardWaitingForActivityDrawn(), and change the semantics where necessary. - Make wallpaper_close_enter consistent with task_open_enter and the Keyguard launch animation. - Close the panel even on lockscreen when launching a notification. - Block notification shade updates during the collapsing motion so notification don't play the disappear animation immediately after having launched a notification. Bug: 15991916 Change-Id: I133c177b84e926c87c1a404ba93d633593fec3ab
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
76a1623afc170a13923b68f3256057d8adeb7937 |
|
08-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Preparations for lockscreen launch animations - Update unlock animations to new spec to make the consistent with lockscreen launch animations. - Introduce disappearing motion for security views which runs before we actually dismiss Keyguard. - If a window is running the un-force-hide animation, treat as it would have the wallpaper flag set so the wallpaper stays until the animation is completely done. - Run an animation on the wallpaper if the wallpaper is going away. Bug: 15991916 Bug: 16234603 Bug: 15326120 Change-Id: I063aa4f269ddcf75b9a705e90f0c3056b541b642
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e34560b21989eea54a139a0586d156ba573cc2ea |
|
10-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add accessibility action to open power long-press dialog Also fixes an infinite recursion bug in the WindowManagerService implementation of WindowManagerInternal. BUG: 16129909 Change-Id: I4f9d32f4e6c3ad460652c5e5271540fa5032a1f5
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
fa10423fa00f3495e451016acba9b6848eb995c9 |
|
21-Jun-2014 |
Adrian Roos <roosa@google.com> |
Add stable insets for stable system windows Adds a new kind of inset that only accounts for stable system windows like the system or navigation bar. Bug: 15457292 Change-Id: I681b711f6f40a94c25b7acd3a44eb3539486afab
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
84984faf530e525b066e28710d0f9beb32142ec5 |
|
19-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Return to recents when coming from recents If a task is launched from recents then backing all the way out of the task will return you to recents. Entering the task in any other way (home, another activity, nav bar) will reset this behavior. Fixes bug 15703876. Change-Id: I98dc36e4dbcb238d59e2175832076de7225bfdd9
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c9457faeb6bf22ce8fc72bc61af5109a2b567c51 |
|
06-Jun-2014 |
Craig Mautner <cmautner@google.com> |
Do not display unsecure windows behind dialogs If a dialog activity has FLAG_SHOW_WHEN_LOCKED set it will dismiss the keyguard. Previously this would expose any full screen unsecure windows behind the dialog. With this fix the dialog is displayed over the wallpaper. Fixes bug 15006623. Change-Id: I85a6713c7647db52211bd0f7280010e859723710
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e29b2dbc762bfa66093d76f5a65f55328d8753c9 |
|
30-May-2014 |
Jorim Jaggi <jjaggi@google.com> |
Fade scrim in unlock animation. This also introduces a startTime which gets sent from window manager to SystemUI, which tells when the animation should start, to allow for a more synchronized animation with fading out the scrim and fading in the activity behind. Bug: 15163546 Change-Id: I16212b1ef9eb76f1f98734da1d14fc5b7e626937
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
71ac80c46a1b094ad951e59c24791d9e9ef769bf |
|
29-May-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Revert "Modify task navigation to return to recent tasks." DO NOT MERGE" into lmp-preview-dev
|
b9a6c8ad99c7885dccc23223068c0a551f350cd5 |
|
29-May-2014 |
Craig Mautner <cmautner@google.com> |
Revert "Modify task navigation to return to recent tasks." DO NOT MERGE This reverts commit 1a4e211e03f1f795d935058e27356a0e8bc5df7c. Change-Id: Ia691b93347c7eb2395933e5a5ba385ea94e08d6f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
219d7a50fb7a269fe54dd9d70587c269d217336f |
|
29-May-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Add methods to coordinate unlock animation." into lmp-preview-dev
|
e30e02f5d9a9141c9ee70c712d4f9d52c88ea969 |
|
28-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Add system layer for voice interaction services. New window layer that voice interaction service windows go in to. Includes a new voice-specific content rectangle that voice activities are placed in to. Add specific animations for this layer, sliding down from the top (though this can be customized by the voice interaction service). Also add the concept of activities running for voice interaction services for purposes of adjusting the animation used for them, again sliding from the top, but not (yet?) customizable by the voice interaction service. Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0d674623facfbd3e9c520d2be4ed98977b92a1a2 |
|
21-May-2014 |
Jorim Jaggi <jjaggi@google.com> |
Add methods to coordinate unlock animation. Introduce IWindowManager.keyguardGoingAway to notify that Keyguard wants to dismiss it self. This method starts the state machine in WindowAnimator which animates in the activity behind the keyguard. Animating out the keyguard is done by the StatusBar/Keyguard software when it receives the startKeyguardExitAnimation() callback. Bug: 14118756 Change-Id: Id3b8f41189410bad808b4892fbec74245e59efce
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e67a784eb2c914c04c62ea5dfa1e3751df5582cc |
|
21-May-2014 |
Craig Mautner <cmautner@google.com> |
Modify task navigation to return to recent tasks. DO NOT MERGE Tasks launched from the recent task list will now return to the list when they are finished. Also tasks that are launched from the notification panel and services will now return to the list, provided that the launcher is not front and center when they are launched. Fixes bug 14464114. Change-Id: Ic0d3731fc7248d1eaa80e5ee399753d80e80c979
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
fb0448ab4b42c1b390cd75c3660ec0de511b7b3b |
|
02-May-2014 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of 4f8cd188 to master Change-Id: I148cd616cd14d834915978aa2dc3f9e27188dbd3
|
140ffc783c50bbe3b62e817c117a31b93e7f627e |
|
02-May-2014 |
Jeff Brown <jeffbrown@google.com> |
Clean up some terminology related to interactive state. Change-Id: Ife4445685a5314dea64332a3490fa8dd3ffd89a2
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
337d9d2edc262141f9b8f684e53aae5e47f0ae13 |
|
23-Apr-2014 |
Michael Wright <michaelwr@google.com> |
Move key attribute information into KeyEvent. This consolidates all of the information that was in the native KeyEvent and the KeyLayout files into the managed KeyEvent class. It also moves the definition for all of the key names to the native side, rather than having them in both places. Change-Id: I172e3b554e7eb52c79ae2ec406ef4332e8b25ffa
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
858737d08d9a2db7ef230a17975cd4ded709c3c5 |
|
11-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of 4e5c089e to master-lockscreen-dev Change-Id: I456ff6be1e39b65f3e0efeb7fb1924e71d11f6b1
|
4e5c089ef3e62e7f658e71c0be262d09bd3e399b |
|
11-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of 337e764d to master Change-Id: I8168dbf42b68c2f7b5ccb300e0080dddc627af26
|
037c33eae74bee2774897d969d48947f9abe254f |
|
09-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
Plumb display power state through display manager. Declare a new method, Display.getState() to retrieve the actual power state of a display. Improved documentation for Intent.ACTION_SCREEN_ON and Intent.ACTION_SCREEN_OFF to clarify what they really mean in terms of the interactive state of the device. Deprecated PowerManager.isScreenOn() and replaced it with PowerManager.isInteractive() with a more suggestive name and better documentation. Redirect display power state changes to go through the display manager first and only then head over to the power manager for legacy compatibility. Eliminated the bright here and woke here policy flags since they were unused. Simplified the input dispatch policy somewhat. Ensure that screen wake locks are respected up until the point when dozing really begins. Fixed a regression in DreamService where onDreamingStarted might be called before onWindowAttached. Bug: 13133142 Bug: 13472578 Bug: 13929355 Bug: 13760290 Change-Id: Iabef96921dd554ce3768fb18619cefc3230b5fb0
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
cff0acb6b1eea23c3f44a078a0a5e81c11faea35 |
|
31-Mar-2014 |
Jorim Jaggi <jjaggi@google.com> |
Wait for Keyguard to be drawn after boot. The old logic with waiting for the Keyguard to be drawn assumed that it is in an own window, and just checked for the visibility. This is no longer possible as the Keyguard is in the status bar, and the status bar might have been drawn without the Keyguard. So we have to wait explicitely until Keyguard told PhoneWindowManager that it has now been drawn and we can turn on the screen. In addition, the starting logic of SystemUI is moved into SystemUIApplication such the we can make sure that the status bar already exists when the callbacks from PhoneWindowManager reach KeyguardService. This simplifies the logic a lot. Bug: 13635952 Change-Id: Ifd6ba795647edcf3501641e39052e4d04bc826fb
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9cf34e2ee4cb3d2e14c2863298ad3a2fafc31d39 |
|
23-Mar-2014 |
Craig Mautner <cmautner@google.com> |
Revert "Apply FLAG_SHOW_WHEN_LOCKED within tasks." This reverts commit f7ad855718dc576a1618a54035b82e92356aa0d8. After careful consideration this would prove to be a security leak to leave it in. Tasks could deliberately launch dialog activities that don't want to be seen in an unsecure setting. These would then be visible over the task background. Change-Id: Ia7e984bc9616573af6c7772f6ea0f2dd588bb85d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f7ad855718dc576a1618a54035b82e92356aa0d8 |
|
21-Mar-2014 |
Craig Mautner <cmautner@google.com> |
Apply FLAG_SHOW_WHEN_LOCKED within tasks. If the bottommost fullscreen window of a task has FLAG_SHOW_WHEN_LOCKED set then show all windows of the task that are above that window. Fixes bug 13558398. Change-Id: Ied8ada54efbb079eaf375470b2eae749e5551c24
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
8e3feb15c5aec2c72b0ef120a1da325e1e8f0dda |
|
24-Feb-2014 |
Svetoslav <svetoslavganov@google.com> |
Added accessibility APIs for introspecting interactive windows. 1. The old introspection model was allowing querying only the active window which is the one the user is touching or the focused one if no window is touched. This was limiting as auto completion drop downs were not inspectable, there was not way to know when the IME toggles, non-focusable windows were not inspectable if the user taps them as until a screen-reader starts introspecting the users finger is up, accessibility focus was limited to only one window and the user couldn't use gestures to visit the whole UI, and other things I can't remember right now. The new APIs allow getting all interactive windows, i.e. ones that a sighted user can interact with. This prevents an accessibility service from interacting with content a sighter user cannot. The list of windows can be obtained from an accessibility service or the host window from an accessibility node info. Introspecting windows obey the same rules for introspecting node, i.e. the service has to declare this capability in its manifest. When some windows change accessibility services receive a new type of event. Initially the types of windows is very limited. We provide the bounds in screen, layer, and some other properties which are enough for a client to determined the spacial and hierarchical relationship of the windows. 2. Update the documentation in AccessibilityService for newer event types. 3. LongArray was not removing elements properly. 4. Composite accessibility node ids were not properly constructed as they are composed of two ints, each taking 32 bits. However, the values for undefined were -1 so composing a 64 long from -1, -1 prevents from getting back these values when unpacking. 5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added a check that enforces such trees to be well formed on dev builds. 6. Removed an necessary code for piping the touch exploration state to the policy as it should just use the AccessibilityManager from context. 7. When view's visibility changed it was not firing an event to notify clients it disappeared/appeared. Also ViewGroup was sending accessibility events for changes if the view is included for accessibility but this is wrong as there may be a service that want all nodes, hence events from them. The accessibility manager service takes care of delivering events from not important for accessibility nodes only to services that want such. 8. Several places were asking for prefetching of sibling but not predecessor nodes which resulted in prefetching of unconnected subtrees. 9. The local AccessibilityManager implementation was relying on the backing service being ready when it is created but it can be fetched from a context before that. If that happens the local manager was in a broken state forever. Now it is more robust and starts working properly once the backing service is up. Several places were lacking locking. bug:13331285 Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
10102e4c0e501333a12b38a5cfe709d1558d84dd |
|
21-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of baaa080b to master Change-Id: I3ee12321e298f7a2ea577a99f30c49f3bb497fae
|
2687550272ba061448f5d5b914700dc335299ee7 |
|
31-Jan-2014 |
Jeff Brown <jeffbrown@google.com> |
Add a new "doze mode" based on Dream components. When a doze component has been specified in a config.xml resource overlay, the power manager will try to start a preconfigured dream whenever it would have otherwise gone to sleep and turned the screen off. The dream should render whatever it intends to show then call startDozing() to tell the power manager to put the display into a low power "doze" state and allow the application processor to be suspended. The dream may wake up periodically using the alarm manager or other features to update the contents of the display. Added several new config.xml resources related to dreams and dozing. In particular for dozing there are two new resources that pertain to decoupling auto-suspend mode and interactive mode from the display state. This is a requirement to enable the application processor and other components to be suspended while dozing. Most devices do not support these features today. Consolidated the power manager's NAPPING and DREAMING states into one to simplify the logic. The NAPPING state was mostly superfluous and simply indicated that the power manager should attempt to start a new dream. This state is now tracked in the mSandmanSummoned field. Added a new DOZING state which is analoguous to DREAMING. The normal state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP. The PowerManager.goToSleep() method now enters the DOZING state instead of immediately going to sleep. While in the doze state, the screen remains on. However, we actually tell the rest of the system that the screen is off. This is somewhat unfortunate but much of the system makes inappropriate assumptions about what it means for the screen to be on or off. In particular, screen on is usually taken to indicate an interactive state where the user is present but that's not at all true for dozing (and is only sometimes true while dreaming). We will probably need to add some more precise externally visible states at some point. The DozeHardware interface encapsulates a generic microcontroller interface to allow a doze dream for off-loading rendering or other functions while dozing. If the device possesses an MCU HAL for dozing then it is exposed to the DreamService here. Removed a number of catch blocks in DreamService that caught Throwable and attempted to cause the dream to finish itself. We actually just want to let the process crash. Cleanup will happen automatically if needed. Catching these exceptions results in mysterious undefined behavior and broken dreams. Bug: 12494706 Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
658c7b896a751b971db1292d86655dbb97f00067 |
|
10-Oct-2013 |
Satoshi Kataoka <satok@google.com> |
Introduce an API to get the recommended height of the InputMethodWindow Bug: 11035379 Bug: 5137498 Change-Id: I0e920ee79c526c3aea6872b063cf294e2ab081c8
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
516f953a82896a9b431ad87cb457277c62c75162 |
|
08-Oct-2013 |
Alan Viverette <alanv@google.com> |
resolved conflicts for merge of e4ccb864 to master Change-Id: I50c41c712c4eb4f68b22777efb2e5d5370536b22
|
5a0f4eccfb1e1774c4aac825bf39bcc4f5fc00e0 |
|
08-Oct-2013 |
Alan Viverette <alanv@google.com> |
Ignore certain WindowManager flags when touch exploration is enabled Specifically, ignore any flags that alter the visibility of the navigation bar and transparency. BUG: 11082573 Change-Id: I17264dc55a1c6c3cb9b9cf92d5121799cecee5b8
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
b7ba2630bdd6a0d7f68f3ca62b6ceb5160266c9a |
|
04-Oct-2013 |
John Spurlock <jspurlock@google.com> |
am bee8af82: am c3752cfb: am e660ecc4: Merge "Store decor rects per window for transition cropping." into klp-dev * commit 'bee8af8207938fb0d29b38d915be1803edc64d69': Store decor rects per window for transition cropping.
|
38dc2ad85e4572d6e56f0a98edd97945312f708c |
|
04-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
am b2db2fbc: am 6d90862f: am d65825ab: Merge "Private flags are masked in correct variable" into klp-dev * commit 'b2db2fbce33dbcfa52ccb20267ad4897c558c34f': Private flags are masked in correct variable
|
e660ecc436c6bb9d3476298e97976a24b432482e |
|
03-Oct-2013 |
John Spurlock <jspurlock@google.com> |
Merge "Store decor rects per window for transition cropping." into klp-dev
|
95c42974f719d1fac90fc0438eac778e9795681f |
|
02-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
Private flags are masked in correct variable 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4664623c304cf162b9a78f3aee3290a92e54b628 |
|
01-Oct-2013 |
John Spurlock <jspurlock@google.com> |
Store decor rects per window for transition cropping. 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d273cae2c49c3f6d21f53406b7540e572c11bba0 |
|
02-Oct-2013 |
Jim Miller <jaggies@google.com> |
resolved conflicts for merge of fb2e3c8d to master Change-Id: Ic9fe2674e0eb82d071f9b547b6089acacf705576
|
6c9df5054a25f179ea7359a1a5e59e7d5d8da122 |
|
20-Sep-2013 |
Jim Miller <jaggies@google.com> |
Fix permissions on WindowManagerService.showAssistant() 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
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d9273d6f289d9b55da3fd0db2f659fdfb48106a8 |
|
31-May-2013 |
Tor Norbye <tnorbye@google.com> |
Add typedefs and nullness annotations. This changeset adds in typedef annotations (custom annotations marked with @IntDef) for various int parameters and return values in the API. It also adds nullness annotations for cases where the documentation explicitly mentioned null policy, or where it was blindingly obvious from the context. Also fixed some typos in the documentation. Change-Id: Ica27c01368895818e26237544edd8483007155bb
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
46ac6fa614131d567bed93d1d2067d765ecef85d |
|
01-Aug-2013 |
Craig Mautner <cmautner@google.com> |
Add force default orientation. Devices can be configured to remain in their default landscape or portrait orientation by setting config_forceDefaultOrientation true in overlay/.../values/config.xml. Activities that desire to run in the non-default orientation are supported by creating a logical display within the physical display. Transitions to and from the activity perform a crossfade rather than the normal rotation animation. Also, improve SurfaceTrace debug output. Fixes bug 9695710. Change-Id: I053e136cd2b9ae200028595f245b6ada5927cfe9
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
80f00c1f2375796dab09bc4ed5b7631c62f7e158 |
|
13-Jun-2013 |
John Spurlock <jspurlock@google.com> |
Remove concept of system bar from window manager. It was already hardcoded to false, this change removes the dead code. Change-Id: I5e543344e60f69cb9882a70ba29f7c09404ad9fc
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
037aa8d434984840691378f3cc7d99d63dcc4076 |
|
07-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Centralize all system InputEventReceiver monitors. Implement all system level InputEvent monitors as new InputEventListeners. Only one InputChannel required and monitoring can be enabled or disabled by registering with WindowManagerService. Change-Id: I64714ab858342ed183c62b421098478ffb6637bc
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
04fe6ebb9f919f196ec06a19bebc09b8e943f95b |
|
31-May-2013 |
Adam Powell <adamp@google.com> |
Fix a bug resolving the correct icon/logo in action bars Remove some abstraction-breaking magic in ActionBarView and replace it with proper resolution of the icon/logo when creating a window. The old implementation relied on the ActionBarView's context being an Activity. Bug 9171554 Change-Id: Idbbb1942622195dcb55e8119f2d64287b07bb509
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
04db1762fb75a3938dda34537626c41c8e97d9c5 |
|
13-May-2013 |
John Spurlock <jspurlock@google.com> |
Window manager cleanup. Specifically: - Fix policy vs wm lock management issues. - Share runnable to avoid allocation. - Remove unused noop runnable. - Make sure to handle status bar = null case. - Fix javadoc typo. Bug: 8890313 Change-Id: I242eaef8e946025f6885d6dba3225722fb0ca7ce
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
967212cb542e6eeb308678367b53381bff984c31 |
|
14-Apr-2013 |
Craig Mautner <cmautner@google.com> |
Implement stack splitting and task movement. Split stacks and move tasks between them. Layout the windows according to the new stack split. After layout content rectangles are known split the available area between all stack boxes. Then use those values for future layout. Provide stack contents to ActivityManager. Change-Id: I9746e6185445633810d506be514d0b7b540a7f99
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c4aad01cbbb69c916ef323693e1fd0560b0eccba |
|
23-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Formalize overscan metrics. The window manager now maintains and reports a new formal "overscan insets" for each window, much like the existing content and visible insets. This is used to correctly position the various UI elements in the various combination of layout options. In particular, this allows us to have an activity that is using fitSystemWindows to have the content of its UI extend out to the visible content part of the screen while still positioning its fixed UI elements inside the standard content rect (and the entire window extending all the way into the overscan area to fill the screen as desired). Okay, maybe that is not written so clearly. Well, it made my head hurt too, so suffer! The key thing is that windows now need to know about three rectangles: the overall rectangle of the window, the rectangle inside of the overscan area, and the rectangle inside of the content area. The FLAG_LAYOUT_IN_OVERSCAN option controls whether the second rectangle is pushed out to fill the entire overscan area. Also did some improvements to debug dumping in the window manager. Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3c1743705c4df816089e07a17753c6043b4d8e66 |
|
22-Feb-2013 |
Craig Mautner <cmautner@google.com> |
Create rotation animation modes. Allow fullscreen windows to specify crossfade or jumpcut animations that override the default rotation animation. Only if the incoming and outgoing topmost windows are fullscreen and both specify the same animation to use. Fixes bug 8182773. Change-Id: I6b3c0020d7bd2cdfba5c66189e114ec62cd54fcf
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c652de8141f5b8e3c6bcf8916842b6e106413b1a |
|
16-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement display overscan support. The window manager now keeps track of the overscan of each display, with an API to set it. The overscan impacts how it positions windows in the display. There is a new set of APIs for windows to say they would like to go into the overscan region. There is a call into the window manager to set the overscan region for a display, and it now has a concept of display settings that it stores presistently. Also added a new "wm" command, moving the window manager specific commands from the "am" command to there and adding a new now to set the overscan region. Change-Id: Id2c8092db64fd0a982274fedac7658d82f30f9ff
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c2293025a25e04b26bf53713d71f85fd9ca5e8e9 |
|
07-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: track system windows, monitoring changes. Change-Id: I273e82bdad66ada3bf0f7ec9176bc304b9ee1ee8
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f265ea9d8307282ff1da3915978625a94fc2859e |
|
01-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: vibration, neighboring cells, dialing, etc. Improve handling of vibration op, so that apps are better blamed (there is now a hidden vibrator API that supplies the app to blame, and the system now uses this when vibrating on behalf of an app). Add operation for retrieving neighboring cell information. Add a new op for calling a phone number. This required plumbing information about the launching package name through the activity manager, which required changing the internal startActivity class, which required hitting a ton of code that uses those internal APIs. Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
80943d8daa6ab31ab5c486d57aea406aa0730d58 |
|
02-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding UI test automation APIs. This change adds APIs support for implementing UI tests. Such tests do not rely on internal application structure and can span across application boundaries. UI automation APIs are encapsulated in the UiAutomation object that is provided by an Instrumentation object. It is initialized by the system and can be used for both introspecting the screen and performing interactions simulating a user. UI test are normal instrumentation tests and are executed on the device. UiAutomation uses the accessibility APIs to introspect the screen and a special delegate object to perform privileged operations such as injecting input events. Since instrumentation tests are invoked by a shell command, the shell program launching the tests creates a delegate object and passes it as an argument to started instrumentation. This delegate allows the APK that runs the tests to access some privileged operations protected by a signature level permissions which are explicitly granted to the shell user. The UiAutomation object also supports running tests in the legacy way where the tests are run as a Java shell program. This enables existing UiAutomator tests to keep working while the new ones should be implemented using the new APIs. The UiAutomation object exposes lower level APIs which allow simulation of arbitrary user interactions and writing complete UI test cases. Clients, such as UiAutomator, are encouraged to implement higher- level APIs which minimize development effort and can be used as a helper library by the test developer. The benefit of this change is decoupling UiAutomator from the system since the former was calling hidden APIs which required that it is bundled in the system image. This prevented UiAutomator from being evolved separately from the system. Also UiAutomator was creating additional API surface in the system image. Another benefit of the new design is that now test cases have access to a context and can use public platform APIs in addition to the UiAutomator ones. Further, third-parties can develop their own higher level test APIs on top of the lower level ones exposes by UiAutomation. bug:8028258 Also this change adds the fully qualified resource name of the view's id in the emitted AccessibilityNodeInfo if a special flag is set while configuring the accessibility service. Also added is API for looking up node infos by this id. The id resource name is relatively more stable compared to the generaed id number which may change from one build to another. This API facilitate reuing the already defined ids for UI automation. bug:7678973 Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4b71aa1f8a1a3b7189fd29241ea7c594ce01623c |
|
28-Dec-2012 |
Craig Mautner <cmautner@google.com> |
Move app transition constants Move app transition constants from WindowManagerPolicy to AppTransition. Change-Id: I8ae6c4d0da1db826c44eb4ea0c6b85016b50b1a3
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
545252f4fde6fbb70b07e97a120c7d1405758017 |
|
11-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature. 1. This patch takes care of the case where a magnified window is covering an unmagnigied one. One example is a dialog that covers the IME window. bug:7634430 2. Ensuring that the UI automator tool can connect and correctly dump the screen. bug:7694696 3. Removed the partial implementation for multi display magnification. It adds unnecessary complexity since it cannot be implemented without support for input from multiple screens. We will revisit when necessary. 4. Moved the magnified border window as a surface in the window manager. 5. Moved the mediator APIs on the window manager and the policy methods on the WindowManagerPolicy. 6. Implemented batch event processing for the accessibility input filter. Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
152e9bb81aa5b2ab4637f4b2dae04b3ce89fa891 |
|
13-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature. 1. The screen magnification feature was implemented entirely as a part of the accessibility manager. To achieve that the window manager had to implement a bunch of hooks for an external client to observe its internal state. This was problematic since it dilutes the window manager interface and allows code that is deeply coupled with the window manager to reside outside of it. Also the observer callbacks were IPCs which cannot be called with the window manager's lock held. To avoid that the window manager had to post messages requesting notification of interested parties which makes the code consuming the callbacks to run asynchronously of the window manager. This causes timing issues and adds unnecessary complexity. Now the magnification logic is split in two halves. The first half that is responsible to track the magnified portion of the screen and serve as a policy which windows can be magnified and it is a part of the window manager. This part exposes higher level APIs allowing interested parties with the right permissions to control the magnification of a given display. The APIs also allow a client to be registered for callbacks on interesting changes such as resize of the magnified region, etc. This part servers as a mediator between magnification controllers and the window manager. The second half is a controller that is responsible to drive the magnification state based on touch interactions. It also presents a highlight when magnified to suggest the magnified potion of the screen. The controller is responsible for auto zooming out in case the user context changes - rotation, new actitivity. The controller also auto pans if a dialog appears and it does not interesect the magnified frame. bug:7410464 2. By design screen magnification and touch exploration work separately and together. If magnification is enabled the user sees a larger version of the widgets and a sub section of the screen content. Accessibility services use the introspection APIs to "see" what is on the screen so they can speak it, navigate to the next item in response to a gesture, etc. Hence, the information returned to accessibility services has to reflect what a sighted user would see on the screen. Therefore, if the screen is magnified we need to adjust the bounds and position of the infos describing views in a magnified window such that the info bounds are equivalent to what the user sees. To improve performance we keep accessibility node info caches in the client process. However, when magnification state changes we have to clear these caches since the bounds of the cached infos no longer reflect the screen content which just got smaller or larger. This patch propagates not only the window scale as before but also the X/Y pan and the bounds of the magnified portion of the screen to the introspected app. This information is used to adjust the bounds of the node infos coming from this window such that the reported bounds are the same as the user sees not as the app thinks they are. Note that if magnification is enabled we zoom the content and pan it along the X and Y axis. Also recomputed is the isVisibleToUser property of the reported info since in a magnified state the user sees a subset of the window content and the views not in the magnified viewport should be reported as not visible to the user. bug:7344059 Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4eeb4f664ac6b5901a8e874dcf70c0382295f792 |
|
08-Nov-2012 |
Jim Miller <jaggies@google.com> |
Add mechanism to kick keyguard to show the assistant Fixes bug 7499778 Change-Id: Ic9ea514feb489feeee6716f40bdb9792842f9515
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2874a54068af1e7de3c1c046cc0061412daafaf8 |
|
06-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Add flag for displaying non-user's Windows to user." into jb-mr1-dev
|
88400d3a31139c40c4014faf86c243647087ef6c |
|
30-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Add flag for displaying non-user's Windows to user. Created a new flag that indicates that a window should be shown to all users. For the flag to be valid the owner of the window must have system permissions. Also separated system window types into those that show to all users (e.g. StatusBar, Keyguard, ....) and those that appear only to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear only to their owner can override their default behavior using the new flag (e.g. LowBattery). Fixes bug 7211965. Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c38c9be031ddad5cf551b55458889f11e01dc5b2 |
|
04-Oct-2012 |
Jeff Brown <jeffbrown@google.com> |
Coordinate screen on with the window manager. Bug: 7267457 Change-Id: Ic2c322253639e1f0b2e4e72a7b145025d0240f93
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f752202bee88e31ce765483ba2efa6999ae9c9ad |
|
04-Oct-2012 |
Adam Cohen <adamcohen@google.com> |
Plumbing to allow keyguard to be shown with user switcher (issue 7175023) -> Also reduced calls to lockNow, and moved this call in ActivityManagerService Change-Id: I9ba34ca902f7c0f71fa4ec302104688ca8d11f55
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f1b674197577e815040cd75ef86d611965d603ad |
|
19-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Fix deadlock in LockPatternUtils by using local id. Activity manager now updates window manager's current user id directly and immediately rather than waiting for a broadcast update. Window manager passes this through policy to the KeyguardViewMediator and into LockPatternUtils. LockPatternUtils no longer goes to Activity to get the current user id if it finds that its local id is non-default. Fixes bug 7193726. Change-Id: Id5613e7a9fe9e5b49e83c26b74504f587c3998c2
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
1cf70bbf96930662cab0e699d70b62865766ff52 |
|
06-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Screen magnification - feature - framework. This change is the initial check in of the screen magnification feature. This feature enables magnification of the screen via global gestures (assuming it has been enabled from settings) to allow a low vision user to efficiently use an Android device. Interaction model: 1. Triple tap toggles permanent screen magnification which is magnifying the area around the location of the triple tap. One can think of the location of the triple tap as the center of the magnified viewport. For example, a triple tap when not magnified would magnify the screen and leave it in a magnified state. A triple tapping when magnified would clear magnification and leave the screen in a not magnified state. 2. Triple tap and hold would magnify the screen if not magnified and enable viewport dragging mode until the finger goes up. One can think of this mode as a way to move the magnified viewport since the area around the moving finger will be magnified to fit the screen. For example, if the screen was not magnified and the user triple taps and holds the screen would magnify and the viewport will follow the user's finger. When the finger goes up the screen will clear zoom out. If the same user interaction is performed when the screen is magnified, the viewport movement will be the same but when the finger goes up the screen will stay magnified. In other words, the initial magnified state is sticky. 3. Pinching with any number of additional fingers when viewport dragging is enabled, i.e. the user triple tapped and holds, would adjust the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 4. When in a permanent magnified state the user can use two or more fingers to pan the viewport. Note that in this mode the content is panned as opposed to the viewport dragging mode in which the viewport is moved. 5. When in a permanent magnified state the user can use three or more fingers to change the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 6. The magnification scale will be persisted in settings and in the cloud. Note: Since two fingers are used to pan the content in a permanently magnified state no other two finger gestures in touch exploration or applications will work unless the uses zooms out to normal state where all gestures works as expected. This is an intentional tradeoff to allow efficient panning since in a permanently magnified state this would be the dominant action to be performed. Design: 1. The window manager exposes APIs for setting accessibility transformation which is a scale and offsets for X and Y axis. The window manager queries the window policy for which windows will not be magnified. For example, the IME windows and the navigation bar are not magnified including windows that are attached to them. 2. The accessibility features such a screen magnification and touch exploration are now impemented as a sequence of transformations on the event stream. The accessibility manager service may request each of these features or both. The behavior of the features is not changed based on the fact that another one is enabled. 3. The screen magnifier keeps a viewport of the content that is magnified which is surrounded by a glow in a magnified state. Interactions outside of the viewport are delegated directly to the application without interpretation. For example, a triple tap on the letter 'a' of the IME would type three letters instead of toggling magnified state. The viewport is updated on screen rotation and on window transitions. For example, when the IME pops up the viewport shrinks. 4. The glow around the viewport is implemented as a special type of window that does not take input focus, cannot be touched, is laid out in the screen coordiates with width and height matching these of the screen. When the magnified region changes the root view of the window draws the hightlight but the size of the window does not change - unless a rotation happens. All changes in the viewport size or showing or hiding it are animated. 5. The viewport is encapsulated in a class that knows how to show, hide, and resize the viewport - potentially animating that. This class uses the new animation framework for animations. 6. The magnification is handled by a magnification controller that keeps track of the current trnasformation to be applied to the screen content and the desired such. If these two are not the same it is responsibility of the magnification controller to reconcile them by potentially animating the transition from one to the other. 7. A dipslay content observer wathces for winodw transitions, screen rotations, and when a rectange on the screen has been reqeusted. This class is responsible for handling interesting state changes such as changing the viewport bounds on IME pop up or screen rotation, panning the content to make a requested rectangle visible on the screen, etc. 8. To implement viewport updates the window manger was updated with APIs to watch for window transitions and when a rectangle has been requested on the screen. These APIs are protected by a signature level permission. Also a parcelable and poolable window info class has been added with APIs for getting the window info given the window token. This enables getting some useful information about a window. There APIs are also signature protected. bug:6795382 Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
69b0818179201fadc9d2a384d692d8ae4aecd85c |
|
05-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Limit certain actions to default Display. Stop messing up PhoneWindowManager state when passing in windows from non-default Display. Change-Id: I472f7a13c5e2241fbf1f79ae1c8045fd92af016c
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
398341927f3dca68d71024483aa276d10af4c080 |
|
02-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Minor refactors. - Refactor DragState to take Display instead of DisplayContent. - Rename xxxAnimationLw methods in WindowManagerPolicy to xxxPostLayout to reflect animation refactoring. Change-Id: I502f2aa45a699ad395a249a12abf9843294623f0
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9a538ee7bde42ad36f43edc48594282d98e191a4 |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Add factory test feature to shut off on long press power. Bug: 6847329 Change-Id: I2f4f975c3af2d13ccc06812a5a42e79032700862
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support. Split WindowManagerImpl into two parts, the WindowManager interface implementation remains where it is but the global communications with the window manager are now handled by the WindowManagerGlobal class. This change greatly simplifies the challenge of having separate WindowManager instances for each Context. Removed WindowManagerImpl.getDefault(). This represents the bulk of this change. Most of the usages of this method were either to perform global functions (now handled by WindowManagerGlobal) or to obtain the default display (now handled by DisplayManager). Explicitly associate each new window with a display and make the Display object available to the View hierarchy. Add stubs for some new display manager API features. Start to split apart the concepts of display id and layer stack. since they operate at different layers of abstraction. While it's true that each logical display uniquely corresponds to a surface flinger layer stack, it is not necessarily the case that they must use the same ids. Added Display.getLayerStack() and started using it in places where it was relatively easy to do. Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9630704ed3b265f008a8f64ec60a33cf9dcd3345 |
|
28-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Power manager rewrite. The major goal of this rewrite is to make it easier to implement power management policies correctly. According, the new implementation primarily uses state-based rather than event-based triggers for applying changes to the current power state. For example, when an application requests that the proximity sensor be used to manage the screen state (by way of a wake lock), the power manager makes note of the fact that the set of wake locks changed. Then it executes a common update function that recalculates the entire state, first looking at wake locks, then considering user activity, and eventually determining whether the screen should be turned on or off. At this point it may make a request to a component called the DisplayPowerController to asynchronously update the display's powe state. Likewise, DisplayPowerController makes note of the updated power request and schedules its own update function to figure out what needs to be changed. The big benefit of this approach is that it's easy to mutate multiple properties of the power state simultaneously then apply their joint effects together all at once. Transitions between states are detected and resolved by the update in a consistent manner. The new power manager service has is implemented as a set of loosely coupled components. For the most part, information only flows one way through these components (by issuing a request to that component) although some components support sending a message back to indicate when the work has been completed. For example, the DisplayPowerController posts a callback runnable asynchronously to tell the PowerManagerService when the display is ready. An important feature of this approach is that each component neatly encapsulates its state and maintains its own invariants. Moreover, we do not need to worry about deadlocks or awkward mutual exclusion semantics because most of the requests are asynchronous. The benefits of this design are especially apparent in the implementation of the screen on / off and brightness control animations which are able to take advantage of framework features like properties, ObjectAnimator and Choreographer. The screen on / off animation is now the responsibility of the power manager (instead of surface flinger). This change makes it much easier to ensure that the animation is properly coordinated with other power state changes and eliminates the cause of race conditions in the older implementation. The because of the userActivity() function has been changed so that it never wakes the device from sleep. This change removes ambiguity around forcing or disabling user activity for various purposes. To wake the device, use wakeUp(). To put it to sleep, use goToSleep(). Simple. The power manager service interface and API has been significantly simplified and consolidated. Also fixed some inconsistencies related to how the minimum and maximum screen brightness setting was presented in brightness control widgets and enforced behind the scenes. At present the following features are implemented: - Wake locks. - User activity. - Wake up / go to sleep. - Power state broadcasts. - Battery stats and event log notifications. - Dreams. - Proximity screen off. - Animated screen on / off transitions. - Auto-dimming. - Auto-brightness control for the screen backlight with different timeouts for ramping up versus ramping down. - Auto-on when plugged or unplugged. - Stay on when plugged. - Device administration maximum user activity timeout. - Application controlled brightness via window manager. The following features are not yet implemented: - Reduced user activity timeout for the key guard. - Reduced user activity timeout for the phone application. - Coordinating screen on barriers with the window manager. - Preventing auto-rotation during power state changes. - Auto-brightness adjustment setting (feature was disabled in previous version of the power manager service pending an improved UI design so leaving it out for now). - Interpolated brightness control (a proposed new scheme for more compactly specifying auto-brightness levels in config.xml). - Button / keyboard backlight control. - Change window manager to associated WorkSource with KEEP_SCREEN_ON_FLAG wake lock instead of talking directly to the battery stats service. - Optionally support animating screen brightness when turning on/off instead of playing electron beam animation (config_animateScreenLights). Change-Id: I1d7a52e98f0449f76d70bf421f6a7f245957d1d7
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
dde331cebd87982faded6818ad5f9927ff994c96 |
|
03-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
We can now (kind-of) change screen density on the fly. Preloaded drawables now have a density associated with them, so we can load the correct drawable if we are using a different density. Window manager now formally keeps track of the density for each screen, allowing it to be overridden like you can already do with size, and relies on this density to drive itself internally and the configurations it reports. There are a new set of Bitmap constructors where you provide a DisplayMetrics so they can be constructed with the correct density. (This will be for when you can have different windows in the same app running at different densities.) ActivityThread now watches for density changes, and pushes them to the DENSITY_DEVICE and Bitmap global density values for that process. A new am command allows you to change the density.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda |
|
21-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Use two fingers to work some magic... Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d7a04de16798acc04ec0a89a0c7d9f1cf60d1521 |
|
17-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Capture window manager's last ANR state in bug report. Currently just grabbing the window state but we could grab other things as part of the last ANR report. Bug: 6680398 Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
cf39bdf3dff5e29447f6ce734b76dc3490385e58 |
|
18-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Add support for switching between multiple keyboard layouts. Also show a notification when an external keyboard is connected and does not have a keyboard layout selected yet. Bug: 6405203 Change-Id: Id0ac6d83b3b381f8a236b2244a04c9acb203db3c
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
2a7a6ca00ab176105b5bbfa6b17bb0dcd058d517 |
|
14-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "Implement new window cropping." into jb-dev
|
85afd1b6f871d471fdff1980134676a5f1690525 |
|
13-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Implement new window cropping. The window manager now performs the crop internally, evaluating it every animation from, to be able to update it along with the surface position. Change-Id: I960a2161b9defb6fba4840fa35aee4e411c39b32
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
7304c343821309dd15f769b18f1de2fa43751573 |
|
12-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Move power HAL interactions to PowerManagerService. This refactoring sets the stage for a follow-on change that will make use additional functions of the power HAL. Moved functionality from android.os.Power into PowerManagerService. None of these functions make sense being called outside of the system server. Moving them to the PowerManagerService makes it easier to ensure that the power HAL is initialized exactly once. Similarly, moved ShutdownThread out of the policy package and into the services package where it can tie into the PowerManagerService as needed. Bug: 6435382 Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c042ee2acd8529b95c5dc99240d626e61d2500cd |
|
08-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Disable input dispatch until boot finished. Bug: 6263070 Change-Id: I25e15e3d8af8eb3343c7b684fec345337d9f6aab
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e849230f444653e692024b4321044cb9f6188919 |
|
02-May-2012 |
satok <satok@google.com> |
Merge "DO NOT MERGE : Backport I5723f627ce323b0d12b Reduce window resizing during IME transition" into jb-dev
|
1bc0a49e3cade697201e454bb6e46ee789cef6e4 |
|
25-Apr-2012 |
satok <satok@google.com> |
DO NOT MERGE : Backport I5723f627ce323b0d12b Reduce window resizing during IME transition Bug: 5137498 Change-Id: Ieb8fd700d193eddaa31b0c5ebd8c7f7885586372
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0632b35b6828cd4324b3d218c2e38f895e819aad |
|
02-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Improve handling of built-in keyboard." into jb-dev
|
daa3753a04699724d2cfe824ac1f5a266d643a05 |
|
02-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve handling of built-in keyboard. The window manager policy made some incorrect assumptions about the meaning of the Configuration.keyboard field. We need to be more careful about distinguishing between built-in and external keyboards. Most of this change is to move the determination of the parts of the Configuration related to input devices into the WindowManagerService leveraging new features of the InputManagerService to good effect. Then we plumb through the flag that indicates whether a device is internal or external so that we can be more particular about how the lid switch effects changes to the Configuration. Bug: 6424373 Change-Id: I36a1c22ade35e578955465a25940a33f227b9763
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
5c58de3a523a384c47b0b1e0f5dd9728a74cd9f7 |
|
29-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Add system insets to windows. This will be used to determine which parts of a window a completely hidden by system UI elements (status bar, nav bar, system bar) so that they can be clipped out from rendering. Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0c2acffec8689f8721a454845b24a830bc37ce92 |
|
13-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Clean up lock screen hide animation. We now have an animation to apply to the thing behind the lock screen animation when it isn't on the wallpaper, which looks similar to the animation we use when both are on the wallpaper. In implementing this, cleaned up the code to figure out up-front which animation to run, getting rid of that kludgy thing that cleared the window animation if the wallpaper was not being used for the lower windows. Change-Id: Ifc4c8a8894ad384124dcf4bbdaab134f1157b0f3
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
7d276c377ce0c56630c06a6da431a6cb9bd76d1e |
|
30-Jan-2012 |
Daniel Sandler <dsandler@android.com> |
New Android Dreams architecture, disabled for now. Rather than normal Activities (which have a host of problems when used for this purpose), screen savers are now a special kind of Service that can add views to its own special window (TYPE_DREAM, in the SCREENSAVER layer). Dreams are now launched by the power manager; whenever it is about to turn the screen off, it asks the window manager if it wants to run a screen saver instead. (http://b/5677408) Also, the new config_enableDreams bool allows the entire feature to be switched on or off in one place. It is currently switched off (and the APIs are all @hidden). Change-Id: Idfe9d430568471d15f4b463cb70586a899a331f7
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ac14351e16e1258f1cb54e2bf772b8be004eb2b8 |
|
06-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Move some APIs from window manager to input manager. Simplified input injection API down to just one call. Removed all input state reading API. It was only used by the window manager policy and required a permission that applications could not obtain. READ_INPUT_STATE is now unused and deprecated. Change-Id: I41278141586ddee9468cae0fb59ff0dced6cbc00
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f87d19621dc2a30232bba1f51862a0b671eb9729 |
|
04-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Clean up status bar, system bar, navigation bar management. The status bar and navigation bar are two completely separate elements, with their own semantics. The system bar now classifies itself as a navigation bar, since that is really how it behaves. This required rewriting the HDMI resizing code, so that it is all done by PhoneWindowManager since that is what is responsible for the size of the navigation bar (and thus now system bar). This actually gets rid of a fair amount of code, and means we can also do the same thing for a pure navigation bar. Likewise the system bar now has the navigation bar ability to be hidden when requested by system UI flags. To get the behavior we want on Xoom, we only allow the nav bar to be hidden when it will help provide a better aspect ratio for showing widescreen videos. Finally the nav/system bar now animates when hidden and shown. Change-Id: Ie927154b68376a0b61802f99171ff56b8da92e7a
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
61ac6bb250494db602b485491a493b64776eaf3b |
|
03-Feb-2012 |
Craig Mautner <cmautner@google.com> |
Extract code from performLayoutAndPlaceSurfacesInnerLocked() into multiple methods. Change-Id: I80152c38741ce73b92da9483cfed84efbac34f89
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d3fe9abfb9a6a21a18abde6a98dceb423c04ebef |
|
21-Jan-2012 |
Jim Miller <jaggies@google.com> |
am ab9601cd: am 230a7092: Merge "Fix 5863053: Add method to lock screen immediately." into ics-mr1 * commit 'ab9601cdbb95ae94088750eff9a926a572c1a4d6': Fix 5863053: Add method to lock screen immediately.
|
230a709285abc5dfd92f05d91a8997d52a59d3c7 |
|
19-Jan-2012 |
Jim Miller <jaggies@google.com> |
Merge "Fix 5863053: Add method to lock screen immediately." into ics-mr1
|
93c518e4f8abd98f87cda1712b30a5a86cfa60dd |
|
18-Jan-2012 |
Jim Miller <jaggies@google.com> |
Fix 5863053: Add method to lock screen immediately. This fixes a bug where the device fails to lock when DevicePolicyManagerService requests the device to be locked and the screen was off because the user hit the power button. The change allows DPMS to directly invoke screen lock, bypasssing the screen state. Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f88d1493aa968d3da551116f076edd5e21f7ccfc |
|
13-Jan-2012 |
Dianne Hackborn <hackbod@google.com> |
am 10065177: am 2e282f35: Merge "Fix issue #5823276: home repaints after full-screen app is exited" into ics-mr1 * commit '100651779fde99f7ae2a10719d688b51115f08e9': Fix issue #5823276: home repaints after full-screen app is exited
|
01b02a734d2988c22b00f5df6346ad03d8bf52b6 |
|
12-Jan-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5823276: home repaints after full-screen app is exited Don't consider a window as a candidate for the top fullscreen window if it is not going to be a candiate for layout. Also don't consider windows a candidate for layout if their app token is hidden. This fixes a transient state where we are preparing to unhide the window but have not done so yet. Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ee4d45f3052c8d339035c4bb8eca9b7a724e5074 |
|
13-Dec-2011 |
Dianne Hackborn <hackbod@google.com> |
am 0be53567: am 19a06fe9: Merge "Fix issue #5755172: Soft menu key disappears when menu is open" into ics-mr1 * commit '0be53567c1c2299c548d3204d2b9240108fbd53a': Fix issue #5755172: Soft menu key disappears when menu is open
|
73ab6a49db2b834ce1d56c7a1164938b409ee6fc |
|
13-Dec-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5755172: Soft menu key disappears when menu is open We need to work more like before in determining whether the menu key is needed -- in some cases look back in the window list to determine this if we don't know the value from the current window. This requires adding a new private flag indicating whether the compat menu state is known for a window, which is set by PhoneWindow as part of its existing process of computing the flag for its own windows. Now we can have a new API on WindowState to determine the value of this flag for a window, which if needed walks back in the window list to find a window the value is known for (or stops at what the policy has determined is the top full-screen window, so we stop like we used to at things like the lock screen or the bottom of an application). Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
32cbc3855c2a971aa5a801fd339fb6a37db91a1a |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Refactor InputQueue as InputEventReceiver. This change simplifies the code associated with receiving input events from input channels and makes it more robust. It also does a better job of ensuring that input events are properly recycled (sometimes we dropped them on the floor). This change also adds a sequence number to all events, which is handy for determining whether we are looking at the same event or a new one, particularly when events are recycled. Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0c4ccff36930ff4f0292b94ad51e164c9fa060a3 |
|
19-Oct-2011 |
Daniel Sandler <dsandler@android.com> |
Add hasNavigationBar() to the window manager. It is no longer sufficient to check the value of internal.R.bool.config_showNavigationBar to determine if a navigation bar (separate from the status bar) is shown on a device, because the emulator needs to be able to override this value (now possible by setting qemu.hw.mainkeys to "1" or "0", for navbar or no navbar, respectively). This logic is now contained in PhoneWindowManager, and any clients wishing to know whether the system has a software nav bar should consult the new hasNavigationBar() method. Bug: 5404945 Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d5bb82d18cbd95bb9e751d8315b9ed0b69595033 |
|
12-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
DO NOT MERGE. Improve screenshot chord debouncing. Bug: 5011907 Introduce a 150ms delay in handling volume down keys while waiting to see if a power key will follow. Don't trigger the screenshot chord if both volume up and volume down are pressed together. Don't trigger the long-press power menu if volume keys are also pressed. Require the user to press both keys in the chord within the debounce time and continue long-pressing them in order to trigger the screenshot action. Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
df89e65bf0fcc651d20b208c8d8d0b848fb43418 |
|
07-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix how we hide and show the nav bar. The PhoneWindowManager is now responsible for hiding and showing the nav bar. For hiding, it just moves it off the screen (easy way to get a nice slide animation on and off). At the same time, we use a new WM facility to put up a fake input window to capture all touch events. When a touch event is received, we force the system UI to clear the navigation hiding bit so it will be shown again. This removes a bunch of code from the system UI for hiding and showing the nav bar. Also removes the code calling from userActivity() to the system UI, which was bad. (Also no longer using userActivity() fixes bugs around re-showing the nav bar due to key presses and other wrong things.) Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9a230e01a1237749a8a19a5de8d46531b0c8ca6a |
|
06-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately This cleans up how ui flags are managed between the client and window manager. It still reports the global UI mode state to the callback, but we now only clear certain flags when the system goes out of a state (currently this just means the hide nav bar mode), and don't corrupt other flags in the application when the global state changes. Also introduces a sequence number between the app and window manager, to avoid using bad old data coming from the app during these transitions. Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4c253119db0ce753e46ec3809b54b9e357d363db |
|
24-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Prevent unintended rotations. Bug: 4981385"
|
c0347aa19f354a8e1ff4fcd5372b134c0c7c16ad |
|
24-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Prevent unintended rotations. Bug: 4981385 Changed the orientation listener to notify the policy whenever its proposed orientation changes, and changes the window manager to notify the orientation listener when the actual orientation changes. This allows us to better handle the case where the policy has rejected a given proposal at one time (because the current application forced orientation) but might choose to accept the same proposal at another time. It's important that the proposal always be up to date. A proposal becomes irrelevant as soon as the phone posture changes such that we can no longer determine the orientation with confidence (such as when a device is placed flat on a table). Simplified the orientation filtering. Now we just wait 200ms for the device to be still before issuing a proposal. The idea is that if the device is moving around a lot, we assume that the device is being picked up or put down or otherwise in the process of being moved. We don't want to change the rotation until that's all settled down. However, we do want to tolerate a certain amount of environmental noise. (The previous confidence algorithm was also designed along these lines but it was less direct about waiting for things to settle. Instead it simply made orientation changes take longer than usual while unsettled, but the extra delay was often too much or too little. This one should be easier to tune.) Change-Id: I09e6befea1f0994b6b15d424f3182859c0d9a530
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
90c52de28691ca0bbbf7c039ef20f85ce46882cc |
|
23-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5173952: Opening a Notification From Lock Screen... ...Should Skip Unsecure Lockscreen (ICS) Also while I am in there, clean up logging of intent objects to include even less sensitive information, while showing the true Intent in dump output (since apps can't get to that). Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
01a98ddbdfbaf1f0d2bc602537e6e314364902a3 |
|
21-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Handle orientation changes more systematically. Bug: 4981385 Simplify the orientation changing code path in the WindowManager. Instead of the policy calling setRotation() when the sensor determined orientation changes, it calls updateRotation(), which figures everything out. For the most part, the rotation actually passed to setRotation() was more or less ignored and just added confusion, particularly when handling deferred orientation changes. Ensure that 180 degree rotations are disallowed even when the application specifies SCREEN_ORIENTATION_SENSOR_*. These rotations are only enabled when docked upside-down for some reason or when the application specifies SCREEN_ORIENTATION_FULL_SENSOR. Ensure that special modes like HDMI connected, lid switch, dock and rotation lock all cause the sensor to be ignored even when the application asks for sensor-based orientation changes. The sensor is not relevant in these modes because some external factor (or the user) is determining the preferred rotation. Currently, applications can still override the preferred rotation even when there are special modes in play that might say otherwise. We could tweak this so that some special modes trump application choices completely (resulting in a letter-boxed application, perhaps). I tested this sort of tweak (not included in the patch) and it seems to work fine, including transitions between applications with varying orientation. Delete dead code related to animFlags. Handle pausing/resuming orientation changes more precisely. Ensure that a deferred orientation change is performed when a drag completes, even if endDragLw() is not called because the drag was aborted before the drop happened. We pause the orientation change in register() and resume in unregister() because those methods appear to always be called as needed. Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
bc1aa7bbc753ebcd32da4507fa23215489b6d314 |
|
20-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5312624: Lock screen very flickery The key thing was to fix isVisibleOrBehindKeyguardLw() so that it wouldn't count a window as not visible if it was just currently in the process of drawing due to an orientation change. Also improve logic in deciding when to turn screen on to better ensure the screen is in a stable state, in particular treating screen off as a frozen screen and not allowing it to turn on until the update of the screen due to any config change is done. Change-Id: If82199f3773270b2d07f9c7de9da2dad8c7b28d7
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
38e29a61d0c87fe3e391d24e2eb11dd1800d107d |
|
18-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5242779: Device not responding to touch on unlock screen Rework how we decide when it is okay to turn on the screen by having the policy call back to the power manager when it knows the lock screen has been drawn. Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
1f903c3b577d20f7db7e3d5875cafe577d0d845f |
|
14-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5283365: Rotating the device to portrait mode, hides the keyboard partly PhoneWindowManager now takes full responsibility for deciding where the navigation bar goes. This gets rid of a bunch of race conditions with determining layout while the nav bar is moving itself at the same time the window manager is computing a new configuration. Note that this breaks the "nav bar on left" option. The current nav bar code could also be cleaned up some more to completely drive its behavior based on onSizeChanged() happening during relayout. Change-Id: I1651d74c3464ba0d588aab3049e099c78420146a
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ba24e4d8bbeb60e96d74f05e21691dad61ce497e |
|
01-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5229575: Youtube link shared through messaging is not... ...opening after selecting option "Youtube" as a luncher. Also: * Tweak window animations so that the wallpaper exist animations do not stop too early (causing the wallpaper to suddenly disappear). * Make sure no input is being processed while booting, to avoid accidentally doing things especially in the upgrade dialog. * Some other small cleanup. Change-Id: I40a6b53731991d4e31ac4502e3d85f0e47507481
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d040edbae968d826aa2c82d382345811a45c646b |
|
31-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Use floating point window positions. Gets rid of gapps between windows during animations. Change-Id: I17d2ef0af214008f0eabd7eb19268f145fe83b39
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
661cd52e0e1d527132eb1cae604d3e64da7ec0cb |
|
22-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Add progress dialog for booting after an upgrade. This introduces a new facility for code during the boot process to display messages to the user through a progress dialog. This is only for use when performing longer-than-usual post-upgrade operations such as running dexopt on applications or upgrading databases. Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
50469db07167e3a837e10f215baa4eacb1319604 |
|
03-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
am 7322e557: am a4cfcf10: am 75d6b3c2: Merge "Fix issue #4502672: Wrong xml resources used for homescreen widgets." into honeycomb-mr2 * commit '7322e557cfe42da42779625d69ced2db74a9df90': Fix issue #4502672: Wrong xml resources used for homescreen widgets.
|
ed60f81940c5f2125518c7c31ad4f61b8a9baf3e |
|
02-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 76450622 to master Change-Id: I26ccd8f264e65f100d894f43cf597a781552db83
|
2f0b17573d4324832f7a20402a3d2b5920bc4866 |
|
01-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4502672: Wrong xml resources used for homescreen widgets. There was a race in the system process between applying the initial configuration and executing code in higher-level system services like the app widget service that relies on the config. For some reason it starting showing up more after my code changes; it should now be completely fixed. Also fix the activity starting window to run in compatibility mode if its application is going to be in compatibility mode. And some various cleanup and small fixes. Change-Id: I0566933bf1bbb4259c1d99a60c0a3c19af1542e5
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
81e56d535c853d73ff537357da5b935f51cb779d |
|
26-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework how we decide whether to use system or status bar. The PhoneWindowManager is now responsible for determing this, since it needs to do this before we can generate the configuration since we need to take into account the system bar size we will use. Also the Display should now report the screen height without including the system bar. Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
8c1132e3ceed8e1a8c696e2afe0e6fe456ccd7ef |
|
26-May-2011 |
Daniel Sandler <dsandler@android.com> |
Merge "Framework support for Android Dreams."
|
0601eb7953cbf77d92826bef3ca37e208d922de7 |
|
13-Apr-2011 |
Daniel Sandler <dsandler@android.com> |
Framework support for Android Dreams. A Dream is an activity that is launched by the window manager after a specified idle time. You might think of this as a "screen saver", but with the same capacity for interactivity as any other application. The window manager maintains a timer (like the screen lock timer) that is reset on userActivity; the timer is suspended during wakelocks and when the screen is off. When the timer elapses, the user's preferred dream module is launched (by reading Settings.Secure.DREAM_COMPONENT, which is configured through the Settings app UI). Like a dock app, the user can install new dreams and a single application package may contain multiple dream activities. Unlike the dock mode, however, there is no "screensaver mode" for the system to manage. This allows us to offer the user the ability to run a dream at any time, in addition to making the overall mechanism quite simple. There is no public API for this facility. There is, however, a useful/recommended base class for dream activities in the support library (change I4559a958). Change-Id: Ied691856f88cfa38a7aca496d015f9a595da72f2
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
161e67ff3ba26408eea09221734ad2e29a1eed11 |
|
20-May-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 06a8ceac to master Change-Id: Id51574c825affddfac14ad7214c5496d6a3d6e69
|
69cb87576ba163b61bb0e6477a3b7c57a9b11d40 |
|
20-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Add new "-swNNNdp" resource qualifier. Change-Id: I0101e88ca9d8d44138bdcaf571f24b0352f4f6ce
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
68066c2f38e47b56f0510c56eafd827731a0dc08 |
|
22-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE. From main -- Start work on simulating landscape/portrait when orientation is locked. Not yet working, so turned off. Also fix a bug where the display size configuration became inconsistent after a configuration change -- we now figure out everything about the display size when computing a new configuration. Change-Id: Id155f133c0bf108508a225ef64ed3ca398a90a58
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
29735689cea7bf52998c1911542dcfdd1c1d9628 |
|
22-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE: From master -- Fix bug in deciding which rotation to use for an orientation. Change-Id: Ie271123271a662f3f753f381ce4c43ad7904dc4a
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
aa9d84c37e05f696ec158dac98ce38cf41e18314 |
|
10-May-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 05be6d6f to master Change-Id: Ic6a6c5bb300f6f1d43f9ed550b284282b4f16212
|
e2515eebf42c763c0a2d9f873a153711778cfc17 |
|
28-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
dacea8ce503369e7b82ff1c0e1a5a8a48863a25a |
|
22-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Start work on simulating landscape/portrait when orientation is locked. Not yet working, so turned off. Also fix a bug where the display size configuration became inconsistent after a configuration change -- we now figure out everything about the display size when computing a new configuration.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9d13264f6b5818812e61d66baaada599b8ad1faf |
|
22-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix bug in deciding which rotation to use for an orientation. Change-Id: Icc928c2188a5865035cafcdab2efd5bae3132b1f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0029c66203ab9ded4342976bf7a17bb63af8c44a |
|
30-Mar-2011 |
Jeff Brown <jeffbrown@google.com> |
Add input filter mechanism for accessibility. This patch adds a mechanism for capturing, filtering, transforming and injecting input events at a very low level before the input dispatcher attempts to deliver them to applications. At this time, the mechanism is only intended to be used by the accessibility system to implement built-in system-level accessibility affordances. The accessibility input filter is currently just a stub. It logs the input events receives and reinjects them unchanged, except that it transforms KEYCODE_Q into KEYCODE_Z. Currently, the accessibility input filter is installed whenever accessibility is enabled. We'll probably want to change that so it only enables the input filter when a screen reader is installed and we want touch exploration. Change-Id: I35764fdf75522b69d09ebd78c9766eb7593c1afe
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
56194ebec6212e229f4ccdaa4b187166d20013ef |
|
03-Mar-2011 |
Jeff Brown <jeffbrown@google.com> |
Wake screen from external HID peripherals. Added some plumbing to enable the policy to intercept motion events when the screen is off to handle wakeup if needed. Added a basic concept of an external device to limit the scope of the wakeup policy to external devices only. The wakeup policy for internal devices should be based on explicit rules such as policy flags in key layout files. Moved isTouchEvent to native. Ensure the dispatcher sends the right event type to userActivity for non-touch pointer events like HOVER_MOVE and SCROLL. Bug: 3193114 Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
520d8bc1d840966b5519195aaa514597a662c053 |
|
18-Feb-2011 |
Mike Lockwood <lockwood@android.com> |
KeyguardManager: Add isKeyguardLocked() and isKeyguardSecure() BUG: 3402847 Change-Id: I725838c9d96617dd4497f9c80417cd623eceb846 Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
664644d9e012aa2a28ac96f305b1ce6499ec8806 |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
visibility ("lights out") API. 1. Views may setSystemUiVisibility() to recommend that the system chrome (status bar or other UI) show or hide itself. (This functionality was previously available only via the FLAG_FULLSCREEN window flag for some SystemUI implementations.) 2. Views may register a OnSystemUiVisibilityChangedListener on a view, and find out when the system UI actually appears or disappears, allowing apps to coordinate the appearance of their own UI if desired. Bug: 3241144 Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f99f9c5f92dbcdf5f6e9c93847a5dae4c35a817e |
|
13-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3153930: orphan window left on screen The problem is that if a window containing children is removed before the children are, the children may be lost. This change (amongst the huge amount of new debugging code) now ensures at this point that all children windows are removed when the parent is. Note that this results in a bunch of error messages now as the client app tries to continue to do things with that child window. This is correct, it shouldn't be doing that, and needs to be fixed to stop it. But at least it now can't cause the window manager to leak surfaces. Change-Id: I7b80dd89ff9de7cb5af1dc759cfa4b31ac29cddc
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ad7fa7fa77318d416ed338ede6aae582c239f822 |
|
07-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
WM part of #3293405: Screen needs to be redrawn when HDMI is plugged in Change-Id: If5ceb28073c6abf14165871bd99cb481b31a863b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
49ed71db425c5054e3ad9526496a7e116c89556b |
|
07-Dec-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for fallback keycodes. This change enables the framework to synthesize key events to implement default behavior when an application does not handle a key. For example, this change enables numeric keypad keys to perform their associated special function when numlock is off. The application is informed that it is processing a fallback keypress so it can choose to ignore it. Added a new keycode for switching applications. Added ALT key deadkeys. New default key mappings: - ESC -> BACK - Meta+ESC -> HOME - Alt+ESC -> MENU - Meta+Space -> SEARCH - Meta+Tab -> APP_SWITCH Fixed some comments. Fixed some tests. Change-Id: Id7f3b6645f3a350275e624547822f72652f3defe
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
1f2451007c660091b7b090c1ea332f9044515d2d |
|
19-Nov-2010 |
Jeff Brown <jeffbrown@google.com> |
Ensure the ShortcutManager uses the correct key character map. The ShortcutManager used to only receive the key code of the key event that triggered the shortcut. This change now provides the shortcut manager with the whole key event so it can look up the associated character using the correct key character map. To make this more efficient, added a mechanism for recycling key events. At the moment it is only used by key events owned by the system process, since clients of the existing API (such as Views) might continue to hold on to key events after dispatch has finished so they would break if the key event were recycled by the framework. Deprecated KeyCharacterMap.BUILT_IN_KEYBOARD. Change-Id: I4313725dd63f2be01c350c005a41c7fde9bc67e8
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
7eec10e6c99c30d5ee061fec08ac89ad4254ac32 |
|
13-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Get rid of the extended themes. We now decide whether to use a bitmap background based on whether the window's drawing is hardware accelerated. To do this, there is a new "state_accelerated" that state list drawables can be parameterized on, and the standard window background uses this to select a solid color or bitmap drawable as appropriate. Introduces a little hackery to have wm preview windows pretend like they are hardware accelerated even if they aren't, so the preview looks closer to the actual app. Also Add a DialogWhenLarge variation for the light theme. Change-Id: I215a79d5df65ba3eed52ab363cade9d8218a6588
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3915bb845b032dc184dba5e60970b803390ca3ed |
|
05-Nov-2010 |
Jeff Brown <jeffbrown@google.com> |
Tell system server whether the app handled input events. Refactored ViewRoot, NativeActivity and related classes to tell the dispatcher whether an input event was actually handled by the application. This will be used to move more of the global default key processing into the system server instead of the application. Change-Id: If06b98b6f45c543e5ac5b1eae2b3baf9371fba28
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
b73617de462579f7c12c25a4c2747c576f00f6a2 |
|
17-Aug-2010 |
Daniel Sandler <dsandler@google.com> |
Rotation lock. IWindowManager now supports two new methods, freezeRotation() and thawRotation(), that allow a caller to temporarily stash the device's current rotation as the default rotation (when no other constraints are present). The system bar uses this to implement a user-accessible rotation lock by calling freezeRotation() and then turning off accelerometer-based display rotation; unless overridden by an app, the display will continue to appear in the frozen rotation until the rotation is unlocked by the user (either via the rotation lock icon in the system bar or by checking "rotate screen automatically" in Settings). Bug: 2949639 Change-Id: Icd21c169d1053719590e72401f229424b254622f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
4d396052deb54399cbadbeb8abd873df6f3af342 |
|
30-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Fix policy issues when screen is off. Rewrote interceptKeyBeforeQueueing to make the handling more systematic. Behavior should be identical except: - We never pass keys to applications when the screen is off and the keyguard is not showing (the proximity sensor turned off the screen). Previously we passed all non-wake keys through in this case which caused a bug on Crespo where the screen would come back on if a soft key was held at the time of power off because the resulting key up event would sneak in just before the keyguard was shown. It would then be passed through to the dispatcher which would poke user activity and wake up the screen. - We propagate the key flags when broadcasting media keys which ensures that recipients can tell when the key is canceled. - We ignore endcall or power if canceled (shouldn't happen anyways). Changed the input dispatcher to not poke user activity for canceled events since they are synthetic and should not wake the device. Changed the lock screen so that it does not poke the wake lock when the grab handle is released. This fixes a bug where the screen would come back on immediately if the power went off while the user was holding one of the grab handles because the sliding tab would receive an up event after screen turned off and release the grab handles. Fixed a couple of issues where media keys were being handled inconsistently or not at all, particularly in the case of the new PAUSE, PLAY and RECORD keys. Bug: 3144874 Change-Id: Ie630f5fb6f128cfdf94845f9428067045f42892c
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
e20c9e0264190f94324197a8271cf03811a4ca58 |
|
11-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Fix an event injection bug when the policy is bypassed. Added the concept of a "trusted" event to distinguish between events from attached input devices or trusted injectors vs. other applications. This change enables us to move certain policy decisions out of the dispatcher and into the policy itself where they can be handled more systematically. Cherry pick of b931a1b4 from gingerbread into master. Change-Id: I700a5f07b8b227878cea9437a289a45a245c0424
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
b699726018a0049665d8ad6b90dbc5af0e18f135 |
|
09-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Added more robust tracking and cancelation of events. This change fixes several issues where events would be dropped in the input dispatch pipeline in such a way that the dispatcher could not accurately track the state of the input device. Given more robust tracking, we can now also provide robust cancelation of input events in cases where an application might otherwise become out of sync with the event stream due to ANR, app switch, policy decisions, or forced focus transitions. Pruned some of the input dispatcher log output. Moved the responsibility for calling intercept*BeforeQueueing into the input dispatcher instead of the input reader and added support for early interception of injected events for events coming from trusted sources. This enables behaviors like injection of media keys while the screen is off, haptic feedback of injected virtual keys, so injected events become more "first class" in a way. Change-Id: Iec6ff1dd21e5f3c7feb80ea4feb5382bd090dbd9
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
0eaf3931a31c29f3a3883aab426b595c231c2a58 |
|
01-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Support haptic feedback for virtual keys defined in key layout. Change-Id: I83e4108a87332692e03791dc066206becbc7941f
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
fd57416cc8c2a333f46cacad6de48a3b1547eac9 |
|
01-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix build. Change-Id: I99d362e6673252ade4da29f29852eccaedbc9709
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
85a3176704b5bfbeece9bd928369fbb76eec7dc6 |
|
02-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
a41ca77fabe1c7ad12ebb9b69b9e786c07d49fa0 |
|
11-Aug-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for the PointerLocation overlay. This change involves adding a new method to IWindowManager, monitorInput() that returns an InputChannel to receive a copy of all input that is dispatched to applications. The caller must have the READ_INPUT_STATE permission to make this request (similar to other window manager methods such as getKeycodeState). Change-Id: Icd14d810174a5b2928671ef16de73af88302aea0
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
00fa7bdd69f0868fd17ea7c881c771d785b2fbbd |
|
03-Jul-2010 |
Jeff Brown <jeffbrown@google.com> |
More native input dispatch work. Removed old input dispatch code. Refactored the policy callbacks. Pushed a tiny bit of the power manager state down to native. Fixed long press on MENU. Made the virtual key detection and cancelation a bit more precise. Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
349703effce5acc53ed96f7ed8556131f0c65e18 |
|
22-Jun-2010 |
Jeff Brown <jeffbrown@google.com> |
Native input event dispatching. Target identification is now fully native. Fixed a couple of minor issues related to input injection. Native input enabled by default, can be disabled by setting WindowManagerPolicy.ENABLE_NATIVE_INPUT_DISPATCH to false. Change-Id: I7edf66ed3e987cc9306ad4743ac57a116af452ff
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
46b9ac0ae2162309774a7478cd9d4e578747bfc2 |
|
23-Apr-2010 |
Jeff Brown <jeffbrown@google.com> |
Native input dispatch rewrite work in progress. The old dispatch mechanism has been left in place and continues to be used by default for now. To enable native input dispatch, edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy. Includes part of the new input event NDK API. Some details TBD. To wire up input dispatch, as the ViewRoot adds a window to the window session it receives an InputChannel object as an output argument. The InputChannel encapsulates the file descriptors for a shared memory region and two pipe end-points. The ViewRoot then provides the InputChannel to the InputQueue. Behind the scenes, InputQueue simply attaches handlers to the native PollLoop object that underlies the MessageQueue. This way MessageQueue doesn't need to know anything about input dispatch per-se, it just exposes (in native code) a PollLoop that other components can use to monitor file descriptor state changes. There can be zero or more targets for any given input event. Each input target is specified by its input channel and some parameters including flags, an X/Y coordinate offset, and the dispatch timeout. An input target can request either synchronous dispatch (for foreground apps) or asynchronous dispatch (fire-and-forget for wallpapers and "outside" targets). Currently, finding the appropriate input targets for an event requires a call back into the WindowManagerServer from native code. In the future this will be refactored to avoid most of these callbacks except as required to handle pending focus transitions. End-to-end event dispatch mostly works! To do: event injection, rate limiting, ANRs, testing, optimization, etc. Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
b8b11a0b1d82e24f7a79f2e1672e7f5cf1611a55 |
|
11-Mar-2010 |
Dianne Hackborn <hackbod@google.com> |
Further improvements to window management! Fix issue #2493497: Stuck in the Emergency dialer - Home/Back keys doesn't work This was another case of not updating the window focus when needed, this time when the lock screen was hidden. Also re-arrange the layout/animate flow to address issues where you would see a flicker of whatever was behind the lock screen when showing a new activity that hides the lock screen. This was because we were deciding to hide the lock screen during the layout phase, which meant we had to do it without considering whether it had drawn. So we could hide the lock screen before the window is shown for the first time after being drawn. Now we can do this in the policy during animate, so we can wait until the window is drawn and actually being shown. The flow in perform layout is thus significantly changed, where the layout and animate loops are both under the same repeating loop. The actual flow from this should be the same, but it now allows the policy to request a new layout after the animation loop is done. This actually cleans up a number of things in this code as the complexity has increased. Finally this includes a change to the ui mode manager when switching modes, to do the resource configuration switch at a different time. This makes transitions between modes much cleaner (though not yet perfect). Change-Id: I5d9e75c1e79df1106108dd522f8ffed6058ef82b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
90d2db3d21d07c2a4b4cbbc558f5ec59d20098c3 |
|
12-Feb-2010 |
Dianne Hackborn <hackbod@google.com> |
Add Pointer Location to the window manager. The window manager now has pointer location built into it. Viva la touch!
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ef73162887943e16587b8e737b19e59348338e8c |
|
27-Jan-2010 |
Mike Lockwood <lockwood@android.com> |
Support for triggering the lockscreen while the screen is on: Add new ALLOW_LOCK_WHILE_SCREEN_ON window manager flag, which when set causes the window manager to put up the lockscreen after the normal screen timeout has elapsed. Add plumbing to pass PowerManager.userActivity() to the window manager policy. Change-Id: I05adc52bad39c56031a08e8ec3cbcf5c2d9b9827 Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
254cb446faa7cb13699d8150eb4cc4f44cb61a2d |
|
28-Jan-2010 |
Dianne Hackborn <hackbod@google.com> |
More device admin. - Clean up device policy manager APIs. - Implement lockNow(). For now this just turns the screen off to lock the device.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
de2606dcd36e9dfa49c42dbc68c539505d5ff8d4 |
|
19-Dec-2009 |
Dianne Hackborn <hackbod@google.com> |
Don't perform app transition of the app is not currently visible. Yet more special casing for the window manager... try really hard, if we are performing an activity transition that is behind an opaque window (like say the lock screen or status bar) to just not do it. And, just as important, do a reasonable transition away from whatever is on top. Examples: - If the lock screen is up, and you get a call or press the emergency dialer button, we fade from the lock screen to the new UI, instead of fading to the animation going on between the old and new. - If you are in something hiding the lock screen, like the in-call screen, and that is hidden, then fade back to the lock screen. - If you select an item from the status bar, then have the new item displayed behind it as the status bar rolls up rather than seeing a second animation. (In fact this can't always be done because we may not start the transition to the new thing until the status bar is already going away. But for most cases we can do this with just one anim.)
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
44000eb2a2340b1a47eaa587d4829810e04cbcdc |
|
03-Dec-2009 |
Mike Lockwood <lockwood@android.com> |
am 678c2e35: Merge change I9ef88863 into eclair Merge commit '678c2e35768a5426b4ad8f67c836008e7751a353' into eclair-mr2 * commit '678c2e35768a5426b4ad8f67c836008e7751a353': Add WindowManagerPolicy.OFF_BECAUSE_OF_PROX_SENSOR to indicate screen was turned off by the proximity sensor.
|
435eb6464c1f326caf8179438a5401f358f0d7ac |
|
03-Dec-2009 |
Mike Lockwood <lockwood@android.com> |
Add WindowManagerPolicy.OFF_BECAUSE_OF_PROX_SENSOR to indicate screen was turned off by the proximity sensor. Part of a fix for bug b/2300622 (Proximity sensor always blows up the lock screen while in call) Change-Id: I9ef888638b19540a78a34507d52ff522f505102f Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
db727a8a0384ba2ac4dcb4bf93e1dd54e3062b28 |
|
29-Nov-2009 |
Mike Lockwood <lockwood@android.com> |
Remove some unused window manager methods. Change-Id: I1c28150416b92b96b9f434270652c4be2613434c Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3d0ea72dd74bb0a7ad082a82dbf53df11a4f487c |
|
22-Oct-2009 |
Mike Lockwood <lockwood@android.com> |
Add WindowManagerPolicy.allowKeyRepeat() method for disabling key repeats. Part of a fix for bug b/2198537 Change-Id: I99dc64772fa7644b12432d5549603025196ea3e2 Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3d163f073f5cf3b3bf0287fc7d60fabce0269748 |
|
08-Oct-2009 |
Dianne Hackborn <hackbod@google.com> |
More fix #2163209: alarm clock rings but is hidden behind lock screen There was another way we could ignore the application windows flags while the lock screen was displayed. This is the infrastructure to deal with that. Change-Id: Id8c9cb2f7081df6757ccb797a7cde618e82f7b38
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
6af0d50a8edb101d9da1306b6d85abf5dd3f9a30 |
|
28-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2149145: Safe Mode does not work on Sholes device The APIs for checking whether keys are held down now also look at virtual keys. However it turns out there is less than a second between the time we start the input thread and check for safe mode, so there is not enough time to actually open all of the devices and get the data from them about the finger being down to determine if a virtual key is down. So now you can also hold DPAD center, trackball center, or s to enter safe mode. Also give some vibrator feedback. Change-Id: I55edce63bc0c375813bd3751766b8070beeb0153
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
3b3e145d3c41fd68974e08f799b1fd1f8f060cf0 |
|
25-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
A variety of work on animations. - The lock screen now fades in and out. - Fixed a bug where we would accidentally freeze the screen when switching to an activity with a different orientation than the current (but the screen itself is in the current orientation). This would mess up the animations on the car dock. - New API to force a particular animation for an activity transition (untested). - New wallpaper animations. - Resources now uses the next API version when in a development build, to help applications being developed against such builds. Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9bfb707597898f54722460b48588007b682f3e2a |
|
22-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Various fixes and improvements to window, activity. - New meta-data you can add to a dock activity to have it launched by the home key when the device is in that dock. - Fix a deadlock involving ActivityThread's internal content provider lock. - New window flag to have a non-secure keyguard entirely dismissed when a window is displayed. - New WindowManagerPolicy APIs to allow the policy to tell the system when a change it makes during layout may cause the wall paper or overall configuration to change. - Fix a bug where an application token removed while one of its windows is animating could cause the animating window to get stuck on screen. Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
bfe319e06aa56c081d0d94d64a8181291d7f7388 |
|
21-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Turn animations on by default. Add API to skip the animation for a particular start activity, so that a latter better one can be used. Fix Theme.NoDisplay to actually work. Fiddle with various animations: don't do a different animation for task switching, try a scale animation for switching in/out of the wallpaper. Adjust the animation duration so that at normal speed we have something more like the slower animation option (so slow is now the default). Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
6136b7ef169a65a02a6660be636fcec370c68145 |
|
18-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Show the live wallpaper on the lock screen. This also takes care of the problem of system dialogs like the crash dialog causing the status bar to dim behind the lock screen. On the down side, the fade transition from the lock screen is now gone, and I'm not sure how likely it is for it to return. Change-Id: I7f9e6d0f3510a1fdbbe6ad252d986bd85a16475d
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c17f07aa0468424e3475d7761313b761372d1860 |
|
17-Sep-2009 |
Mike Lockwood <lockwood@android.com> |
Revert "Don't activate keyguard if screen is turned off while proximity sensor is active." This reverts commit ddfe879b783ad72603308e28e8f683454464684e.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
25994b4306a256b88d79159106834c9f114e6943 |
|
04-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Wallpapers: new transitions, hiding when not visible, other cleanup. This is work on the transitions with wallpapers. There are now new animations specifically for leaving the wallpaper and returning to it, which allow us to have a consistent animation when entering home and returning to it. I also renamed the existing animations across wallpapers, and cleaned up some junk in the various interpolators. This also now hides the wallpaper surface when it is not visible, to get rid of the wallpaper flickers people complained about albeit in a somewhat brutal way. :) (Though really returning us to the previous behavior with the same previous bugs and name back to them not being very visible, yay!) There is are also some bug fixes here and there about managing the wallpaper visibility that this change revealed. Change-Id: I913990a9a81651728122ed2e1101b75ed2c36fcb
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ddfe879b783ad72603308e28e8f683454464684e |
|
27-Aug-2009 |
Mike Lockwood <lockwood@android.com> |
Don't activate keyguard if screen is turned off while proximity sensor is active. Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f8fbdb6b920562473dc47046924ac8ffed0b8daf |
|
19-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Add wallpaper transition animations. The window manager now detects when a transition between two wallpaper activities is happening, and switches to a new set of animations for that. The animations I defined here are just an arbitrary something that can work in this case.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
ddca3ee3e86fbaa05c1528bd72afd955f0fb4ee6 |
|
24-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Add support for power keys, improve behavior of virtual keys. The platform now knows how to deal with a platform key, which at this point is "just like end call, but don't end a call." Also improve the handling of virtual keys, to allow for canceling when sliding off into the display and providing haptic feedback. Finally fixes a bug where the raw x and y in motion event were not always set which caused the status bar to not work.
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
7ac3f67c179ec77caeee59b86d87d4ec007c4586 |
|
01-Apr-2009 |
Dianne Hackborn <> |
AI 143901: am: CL 143899 am: CL 143896 Fix issue #1748954 and #1737952: #1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway. #1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar: - We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed. - When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct. Original author: hackbod Merged from: //branches/cupcake/... Original author: android-build Merged from: //branches/donutburger/... Automated import of CL 143901
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
c39a6e0c51e182338deb8b63d07933b585134929 |
|
11-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@137873
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
15ab3eae2ec3d73b3e8aa60b33ae41445bf83f4b |
|
20-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@132569
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
da996f390e17e16f2dfa60e972e7ebc4f868f37e |
|
13-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@131421
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f1e484acb594a726fb57ad0ae4cfe902c7f35858 |
|
22-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@127436
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/WindowManagerPolicy.java
|