7b1aa77a9b25b4b1e8070c9cccfadcde39954952 |
|
01-Dec-2012 |
Craig Mautner <cmautner@google.com> |
Include child windows when looking for insertion point. After finding a window in the window list we turn around and look in the AppWindowToken.windows list for it. If it is a child of a window in that list we should use the parent windows index as the search result. Instead we gave up and ended up inserting the window at the beginning of the windows list. Bug 7357465 fixed. Change-Id: If77f343b8597bfbb0b7fa41dedf7972d78d03020
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
e8552142494bbb4438a8748707f74b1ce241ea48 |
|
07-Nov-2012 |
Craig Mautner <cmautner@google.com> |
Retain configuration change info and sync access. - If a window was hidden while the configuration changed and then changed back WindowManagerService would not know that the change had ever happened and wouldn't notify the window of this. Most windows wouldn't care but because Keyguard inflates layouts while it is hidden... Bug 7094175 fixed? Bug 7501099 fixed! Change-Id: If27f5f1d333602dac7719dd39dbdf3fe7954aa06
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
98129739afcb3786a6ec9f3efe774d8e01f6d632 |
|
02-Nov-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7343200: Fails to show wallpaper in the background for... ...lockscreen sometimes and remains black / blank The problem was that we were using the animation-side wallpaper state in cases where it was not updated yet. The mWallpaperTarget variable is propagated over to the animation side when the main window manager state updates. On the animation side, this is used by hideWallpapersLocked() to determine if the current wallpaper should be hidden. The problem is that various paths to hideWallpapersLocked() can come from the layout side of the window manager instead of the animation side. This causes the problem here because in this case the wallpaper state may not have yet been propagated to the animation side, so it could incorrectly decide to hide the wallpaper because it thinks there is not a target when in fact a target is set in the layout side. This won't get fixed until some time way later that the layout side decides that a new window is being shown that may need to have the wallpaper shown. The fix here is pretty gross, but as safe as possible -- the hideWallpapersLocked() function now uses either the animation or layout wallpaper state depending on where the call to it is coming from. Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
529e744d3131b9ebeb6b33c8030230c29a44ad12 |
|
01-Nov-2012 |
Dianne Hackborn <hackbod@google.com> |
More debugging for issue #7343200 Fails to show wallpaper in the... ...background for lockscreen sometimes and remains black / blank There was a bunch of state not being put into the dumpsys output. In particular, the current wallpaper target of the WindowAnimator was not being included. I think the problem is that these targets are not being updated from the main window manager state at some point where they need to be. Change-Id: Ic795047f6aea9b6f72d5550bccc9f8d76c6ecb67
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
ad09bccfe4cc0a3075e97c0911a02b329023a34a |
|
08-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Bring up unlock screen for FLAG_DISMISS_KEYGUARD. Widgets that did not launch Activitys would not display the unlock screens when they were tapped. Now any window that is shown with FLAG_DISMISS_KEYGUARD set while the keyguard is locked will cause the unlock screen to be displayed. Bug: 7301530 fixed. Change-Id: I90d11b52d2b63260bdb5f2b6eb7e98eb7a4d9331
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
341220fd099b2e74ac605d417f274537dc4bc749 |
|
17-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Use parent window to evaluate show-to-all-users. When a window is attached to another window use the parent window's attributes to determine whether the child window should be shown to all users. Bug: 7328633 fixed. Change-Id: I9601c149af87f624378e6895063bb3179d4f845e
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
a987d43bc916b6446fe41037d9fcf07e778b3452 |
|
11-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Check for apps closing and restore mExiting test. Removal of the mExiting test in a previous CL was a mistake leading to z-order errors. In particular the auto complete dialog was on top of the IME and was being dismissed due to touches on the IME. Restoring mExiting alone missed cases where apps were exiting which don't set mExiting. Adding a test for membership in mClosingApps fixes that. Bug: 7327220 fixed. Change-Id: I3965b8a07080d1347bdada51ffeafe6ef2e32c8e
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
e6f7d5054a71eeae8c0b10a2305347efdcd8c3d3 |
|
08-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Fix problems with IME layers. The query WindowState.isDisplayed did not take into account being displayed due to app animations. When an existing input method target was animating away the logic for detecting if it was still on screen was faulty. This led to assigning the input method to a layer below its target and obscuring the input method until the animation was complete. Bug: 7296703 fixed. Change-Id: Ib00db4f21b726ed57d25d6a1e796b65a7d45ee97
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
5962b12bedc4a1d0354816c1cd6b06ba04f6d807 |
|
05-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Adds showWhenLocked attribute to Activities. The new attribute allows an Activity such as the alarm to appear on all users screens. Bug: 7213805 fixed. Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
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/services/java/com/android/server/wm/WindowState.java
|
5fe7e2a3043d6a8ca933c77ccf95c791b57b221a |
|
04-Oct-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6968859: home not exiting an ANR'd dream Add a new call to the activity manager for the input dispatcher to report about any pid having an ANR. This has a new feature where it can also tell the activity manager that it is above the system alert layer, so the activity manager can pop its ANR dialog on top of everything if it needs to. (Normally we don't want these dialogs appearing on top of the lock screen.) Also fixed some debugging stuff here and there that was useful as I was working on this -- windows now very clearly include their uid, various system dialogs now have titles so you know what they are in the window manager, etc. Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
812d2ca475e88d4e52870a4eeeb096a411f0f077 |
|
28-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Fix layout state issues. - Restore test of hidden to isGoneForLayoutLw(), without that we return false when setAppVisibility(true) is called which leads to early layout of windows. Particulary on return from full screen to non-full we lay out once before recognizing that the status bar should be back and then again once the status bar appears causing a jump. Fixes bug 6470541. - Add a new test for configuration size changes to gone or hidden windows. This forces a layout call to these windows which informs them of the new size even though they are not shown until later. In particular this keeps windows that were in the background during a rotation from using their old boundaries on return. Fixes bug 6615859. - Consolidate WindowState.mConfiguration tests into WindowState. Change-Id: I7a82ce747a3fcf7d74104dc23f1532efe64bd767
/frameworks/base/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
178af5948d71c841278081c712506f7a7fca34b9 |
|
17-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Add debug to help with b/7135184. Change-Id: I0d3b60b3e123d35bd557d47e3344ebea1964380b Conflicts: services/java/com/android/server/wm/WindowAnimator.java
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
c516a5c58ff505d7c53d79a174aa118f65cac366 |
|
13-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Only consider hiddenRequested when deciding layout This change removes the test for hidden when deciding whether to do a layout. So layout begins as soon as hiddenRequested occurs. Since hidden is cleared when animations starts considering hidden in the layout decision will delay layout until it is too late. In particular we were not executing a relayout on return to an activity even though the screen had been rotated while away. Fixes bug 6615859. Change-Id: I5fb0b4bf2c253b910a7a192da04419236d8f09d9
/frameworks/base/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.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/services/java/com/android/server/wm/WindowState.java
|
19d59bc5ad877e9b1544ab13a08282b7b384fefb |
|
04-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Make mLayoutNeeded per-Display. Switch from a global mLayoutNeeded to one for each Display so that we don't run layout on Displays that haven't changed. Change-Id: Ib65c5c667933cceacc46b94f4e6e6bd613d5cb35
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
a2d7b1117abc23a3ff0ccda15a2f9138aaa7f4fc |
|
22-Aug-2012 |
Craig Mautner <cmautner@google.com> |
Fix to allow SYSTEM_UID to display windows. Was not previously checking to make sure that the appId was not SYSTEM_UID (1000). This caused certain system windows to fail to appear. Change-Id: I939dc2f8a256acb84b7c413c7e00003a89aff6d4
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
9dc52bc44c94854fcd3384a045b4b862e30e25de |
|
06-Aug-2012 |
Craig Mautner <cmautner@google.com> |
Hide non user app windows from other users. When transitioning between old user and new user application windows from the old user may not be shown because only one user's windows can be shown at a time. Change-Id: I4e17b36c9100c9457cc6eb3cb3b77f3a94fa2b41
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
59c009776dae5ccbdfb93d7151ff2065ca049dc3 |
|
30-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Introduce multiple displays with DisplayContent. Fix a couple of bugs that turned up. Remove touch/focus from display. Add iterators for access. Respond to comments. Remove TODOs, and some deviceId parameters. Change-Id: Idcdb4f1979aa7b14634d450fd0333d6eff26994d
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
6881a10557acf3b0270de54799d6f19437acf584 |
|
27-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Small step towards supporting multiple displays Change-Id: I353449c2b464394988c7e0203656b5851a0c9127
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
fa25bf5382467b1018bd9af7f1cb30a23d7d59f7 |
|
24-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Add display manager skeleton. The purpose of this change is to remove direct reliance on SurfaceFlinger for describing the size and characteristics of displays. This patch also starts to make a distinction between logical displays and physical display devices. Currently, the window manager owns the concept of a logical display whereas the new display manager owns the concept of a physical display device. Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
322e40315609acd5a608440bc469d873e09559ca |
|
13-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Further isolate layout side from animation side. - Use local AppWindowAnimators in WindowAnimator rather than using shared WindowManagerService objects. - Use local WindowStateAnimators in AppWindowAnimator rather than use AppToken's WindowState objects. - Remove redundant WindowManagerService parameter passed to AppWindowAnimator ctor. - Keep from copying parameters from performLayout if the parameters haven't changed since the last copy. - Link WindowStateAnimator to AppWindowAnimator to keep from going through WindowStateAnimator.mWin, WindowState.mAppToken and AppWindowToken.mAppAnimator. - Converted attached WindowState in WindowStateAnimator to WindowStateAnimator to eliminate multiple conversions. Change-Id: I5e35af88d8fdc1a7454984eaea91a1bc4f926978
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
918b53bc531f5bd1ea102e8b827d693bd4d0555b |
|
09-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Isolate layout and animation wallpaper objects. Provide separate copies of mWallpaperTarget, mWallpaperTokens, and mLower/UpperWallpaperTarget in the layout and animation sides of Window Manager. Simplify constructors of WindowAnimator and WindowStateAnimator. Change-Id: I7e35794a432c25c4194c046e9e27150d1c905403
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
711f90a7c1e99a435fa8f5335f13772f0b41270b |
|
04-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Swap source and destination transfer objects. It will be better to have the object that moves layout parameters to animation on the layout side, and the object that moves animation parameters back to layout on the animation side. That way we can do partial filling of these objects without calling across. We may never do partial draining of these objects. Change-Id: I88826fa97350f96e309beef386885f55a9a73305
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda |
|
21-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Use two fingers to work some magic... Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/services/java/com/android/server/wm/WindowState.java
|
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
|