9c5bf3b36f3dd658320f34dbaee9d6d453606bf4 |
|
23-Jun-2012 |
Craig Mautner <cmautner@google.com> |
Don't display based on a dummy animation. The Starting window was being made visible early because the app token had the dummy animation set. When the real animation started the Starting window picked it up and became transparent causing the underlying window to become visible again => jank. Fixes bug 6691421. Change-Id: I95fe88d2887760e6da3adedeb6be300eb6755283
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
f41209568617f4acfaf6dea8f8b2cbe9c2994a3e |
|
22-Jun-2012 |
Craig Mautner <cmautner@google.com> |
Fix starting window problems. Three problems fixed: 1. When one Activity took over for another Activity not all of the starting window state was being copied over. Now copying over more parameters. 2. When the visibility of an Activity was being changed the dummy animation was overwriting the existing animation. If that animation was the starting window animating then it started over when the dummy animation was assigned. Now the dummy animation no longer replaces an existing starting window animation. 3. The test for whether to animate away the starting window only looked to see if the Activity had already drawn a window but did not include the starting window. This caused the starting window to immediately be hidden when the Activity was removed if no windows were drawn, thereby exposing the fading window behind. Now the starting window is included in the hasAppShownWindows test and is animated away if it is exposed. Fixes bug 6691421. Change-Id: I4d32a1546c201652574a44d9e7f2752f1f1eb5a6
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
6e2281d44c9b71a03a50ed24d654927111cd2b72 |
|
20-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6686339: 2 taps required to launch notification... ...or settings from lock screen When a window is drawn, the code to determine whether it should now be shown was calling WindowState.isReadyForDisplay(). Part of the condition of this function is that it is not ready if a policy is forcing the window to be hidden -- which is the case when the lock screen is shown. As a result, we wouldn't show the window at that point, so wouldn't tell the activity manager that the token's windows are visibible, and wouldn't tell the lock screen to go away. This adds a new variation WindowState.isReadyForDisplayIgnoringKeyguard(), which is the same as the original method but ignores the policy visibility for app windows. This allows windows to be go through the complete path of handling when the window is finally drawn and telling the activity manager about it, even if behind the lock screen. By making it a separate function, we don't impact any other code that is calling the old function and may be relying on its behavior. Also cleaned up a little of the dumpsys output. Most important, the new ANR section is now moved to the top, since we want "adb shell dumpsys window" to still give a nice summary of what we normally care about -- the window stack and important global state. Change-Id: Ica3ea85ce46f3f5f5cd2cc30fbd9de13d3885a57
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
67e6070fa10bbd313c8ebe0de4e0440b688c569e |
|
24-May-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Change method of tracking moving AppWindowTokens." into jb-dev
|
ef25d7a01910d5547b60c9cc52d4fa4a9e40b6fa |
|
16-May-2012 |
Craig Mautner <cmautner@google.com> |
Change method of tracking moving AppWindowTokens. Stop trying to keep track of the AppTokens that have been moved to the top and bottom and then try and match the WindowStates when transitions are goodToGo. Instead rebuild the WindowState order based on the AppToken order when we are goodToGo. When moving AppWindowTokens lower in mAppTokens create a new ArrayList of AppWindowTokens to keep track of the apps in Z order while animating. Fixes bug 6481078. Change-Id: I29b33a507b45752f15feb10a9f4b47a3f5eb9f0e
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
bf08af3323117e15a65b74e66b7499d31537f9e1 |
|
17-May-2012 |
Craig Mautner <cmautner@google.com> |
Eliminate deferred surface destruction. Removing the code that delays a surface destruction when WindowManager.FLAG_KEEP_SURFACE_WHILE_ANIMATING is set. The lock screen that continued to animate after destroySurfaceLocked is no longer used and this code was causing problems. Also mDrawState was being set to NO_SURFACE in destroySurfaceLocked even if the surface ended up not being destroyed. Later when it was reused the false value of mDrawState was messing things up. The screen lock bug referenced below no longer levaes the user stuck with a black lockscreen. However it occasionally powers back up in the launcher screen rather than the lock screen. Fixes bug 6485955. Change-Id: I684104c7e7c39c161a5118aa890889fbae92e635
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
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/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
e9bdb31ea1dc3c1c2b1833a4bf0031d85928a45b |
|
06-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Refactor input system into its own service."
|
4532e6158474a263d9d26c2b42240bcf7ce9b172 |
|
05-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor input system into its own service. Extracted the input system from the window manager service into a new input manager service. This will make it easier to offer new input-related features to applications. Cleaned up the input manager service JNI layer somewhat to get rid of all of the unnecessary checks for whether the input manager had been initialized. Simplified the callback layer as well. Change-Id: I3175d01307aed1420780d3c093d2694b41edf66e
/frameworks/base/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
594316361d38d88b53c85bd5c8d58a92345e8187 |
|
04-Apr-2012 |
Craig Mautner <cmautner@google.com> |
First separation of animation from AppWindowToken. New class AppWindowAnimator pulls animation out of AppWindowToken. Change-Id: Ic1ccb6ec2bf091f1f901fe3c20cbeb242376ae6b
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
d09cc4ba247e896cc95a57ed7a3247b55b1b68fc |
|
04-Apr-2012 |
Craig Mautner <cmautner@google.com> |
Move more items between layout and animate sides. - Isolate DimAnimator animation from the layout side. - Isolate mWallpaperForceHidingChanged and mOrientationChangeComplete from the animation side. - Eliminate a redundant setting of mOrientationChangeComplete to true. It was already true at that point. - Synchronize changes to mWindows and mAppTokens on mAnimator. This is a nop until we go to multiple threads. - Synchronize AppWindowToken.freezingScreen on mAnimator. - Modification to repeat layout debugging including temporary enabling of spew on layout repeats. Change-Id: Ic8d82b1c197144aaf6957caa5f71e175288220f2
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
749a7bb28b2aff7a77a8c7dce01e086c2bd82c6b |
|
02-Apr-2012 |
Craig Mautner <cmautner@google.com> |
Refactor to convert four state booleans to int. Replace four booleans (mDrawPending, mCommitDrawPending, mReadyToShow and mHasDrawn) with a single int that can take on the four states. Move mLastHidden from WindowState to WindowStateAnimator. Change-Id: Ieff319dfa19123bf5a6cdc98e9ab28fd432b8153
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
c8bc97e53044cd62c0e023fdc441fd13127d0283 |
|
02-Apr-2012 |
Craig Mautner <cmautner@google.com> |
Further isolate the Surface from WindowState. Replace references to mWinAnimator.mSurface with new member mHasSurface. Clean up odd looping structures. Simplify logging. Change-Id: I9cc52a657044220d7b92528928b11bb18a724aef
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
a608b882327fbb393bde3854953cd322a6fea675 |
|
30-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Move variables into animation class. Moved drawPending and commitDrawPending and associated methods from WindowState to WindowStateAnimator. Created mechanism for passing results from WindowAnimator to WindowManagerService. Initial results passed are mUpdateRotation and mWallpaperMayChange. Change-Id: Ib03d28f921580ac9426ea9233bea6eafc9ea964c
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
d87946ba48b62a6a83fd971ef7c4c419407db836 |
|
30-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Remove obsolete variable masking valid one. The mUpdateRotation variable was still in the WindowManagerService mInnerFields object. This was masking the true mUpdateRotation found in WindowAnimator. Fixes Bug 6240025. Change-Id: I6531002f870f30d22e19ba9af5cac86e1c7b9bcb
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
c2f9be0b7fe14258e01d73f6bc43dd94c3e711d4 |
|
28-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Move Surface operations out of WindowState. Migrated the bulk of Surface operations from WindowState to WindowStateAnimator. There remain a multitude of cross-referencing between the two classes and most of the other classes in the wm package. Change-Id: I4bfdfb84be31341371f3ef311aca8fc6a4966692
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
e7ae2505405cf30d9d3140278d5b9a2604d866df |
|
27-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Move wallpaper animations int WindowAnimator. More refactoring. This time wallpaper animations were broken up from WindowManagerService and the layout piece kept there while the animation piece was moved into WindwoAnimator. Also, applyAnimationLocked and applyEnterAnimationLocked were moved from WindowManagerService to WindowState. Change-Id: I05935023702ce05fdfdc804342ec14f719cdfea4
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
a2c77053b8dfa5f06bdd927bdbab4df2d00bb4e2 |
|
26-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Refactor animation out of WindowState. Remove the animation stepping from WindowState and move it into a new class, WindowStateAnimator. Update all references to moved variables in related files. Change-Id: I7540d8f897b370c73975f3ffe450140861cb0cd1
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
cf8cbbe77447d9cca28e789c5ec4e714694ab37d |
|
26-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Skip layout if performShow fails. In cases where a Surface does not go from hidden to shown, do not set the perform layout flag. This keeps us out of repeated passes through the layout code. Fixes bug 6222487. Change-Id: I22601bef5733d2f996a8cbdd50d6b89517bc3122
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
764983d16925daeeba3f29fd1f844187655d1386 |
|
22-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Separate animation into separate class. Introduction of the class WindowAnimator which takes care of all animations stepping and Surface operations. Change-Id: I78f1c269fa57df0616c08adbe156e3059709ae48
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
2fb98b147b58210604dfaf1482f635ce8d8a0575 |
|
21-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Minor refactoring prior to major refactoring. Removal of blur layer. Deferral of Surface actions in BlackFrame from ctor to first use. Combine common test into single method okToDisplay(). Remove redundant logic in DimAnimator. Change-Id: I43af0415794a8f142803ce94d7e17539aafac67d
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
22ce1414a0073b5cddadf1da8475f6fb7b409e44 |
|
20-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Fix flickering when starting and ending apps. Surfaces were displaying animations in their entirety for a single frame before the animation kicked in. This caused a flash on the screen. By setting the animation to invisible (alpha=0) at their start it makes no difference if they are displayed. Fixed bug 6176540. Removed redundant mDimAnimator.show call. Change-Id: I47c1b0d38273b011d9115822a8476671d6a050fc
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
1dd3ed09e8623574ef21fd48354eaa46d1edd9ee |
|
16-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Perform finish animation actions. When stepAnimation returns false, do not return false immediately. Instead carry out finish actions. Also, remove state machine that is no longer necessary. Fixes bug 6184070. Change-Id: I530eb2b62b864bbce929f573d10b31b102152f1f
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
bf90eaa5d2410bfb60ef84a0efcf3b5eb5022d9f |
|
15-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Separate layout ops from surface ops. Further work to isolate layout from animation and surface operations. Remove cruft and minor refactoring. Change-Id: I6f910ed72c7c614996641c353870c2b2ab5e8bb4
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
e32c30784191a9244a08450759471c934c85034c |
|
12-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Separate out animations from layout. (Dianne) pulled the animation steps out of the layout. Changes to exposed layers cause repeated calls to layout code. Combined animation steps into start and finish animation code. Change-Id: I3602d1d6249d20987d102a54e3a67a7a39361b55
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
1743b64d87cee56e51dedbe4ad60fa2acc28af9c |
|
13-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Dejank: also animate window moves due to requested size changes. This performance an animation when, for example, a dialog window is moved because the size of its content has changed. Change-Id: I2d79a1a57f94e0f2f8ef706a473fca6c9cc637cf
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
ad3a9bb628e912b39e10f8d8a8bde0badefd8bd0 |
|
09-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Fix state machine sequence causing wallpaper flash. Fixes bug 6127355. Change-Id: Ie6894329829f78b3ff8936cfe5ed2933490db5d8
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
dbb7991b4e4638b284814b50e79cacc1e1c9d8cd |
|
02-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Separate animation steps into start, step and finish phases. Fixes bug 6089126. Change-Id: Iafbde36ff719640335a7ecf762e1d991cf7915e4
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
343511c9ec6a7a1d3760f784824a64e732f3b7a2 |
|
29-Feb-2012 |
Craig Mautner <cmautner@google.com> |
Detect animation completions like we used to. Previous approximations weren't indicating completion and windows weren't being layered correctly as a result. Change-Id: I08fcd278485bb87dc10bca257b9f8073108753f3
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
83eaab5b43e479c85dc112a1f9b3e53e907bae1f |
|
28-Feb-2012 |
Craig Mautner <cmautner@google.com> |
Fix bug introduced when moving animation step out from between assignments to wasAnimating and nowAnimating. Now wasAnimating once again contains the animation state prior to the animation step. Change-Id: I2b53bd3f62228183233ab36f0ebe44c0344d2351
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
2f995a7eaa1aba2c038c698039ed6837dfe7e51e |
|
21-Feb-2012 |
Craig Mautner <cmautner@google.com> |
- Consolidate all animations in a single place outside of layout loop. - Move mPolicy.startAnimationLw and mPolicy.finishAnimationLw into same method as mPolicy.animatingWindowLw. - Fix first parameter of performLayoutLockedInner(initial, ...) to pass true on initial pass. Change-Id: If1b47bb8a7e03cf427769c657e371abc0910b3e3
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
4a06c8008b2edd6677f9a411af79b0a4971b87fe |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Simplify Choreographer API. Removed the listeners and schedule animation / draw methods. Instead all requests are posted as one-shot callbacks, which is a better match for how clients actually use the Choreographer. Bug: 5721047 Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
8bcd54b98ad5d98d47364ff14e06910deadf9302 |
|
01-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
Use Choreographer for window manager animation timing. Change-Id: Ic34aff698c63d383ecd06af7da9957475683a1db
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
b7ff51bde92b76757a002bb5b1889f5790986513 |
|
24-Jan-2012 |
Dianne Hackborn <hackbod@google.com> |
Another attempt at issue #5823276: home repaints after full-screen app is exited This is between the two previous attempts. I returned the part from the original that was breaking gallery, but have some new code to detect when something about the window params has changed that would require a layout pass to make sure we still do a layout then, even if the window is not currently visible. Change-Id: I07745e1f66022583e3076b84cc8bbe8bd2acd48f
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
cfbf7dedaddd825b608e87d3dcf46adf80a46976 |
|
12-Jan-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5823276 again: 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. This fix does not include the change to ignore app tokens that are hidden. This causes problems in some dialogs that stay hidden until their app is ready to display, but need to perform a series of relayouts during that time to get to the right size. Dropping this part of the change still (mostly?) seems to allow us to avoid the bad states. Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
170997a519ce79e93e4f6984e9663232475ce92c |
|
19-Jan-2012 |
Justin Ho <justinho@google.com> |
DO NOT MERGE Revert "Fix issue #5823276: home repaints after full-screen app is exited" This reverts commit 01b02a734d2988c22b00f5df6346ad03d8bf52b6. Change-Id: I848c01fc44eb9a51ead1116b2647ed838ec1825f
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
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/services/java/com/android/server/wm/WindowState.java
|
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/services/java/com/android/server/wm/WindowState.java
|
6d05fd3c795088ac60f86382df5a66d631e8a0cb |
|
19-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5588689: Black camera preview after coming back from gmail Make surface management between SurfaceView and the window manager much more controlled, to ensure that SurfaceView always gets to report the current surface is destroyed before the window manager actually destroys it. Also a small tweak to allow windows that have a wallpaper background to still have a preview window. This makes launching home after it has been killed feel much more responsive. Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
e02c88af7935c72fb90a478375e61e4a94465587 |
|
28-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on process management. Introduce a new concept of "B" services. All running services are classified as either A or B. B services are later in the LRU list. Their oom_adj is after the home app. This allows us to better pick services to kill based on how long they have running, and should reduce the amount that we end up killing the home app. This temporarly turns on a debug log when the oom_adj of a process is changed. Sorry, I know it is noisy. This is needed to try to track down why some processes are being killed. Also add a flag to the SyncManager's service binding to allow the syncing process to be more aggressively killed if it has done UI. This is to address cases we have seen where sync is causing an 80MB gmail process to be kept around, preventing other process from running. Now what will happen is that the syncing process will aggressively be killed by the system, and can then be restarted in a much lighter-weight state. Do a little tweak in the power manager to allow us to still do smooth brightness changes even when the fancy TV off animation is in use. And get rid of a debug log in the window manager that was accidentally left in. Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
c6592d2eb808befedc3d9c842b61e21cc6bedbf3 |
|
26-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
am 67a1b7d6: Merge "Fix issue #5508024: Rotation jank seen in live wallpapers" into ics-mr0 * commit '67a1b7d6e5857d0ecdd1aa9d50d10189e5776c11': Fix issue #5508024: Rotation jank seen in live wallpapers
|
3ec891ae8067dd7afac5c0b5a8af0b726f4a4726 |
|
25-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5508024: Rotation jank seen in live wallpapers Fix a few places where we would unfreeze the screen too early. Now that we are no longer relying on surface flinger freezing, we can't depend on it keeping the screen frozen until surfaces get drawn. Change-Id: Icb03bf30c9599a5e2016817bfa5ca6458adc7249
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
cef37fb481d16eda2b304887a8738ed599bc1b21 |
|
24-Oct-2011 |
satok <satok@google.com> |
Fix a bug where surface crashes when the enter animation starts while the exit animation has not yet finished Bug: 5446482 Change-Id: I2e9f2e91ab5e8b22896d12e08fac76c72c997274
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
526f0a0e158cf46c244edc57624c15ebce26c71f |
|
19-Oct-2011 |
Mathias Agopian <mathias@google.com> |
Fix a hang in SF caused by invalid transform matrix from the WM WindowManager could create by transforms because of divide by zero. Bug: 5422468 Change-Id: I782f87ebb78b5ff23750e22837f36ca6cfed1f2f
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
36991744a221c30a47085442e6416bdde40b85e8 |
|
12-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5445966: WindowManager reporting -long on prime when it shouldn't be. The window manager now uses the app screen dimensions to compute the various configuration properties, as it should. This means that prime is official a "not long" device. Poor prime. It probably feels inadequate now. Because it is. Oh and all that other stuff? Debugging logs. Turned off. And why the heck not, debugging logs are great. Change-Id: Iaaf8ef270d986d34fd046d699ef4c0ecea1981fc
/frameworks/base/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
4941dea00a3167addf14ac6bb962cf5bc3590466 |
|
27-Sep-2011 |
Romain Guy <romainguy@google.com> |
Do not blend opaque windows. This change ensures the wallpaper is rendered into an opaque surface which avoids a glClear() in SurfaceFlinger. This should save quite a bit of work on every frame when panning the workspace in launcher. Change-Id: I9c1b8c324edf29826d5dbb1fb39d883e43375310
/frameworks/base/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
73db0d802ee4e1355d400329084eee6f5cff02a3 |
|
16-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
"Fix" issue #5276520: Noise on edges of rotation animation I have no shame. Change-Id: I9f40df670bba0f848097aad8afb978a29e42f85a
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
f809870f118663055dc0f8b626204e7bb1133fb5 |
|
13-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4280324: Returning to Fullscreen Layout with WebView... ...Leads to Shifted Layout Change-Id: I6cf3fd0dd066f73cd1ec6fce3d994f7e3eead293
/frameworks/base/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
cc4f7db698f88b633a286d8ab1105b28a474cd09 |
|
31-Aug-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix input channel leak. Bug: 5156144 Input channels could leak or simply live longer than they should in some cases. 1. Monitor channels (used by the pointer location overlay) are never unregistered, so they would leak. Added code to handle failures in the receive callback by closing the input channel. 2. The DragState held onto its input window and application handles even after the input channel was disposed. Added code to null these handles out when they are no longer needed. 3. Input channels previously used as input event targets would stick around until the targets were cleared (usually on the next event). Added code to detect when the input dispatcher is in an idle state and to proactively clear the targets then to ensure that resources are released promptly. 4. Native input window handles held onto the input channel even after the input window was removed from the input dispatcher. Consequently, the input channel would not be disposed until the input window handle itself was freed. Since the input window handle is held from managed code, this meant that the window's input channel could stick around until the next GC. Refactored the input window handle to separate the properties (info) and identify (handle) state into different objects. Then modified the dispatcher to release the properties (info) when no longer needed, including the input channel. 7. The pointer location overlay does not actually use its standard input channel, only the monitor input channel. Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to request that they not be provided with an input channel at all. Improved some of the error handling logic to emit the status code as part of the exception message. Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
a44abeb125a0c8a8e5a065f868d316e41354286a |
|
09-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve window manager debug output. Cleaned this up while I was debugging another issue. Change-Id: I0663b9ed581c6868b59655a0f994d870971ec1a6
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
bc68a59c024bdb745dac8e2ec7408a9f30595f1a |
|
25-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Report the external display size to the input reader. The input reader needs this information so that it knows how to interpolate touches on an external touch screen. Changed Display so that it asks the WindowManager what the real display size is (as opposed to the raw display size). This means it now takes into the forced display size set by adb shell am display-size. Replaced all calls to getRealWidth() / getRealHeight() / getRealMetrics() in the WindowManager and replaced them with direct usages of the mCurDisplayWidth / mCurDisplayHeight so that the WM doesn't end up making a reentrant Binder call into itself. Fixed the table status bar HeightReceiver so that it updates the height on all configuration changes since it is possible that the display size changed independently of an external HDMI display being plugged / unplugged. Improved the Display class documentation to make the distinctions betweeen the various sizes clearer. Change-Id: I3f75de559d3ebffed532ab46c4ae52c5e7f1da2b
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
9302c8796fc4dcda08d4bd1e11733848fd4fafaf |
|
14-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Refactor input dispatcher use of window/app handles. This change moves the cached window and application input state into the handle objects themselves. It simplifies the dispatcher somewhat because it no longer needs to fix up references to transient InputWindow objects each time the window list is updated. This change will also make it easier to optimize setInputWindows to avoid doing a lot of redundant data copying. In principle, only the modified fields need to be updated. However, for now we continue to update all fields in unison as before. It turns out that the input dispatcher was inappropriately retaining pointers to InputWindow objects within the mWindows InputWindow vector. This vector is copy-on-write so it is possible and the item pointers to change if an editing operation is performed on the vector when it does not exclusively own the underlying SharedBuffer. This bug was uncovered by a previous change that replaced calls to clear() and appendVector() with a simple use of operator= which caused the buffer to be shared. Consequently after editItemAt was called (which it shouldn't have, actually) the buffer was copied and the cached InputWindow pointers became invalid. Oops. This change fixes the problem. Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
b961cd2c80abf1d2834e5ad690904da4fe56d755 |
|
21-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Don't report a resize unless the window's surface actually changed. Change-Id: I133cf8e417753dba60d23a3bfc1c84ace983b335
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
5fd2169eabd77e6bfafaf456e58051a3bafb2bca |
|
07-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #4518815: Compatibility mode introduces compatibility regression... ...for Market App iRunner There were a lot of serious issues with how we updated (or often didn't update) the display and resource state when switching compatibility mode in conjunction with restarting and updating application components. This addresses everything I could find. Unfortunately it does *not* fix this particular app. I am starting to think this is just an issue in the app. This change does fix a number of other problems I could repro, such as switching the compatibility mode of an IME. Also a few changes here and there to get rid of $#*&^!! debug logs. Change-Id: Ib15572eac9ec93b4b9966ddcbbc830ce9dec1317
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
ffb3d939cc78cae523f14a0f8ab37061b5bffc20 |
|
18-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve compat mode scaling implementation. Rip out the old funky code for trying to restrict the app window sizes to be within the compat mode range. Instead, we know rely entirely on scaling -- we deal with windows always with the scaling applied so that the window manager doesn't have to deal with them specially. Instead, we just apply the inverse scale at the few points we need to do something the app sees. Change-Id: I785409dd4513b5f738684e1635dc8f770c249651
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
ac8dea12c17aa047e03a358110aeb60401d36aa2 |
|
21-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE. Integrate from master: Rework display size access. Applications now get the display size from the window manager. No behavior should be changed yet, this is just prep for some real changes. Change-Id: I47bf8b55ecd4476c25ed6482494a7bcc5fae45d2
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
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/services/java/com/android/server/wm/WindowState.java
|
648251710162cdaf7371012a1cbb79b9bc5bc0e4 |
|
03-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3485923: Gmail crash Allow application to try to recover if a surface OOM error happens on the client side. Change-Id: I0308bd99647a35e4bcac448340b7fc6330a828f6
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
6e1eb76f02ccc9dbc309b938f62d39312da8cafe |
|
18-Feb-2011 |
Dianne Hackborn <hackbod@google.com> |
Explode WindowManagerService. Change-Id: I3d73ed4c9a1b5d730aeffeb2df24ce5e6117d698
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|