007751276c210c39bd405ae9fa69854e67e80951 |
|
20-Aug-2013 |
Craig Mautner <cmautner@google.com> |
Merge "Notify ViewRootImpl when it's safe to modify Canvas." into klp-dev
|
bc57cd1b248bf23e443581f9fe44167c94699ce8 |
|
20-Aug-2013 |
Craig Mautner <cmautner@google.com> |
Notify ViewRootImpl when it's safe to modify Canvas. When Activity.convert{To|From}Translucent() is called the ViewRootImpl is now notified when it is safe to convert the Canvas from translucent to opaque and back to translucent. This will make it possible to save resources when compositing opaque layers. Fixes bug 10349536. Change-Id: I7282aee1d54601fb00611d20be204bf164d873f6
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
46bfc4811094e5b1e3196246e457d4c6b58332ec |
|
17-Aug-2013 |
Romain Guy <romainguy@google.com> |
Fix hardware layers lifecycle Bug #10075732 Hardware layers could survive across EGL terminate events. Change-Id: Ie8565d55cb29fe6625fa1584d695edfecd37ab5e
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
4f09d517c5e61d4dfd34b89a7949897c86853881 |
|
01-Jul-2013 |
Craig Mautner <cmautner@google.com> |
Remove debug logging. Bug has been fixed. Change-Id: Ifda11ac6e83012498855e0c7254c99491b128f04
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
e7c58b6d7d761b93e785b0a399e5b00fdb82f4ce |
|
13-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Add debug for specific bug. To be removed once the bug is fixed. Change-Id: Ie273d4503bb0b534af0e9efe8f45c573766e9a74
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
8c84109b9fbbf473b225707a38261ff5f99d95fb |
|
24-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Use FastPrintWriter... everywhere. One problem this turned up is, because FastPrintWriter does its own buffering, a lot of code that used to use PrintWriter would fail -- if it pointed to a StringWriter, there was no buffering, so it could just immediately get the result. Now you need to first flush the FastPrintWriter. Also added some new constructors to specify the size of buffer that FastPrintWriter should use. Change-Id: If48cd28d7be0b6b3278bbb69a8357e6ce88cf54a
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
8f303ad97007a9b38d6d927353c1fba812879ae5 |
|
14-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Complete doDie() before executing addView(). If WindowManager.addView() is called soon after WindowManager.removeView() then the MSG_DIE in the ViewRootImpl mHandler queue may not have had time to execute. This will cause WindowManagerGlobal to throw an exception since the DecorView is being added before it has been removed. This fix detects that situation by saving all Views that are queued up for ViewRootImpl.doDie(). If addView() is called for one of these Views then doDie() is called immediately and not called when MSG_DIE eventually makes its way through the queue. This change also makes doDie() non-reentrant by only allowing it to carry out its functions the first time it is called. This keeps dispatchDetachedWindows() from causing destruction by recursively calling back into doDie(). This is usually caused by calling dismissDialog() from within dispatchDetachedWindow(). Fixes bug 9404689. Fixes bug 9406261. Change-Id: Id4fc8054e273215d82366428fef51b9ba98385fe
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
92098c7c30bc76310a066b220e625fa9aa4b925d |
|
10-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Dismiss immediately to maintain consistent state. Fix bug introduced by deferring nulling of mParent. In dismissDialog the removal was being put on a queue while the state of the Dialog was being updated immediately. This meant that if a show() was called before the remove was executed it would try and add the DecorView a second time. Boom! Fixes bug 9370301. Change-Id: I576d1e207c786bc2e21dfd40cb94f2b63a020fe2
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
652fdfaf6f8131886dbc925d670e00e9d85e56da |
|
06-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Replace arrays with ArrayList The three arrays were being reconstructed and copied for each add and each remove. By replacing them with ArrayList only three constructions total are required. Also, the number of System.arraycopy() calls is halved. Change-Id: I0f8def1b517eb1bc5f930fcd5d3d1e0394071f0e Conflicts: core/java/android/view/WindowManagerGlobal.java
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
05eb730ca42eec3a40f916062af7442218135303 |
|
04-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Delay removal of windows from WindowManager When relaunching activities the window manager clears out all windows by calling a ViewRootImpl.die() in a deferred fashion. Then it immediately deletes the ViewRootImpl and its view from its list of windows. When the die() is eventually executed it calls dispatchDetachedFromWindow() which tries to remove the previously removed windows causing an Exception to be thrown. This change waits to remove the windows until after die() has been completed. Fixes bug 8253030. Change-Id: I5b41be1c6b776e32128c064267653db98bd95292
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
f9e989d5f09e72f5c9a59d713521f37d3fdd93dd |
|
05-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Queues, queues, queues and input. Redesigned how ViewRootImpl delivers input events to views, the IME and to native activities to fix several issues. The prior change to make IME input event delegation use InputChannels failed to take into account that InputMethodManager is a singleton attached to the main looper whereas UI may be attached to any looper. Consequently interactions with the InputChannel might occur on the wrong thread. Fixed this problem by checking the current thread and posting input events or callbacks to the correct looper when necessary. NativeActivity has also been broken for a while because the default event handling logic for joysticks and touch navigation was unable to dispatch events back into the native activity. In particular, this meant that DPad synthesis from touch navigation would not work in any native activity. The plan is to fix this problem by passing all events through ViewRootImpl as usual then forwarding them to native activity as needed. This should greatly simplify IME pre-dispatch and system key handling and make everything more robust overall. Fixed issues related to when input events are synthesized. In particular, added a more robust mechanism to ensure that synthetic events are canceled appropriately when we discover that events are no longer being resynthesized (because the application or IME is handling or dropping them). The new design is structured as a pipeline with a chain of responsibility consisting of InputStage objects. Each InputStage is responsible for some part of handling each input event such as dispatching to the view hierarchy or to the IME. As a stage processes an input event, it has the option of finishing the event, forwarding the event to the next stage or handling the event asynchronously. Some queueing logic takes care to ensure that events are forwarded downstream in the correct order even if they are handled out of order by a given stage. Cleaned up the InputMethodManager singleton initialization logic to make it clearer that it must be attached to the main looper. We don't actually need to pass this looper around. Deleted the LatencyTimer class since no one uses it and we have better ways of measuring latency these days using systrace. Added a hidden helper to Looper to determine whether the current thread is the indicated Looper thread. Note: NativeActivity's IME dispatch is broken by this patch. This will be fixed later in another patch. Bug: 8473020 Change-Id: Iac2a1277545195a7a0137bbbdf04514c29165c60
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
945bfb6068d4ac1414a37a3ebe4dc4d02383e38e |
|
07-Jan-2013 |
Siva Velusamy <vsiva@google.com> |
Support hierarchy viewer commands via DDM Hierarchy Viewer currently interfaces to the host via a socket opened by ViewServer which resides in the WindowManagerService. Since this has access to all windows, it is enabled only on debug builds. This CL adds necessary support to DDM to handle all the commands required for Hierarchy Viewer. It only misses two commands that are sent to the Window Manager (which we don't have access to from the applications). A future CL will remove the ViewServer functionality. Change-Id: I1dae316a00737b0cae4e640ccc97bf9bb1d05973
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
6018aeec27914f138f36b00d8f00136a87562fd3 |
|
23-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Add throwing InvalidDisplayException from addView. Throw an InvalidDisplayException to addView if the display being added to has been removed. Handle this exception in Dialog.show() by removing the view after it has been added and rethrow the exception from there. Add javadoc to ViewManager.addView and Presentation.show explaining the new exception and how best to handle it. Bug: 7368565 partially fixed. It remains for the Videos app to handle Presentation.show throwing the InvalidDisplayException. Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
2d5618c22101cfc4d6478cfe1d846798389540c1 |
|
18-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Allow getDisplayContentLocked to return null... ... and check for null returns. This prevents DisplayContent objects from containing null Display references. Bug: 7368565 fixed. Change-Id: I830fb4c1349204c366193657a95a92c48ccee66c
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support. Split WindowManagerImpl into two parts, the WindowManager interface implementation remains where it is but the global communications with the window manager are now handled by the WindowManagerGlobal class. This change greatly simplifies the challenge of having separate WindowManager instances for each Context. Removed WindowManagerImpl.getDefault(). This represents the bulk of this change. Most of the usages of this method were either to perform global functions (now handled by WindowManagerGlobal) or to obtain the default display (now handled by DisplayManager). Explicitly associate each new window with a display and make the Display object available to the View hierarchy. Add stubs for some new display manager API features. Start to split apart the concepts of display id and layer stack. since they operate at different layers of abstraction. While it's true that each logical display uniquely corresponds to a surface flinger layer stack, it is not necessarily the case that they must use the same ids. Added Display.getLayerStack() and started using it in places where it was relatively easy to do. Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|