7eec37989f1d030d8f933712e6cb2bff8d9e4104 |
|
15-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Suppress a11y shortcut on emergency dialer Suppressing whenever the keyguard is locked, not just when it's showing. This should reduce false triggering. Bug: 34820720 Test: Verfied that shortcut no longer activates on emergency dialer or lock screen. Change-Id: Ic43c11798f04217c2871efe7d0fa21dbf61fd953
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
7039cbc6f3a596aee6851014019849490f358f13 |
|
04-Jan-2017 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Add content description and tooltip to menu item Bug: 34076597 Test: manual Change-Id: Ide32463252457721286c929ab2f8f7bae241835d
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
42a99377f54309111d4acc3d5660bb4b188353ff |
|
25-Sep-2016 |
Gopal Krishna Shukla <gshukla@codeaurora.org> |
Merge "Provide synchronization to setview to avoid NPE" am: b05b93a674 am: 810c31fdca am: 621e87d72f am: 260af96306 Change-Id: I1907b2252ae2fa25667b3a0484f6852660c74da3
|
f7abcda5f22cde86666aeedbf1cc2a99b47ec2c2 |
|
06-Jul-2016 |
Gopal Krishna Shukla <gshukla@codeaurora.org> |
Provide synchronization to setview to avoid NPE If setView() will be called from two different threads then mView property of a View object may have inconsistent value. For instance, setView() may set mView to null causing NullPointerException. Synchronize root.setView() as well to avoid this. Change-Id: I5f9cf47ece5d4aca575bd8644ecfcee0ed43d843
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
45faba516e200760e977e8ceb76f079ee8aa7415 |
|
28-Jun-2016 |
Stan Iliev <stani@google.com> |
Fix wording regarding ThreadedRenderer ThreadedRenderer is not synonymous with hardware rendering, so remove references to hardware rendering when referring to ThreadedRenderer. Change-Id: Ic66a482ccf05f556ebe6ec194ce4f858f75bbb8b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
eac0ea5cdfade6bfd2a1e40e67c2a45d4c37ab9e |
|
12-May-2016 |
Andrii Kulian <akulian@google.com> |
Close leaked windows when trying to preserve main one When app has several windows and activity is relaunched + we try to preserve main window - other windows just stayed around until removed by timeout or replaced by app. There was a problem when one of the windows registered broadcast receiver and set its own timer to remove it. In this case all receivers were removed by framework because windows were considered leaked and apps' timer caused crash when trying to remove registered receiver. This CL removes all windows expect the main one, which we're trying to preserve in this case. Bug: 28337135 Change-Id: Ib8790cc8c61801f11d871ba3803bb0ebc3d3be01
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
d136e51a99df5275eaafdde407e89e78c02b829b |
|
10-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Defuse Bundles parsed by the system process. It's easy for apps to throw custom Parcelables into Bundles, but if the system tries peeking inside one of these Bundles, it triggers a BadParcelableException. If that Bundle was passed away from the Binder thread that delivered it into the system, we end up with a nasty runtime restart. This change mitigates this trouble by "defusing" any Bundles parsed by the system server. That is, if it encounters BadParcelableException while unpacking a Bundle, it logs and delivers an empty Bundle as the result. Simultaneously, to help catch the system process sticking its fingers into Bundles that are destined for other processes, a Bundle now tracks if it's "defusable." For example, any Intents delivered through ActivityThread are marked as being defusable, since they've arrived at their final destination. Any other Bundles are considered to be "in transit" and we log if the system tries unparceling them. Merges several Parcel boolean fields into a flags int. Add better docs to several classes. Bug: 27581063 Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
0ffd49cbe0ab4c13fd5528abacade898a8cff481 |
|
13-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Always consume bottom insets when navigation bar is force shown When an app requests SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION but we force show the navigation bar, we need to treat for the app like there is no virtual navigation bar on the device. Because if you combine it with FLAG_HIDE_NAVIGATION, you'd expect the navigation bar gets hidden but it doesn't, so there could be content that overlaps with the navigation bar. Bug: 27157904 Change-Id: I088e02eae2e723c35e9cb4873de6b1325458533b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
4846ee3cc378001128680f2a3309c7e60bfcac75 |
|
07-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Optimize window relayouts when dragging divider - Communicate the resize mode to ViewRootImpl. If it is a docked divider resize, do not call relayout for every traversal. - Do not call Task.resizeWindows() unconditionally when changing Stack bounds. It might be just a move. - However, not calling relayout breaks layout bounds while relaunching. To fix that, do the following: -- Inform ViewRootImpl that the activity just relaunched, and force a relayout call in the next traversal so the client can pick up the unfrozen bounds. -- When unfreezing the bounds, cause a traversal in window manager. Bug: 25015474 Change-Id: Iab9a445dabce4f6ec1e25957038fe40a4be65246
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
51aaf906f9f5fb2f117f5ccfae8be6974f7cb903 |
|
03-Dec-2015 |
John Reck <jreck@google.com> |
Nuke HardwareRenderer abstract base Bug: 17303292 Change-Id: I4a272ea4f695f4f9993e8be640fdd8530b691be0
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
f4abc2b701c23978e8bd5e4fc3e183e519aede4a |
|
13-Nov-2015 |
Chong Zhang <chz@google.com> |
Need to updateSurface if surface size was changed in relayoutWindow On some chips, SurfaceControl.setSize will not take effect for several frames. We have to also do a updateSurface/invalidate (which destroys and creates the EGLSurface) to get the size right. Keep track of SurfaceControl size changes in window manager, and pass that to ViewRootImpl, so that a updateSurface is done either the surface itself or its size is changed. Note that we don't use frame size change to trigger updateSurface, because frame size could be different from the surface size that window manager set. For example during drag resizing, the surface size is fullscreen although frame size changes constantly. Doing updateSurface upon frame size change could cause us to do many unnecessary updateSurface. bug: 25583942 Change-Id: I1989613a187bb6ef1c179bd2800c6a7b01fcdb3a
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
63a35e2343468a04e360f0514c6c9dc03068c185 |
|
06-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix minor problems when resizing/maximizing docked window. When maximizing the transition should originate from visible bounds, so the first frame matches what is visible to the user. When switching to the big surface, we only need to increase the layer by one, instead of having artificially large value. If we use the large value, it will cause a flicker over system windows. Also includes some cleanup, like static imports and necessary logging. Bug: 24913915 Change-Id: I84d7594622aa639e2008c662f941edf9c20b3202
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
0275e397f482a1f25745a66c5db68c3a6c863951 |
|
17-Sep-2015 |
Chong Zhang <chz@google.com> |
Place surface at screen't top-left when doing drag resizing Instead of letting the client render to (0,0) and moving the surface around, put the surface at a fixed location, and let the client render to the screen position within the surface. This fixes the window shaking problem when resizing by dragging window's top-left corner. The frame rect used in last draw is lagging window manager's latest bounds for the window, moving the surface's position would make the window's bottom-right corner appears moving (while it's supposed to be stationary). bug: 23793966 Change-Id: Ideb152fc48502f8e9672235f10b044889235e7df
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
d70b9e7aea9c7b0691f3ac1326752f91d5049458 |
|
27-May-2015 |
Alan Viverette <alanv@google.com> |
Move ApplicationInfo hardware acceleration to public flags Bug: 21342038 Change-Id: I5af826f3f2921eef24725c909304243c67f3da78
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
827e0facfefd0c0033dcfb1747b4fa6f80f9e0e2 |
|
07-May-2015 |
Jorim Jaggi <jjaggi@google.com> |
Make sure the app can draw a frame before unlocking - The mechanism to stop windows drawing while window animator was animating was somehow flaky. It relied on the fact that the client would call relayout() whenever the animating state changed. This is mostly the case, but not for lockscreen animations. Instead, we now use a push model, where window manager tells the app that the state has changed. - In addition, it only stopped drawing if that window was animating, but then only resumed drawing after all windows have finished animating. Now, we do this per window, so we only stop drawing for windows that are currently animating. - We resume the top activity now at the very beginning of the unlocking sequence. This gives the app a chance to draw a frame before the user sees anything. If it's to slow, then we just use the outdated framebuffer. Bug: 19964562 Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
41725dedc33906aaafee36b2d6523596e2a8a52e |
|
09-Apr-2015 |
George Mount <mount@google.com> |
Disable input during Activity Transition. Bug 19437530 While the actual Activity Transitions are running, input is stopped, except for the "back" button. Change-Id: I112e6252b9de05ece10a6267681fee5487e5ef6b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
9b0ab65ed46be992dd71b5f811bb972168e51c36 |
|
18-Mar-2015 |
Alan Viverette <alanv@google.com> |
Enable/disable hardware rendering on windows by application tag Previously, hardware rendering cannot be enabled or disabled on windows created without a parent activity (e.g. by services) by setting the <application> tag, "android:hardwareAccelerated" in AndroidManifest.xml. It's enabled by default in Android L from the commit, 5e1565ead6dbb7d5c414522591f61b16a23de1c3. This patch provides a way of setting hardware rendering for that case. Change-Id: I60ee9566e99db39cd661fe6f196f43c3968b311a Signed-off-by: Dohyun Lee <dohyun.lee@lge.com>
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
ba6adf66d3c44c0aa2fd8a224862ff1901d64300 |
|
19-Feb-2015 |
John Reck <jreck@google.com> |
Initial attempt at jank-tracking stat collection Is a bit naive, perhaps overly aggressive, but sorta works Change-Id: I01a774e00dbe681439c02557d9728ae43c45ce50
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
a7bb6fbeab933326d58aa806d8194b7b13239d34 |
|
04-Feb-2015 |
Dianne Hackborn <hackbod@google.com> |
First quick implementation of auto assist data. Introduce new AssistData class that contains all data the framework automatically generates for assist. Currently populated with a very simple tree structure representing the app's view hierarchy. Reworked how we populate the class name for accessibility info, so this is provided through a new method call on View that subclasses can override. This method is also used to populate the class name in AssistData. Change-Id: Ibd0acdc8354727d4291473283b5e4b70894905dc
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
3c0e7e908f1f90677ae3937199e37c162f81b2f9 |
|
13-Jan-2015 |
Wale Ogunwale <ogunwale@google.com> |
am 00c85656: am 42b0d10a: am 1ea6afe1: Merge "Don\'t allow windows with invalid types to be added." into lmp-mr1-dev * commit '00c8565614d3555e723ff3d8dad3af92d69d81ea': Don't allow windows with invalid types to be added.
|
74bf065e43a3075ffcaf9fcdc1ef423a1e14b761 |
|
12-Jan-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't allow windows with invalid types to be added. Bug: 18950225 Change-Id: Ia7ead72d036c7628e0a97f8fe9fef2a35525e4df
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
9ecb73c7d89164529fdf8462187f0a3e9a0ed136 |
|
15-Dec-2014 |
Alan Viverette <alanv@google.com> |
Don't force hardware acceleration for services on low-end GFX BUG: 18732678 Change-Id: I136135a91296de3e7d4c089b61019a5395de4a5b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
8ccf071ab83510c8ef7b4d311d894d5c4a352f6c |
|
20-Nov-2014 |
Alan Viverette <alanv@google.com> |
Merge "Move default token handling into WindowManagerImpl" into lmp-mr1-dev
|
7c9746d4ef8ab3c500b501ab32933c5172a856ab |
|
20-Nov-2014 |
Alan Viverette <alanv@google.com> |
Move default token handling into WindowManagerImpl BUG: 18451795 Change-Id: I1fc6db988ad879fded5318f33d08a4f09da38907
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
0d1c27a713cb49de8f6f4fd0a129baa883153921 |
|
03-Nov-2014 |
Chet Haase <chet@google.com> |
Fix seeking and scaled duration behavior The animation scaled was not being factored in early enough in the activity lifecycle. Also, setCurrentPlaytTime() was not accounting for the scaled duration correctly. Finally, added setCurrentFraction() as a more general-purpose seeking facility. Issue #18222006 Animator duration scale ignored in some situations Issue #17951668 add ability to seek fraction, not just time Change-Id: Idad401f5ff5026d7046c36eee09d78a4793215dc
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
d2fa5143910c74fd126359f74b08de84b0f7cf2a |
|
05-Nov-2014 |
Alan Viverette <alanv@google.com> |
Use default token instead of wrapped window manager BUG: 18248602 Change-Id: Id7f06c896dc71db3564fa21d3704222557613035
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
955d8d69ea6caabce1461dc25b339b9bf9dc61a6 |
|
08-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Put in real "code" (aka marketing) name. Change-Id: Idb3976edfae37293ed75cb5b869b4b42d8042bbe
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
ccf2fa00314b91c7d25e0edf48e0e2b51dbc4e63 |
|
25-Sep-2014 |
John Reck <jreck@google.com> |
Missing null check Bug: 17642023 Change-Id: I874b76e1e184a59dec714191d759c1045b7b9814
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
73840ea3670f1c117843acc6069635c80ba2ffd2 |
|
22-Sep-2014 |
John Reck <jreck@google.com> |
Aggressively trim memory for system_process Bug: 16978006 Don't HWUI-accelerate KeyguardScrim Aggressively trim memory as soon as a ViewRootImpl dies or has its visibility changed. Change-Id: Ie1b7c9d30653456bd2e9f309128174f972999368
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
5e1565ead6dbb7d5c414522591f61b16a23de1c3 |
|
30-Jul-2014 |
Alan Viverette <alanv@google.com> |
Enable hardware rendering for system process Also enables hardware rendering by default on windows created without a parent activity (e.g. by services). BUG: 16240470 Change-Id: I906d48cb07af50fa02dae4f4ecdb5e65211fc6ef
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
f47a594f5250b1914c36423ee6b371f0b8db09d0 |
|
01-Jul-2014 |
John Reck <jreck@google.com> |
Fix onTrimMemory for HardwareRenderer Also fixes detachFunctor possibly drawing after return Bug: 15189843 Bug: 15990672 Change-Id: I64c48cb674c461a8eeaba407b697e09f72c98ce3
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
eb94fa7975b1e8742f3b00cec6bd4f9d6b329e3a |
|
04-Jun-2014 |
Dianne Hackborn <hackbod@google.com> |
Improvements to low power mode. Add new public API for monitoring low power mode. BatteryService now puts device in to low power mode when battery level is low. Window manager now watches low power mode to turn off animations. Modifying the animator scale now gets propagated to all processes. Change-Id: I8fa566994764ddd4e1977631e28381ab9409f8ee
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
fe5e7b7346a54537b980796ceeca66bfdbd05561 |
|
24-May-2014 |
John Reck <jreck@google.com> |
Enable debug stuffs Bug: 14596762 * dumpsys gfxinfo implemented * profile GPU visual_bars implemented Change-Id: Icb948a9d5af5989b5615504d0d76ade64b93ef5b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
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
|