a492c3a7b2c18426fd0cb4d017eacbc368195dc5 |
|
24-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Initial draft of high-level multi-display APIs. This patch introduces the ability to create a Context that is bound to a Display. The context gets its configuration and metrics from that display and is able to provide a WindowManager that is bound to the display. To make it easier to use, we also add a new kind of Dialog called a Presentation. Presentation takes care of setting up the context as needed and watches for significant changes in the display configuration. If the display is removed, then the presentation simply dismisses itself. Change-Id: Idc54b4ec84b1ff91505cfb78910cf8cd09696d7d
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
bd6e1500aedc5461e832f69e76341bff0e55fa2b |
|
28-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Add initial multi-display support. Split the DisplayManager into two parts. One part is bound to a Context and takes care of Display compatibility and caching Display objects on behalf of the Context. The other part is global and takes care of communicating with the DisplayManagerService, handling callbacks, and caching DisplayInfo objects on behalf of the process. Implemented support for enumerating Displays and getting callbacks when displays are added, removed or changed. Elaborated the roles of DisplayManagerService, DisplayAdapter, and DisplayDevice. We now support having multiple display adapters registered, each of which can register multiple display devices and configure them dynamically. Added an OverlayDisplayAdapter which is used to simulate secondary displays by means of overlay windows. Different configurations of overlays can be selected using a new setting in the Developer Settings panel. The overlays can be repositioned and resized by the user for convenience. At the moment, all displays are mirrors of display 0 and no display transformations are applied. This will be improved in future patches. Refactored the way that the window manager creates its threads. The OverlayDisplayAdapter needs to be able to use hardware acceleration so it must share the same UI thread as the Keyguard and window manager policy. We now handle this explicitly as part of starting up the system server. This puts us in a better position to consider how we might want to share (or not share) Loopers among components. Overlay displays are disabled when in safe mode or in only-core mode to reduce the number of dependencies started in these modes. Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
/frameworks/base/core/java/android/view/WindowManagerImpl.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/WindowManagerImpl.java
|
a8b9defade5b937d4ad64f9aff4bca792298f43c |
|
23-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Stop using raw display size except in window manager. We don't actually need the raw size in these places. The logical size is good enough. Starting to move dependencies on surface flinger and window manager out of the Display class. Change-Id: I2065bee8e5bf7f42c5a452dd1e8479e40ebb0d37
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
d32460c5b7bea7b06e345397fdbaca58d9732dcf |
|
21-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor local window manager implementation. The objective of this refactoring is to remove the reliance on WindowManager wrapper objects for compatibility mode and for managing sub-windows. Removed the WindowManager.isHardwareAccelerated() method since it is never used. Change-Id: I4840a6353121859a5e0c07d5cc307a437c595d63
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
23e7c35ab5d43242d35b1019ce1a50bfb495cd27 |
|
20-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove dead code in window manager. The 'nest' parameter is always false so we can get rid of support for redundantly added views. Change-Id: I30c6a856797bdc72c4e1aa4cb26b930a33ce9a16
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
54ab347fdde0e4d14d923cca80e5bcc7b879fc52 |
|
14-Jun-2012 |
Romain Guy <romainguy@google.com> |
Don't create a giant layer for all notifications Bug #6642475 When expanding the status bar, create one layer per notification instead of a single giant layer for the pile of notifications. This prevents layer creation failure when the total height of the notifications is larger than the maximum allowed texture size in OpenGL ES 2.0. This change only enables layers on notifications that will be visible once the notification area is fully expanded. Change-Id: I3c791a66cf5ac0973f3a65cfcd84b95209d580f3
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
a53de0629f3b94472c0f160f5bbe1090b020feab |
|
09-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Add callback hack to find out when to load system properties. Use this to reload the trace and layout bounds properties. This is ONLY for debugging. Change-Id: I1c4bdb52c823520c352c5bac45fa9ee31160793c
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
79c6346100b555a8a3d51b3b1c34dbbe99305b9a |
|
28-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "When a window is first shown only draw once while animating." into jb-dev
|
4478de3c02c1fb2f4f888e696ee1b13721e936d9 |
|
28-Apr-2012 |
Jeff Sharkey <jsharkey@android.com> |
Clear IMM references when window dismissed. Match behavior of removeViewLocked(), where InputMethodManager clears any strong references to Views, and also clear mCurRootView. Without this, IMM can leak a DecorView instance after the user has left the application. Bug: 6413553 Change-Id: Iad09cf5dbb7f6f156fd39ed243431432e00f8945
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
12d3a94397c33fdb773a1eaaaa13cab80bf0c571 |
|
27-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
When a window is first shown only draw once while animating. On some hardware allocating a new graphics buffer is quite expensive, which blocks updates to the UI. This can cause glitches when performing window animations. To reduce these glitches, the view hierarchy will now only allow itself to be drawn once if its window is being shown while the window manager is animating, not resuming draws until it is told that the animation is done. Change-Id: Ie15192f6fddbd0931b022a72c76ddd55ca266d84
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
19f86e831ee0629b24385b0bb51d27ff91961dd2 |
|
24-Apr-2012 |
Romain Guy <romainguy@google.com> |
Invoke onTrimMemory with an EGL context Bug #6369600 Change-Id: I3ded47c3688ef2f2873495392c35e898357204da
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
162bc0ea0d7862b92f18d0ce47310a85304205f7 |
|
09-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Some small tweaks to improve memory management. We now allow processes that currently have stopping activities to be managed as if they were done stopping, so that memory trimming can be done before the process goes to the background. Hopefully this will reduce cases where the processes goes to the background and immediately gets killed, but wouldn't have had to be killed if it had a chance to trim its memory. Also change window memory trimming to always do the aggressive trimming when memory is critical, even if not on a low-end device. And tweak web view trimming to not trim for foreground UI events. Change-Id: I241b3152b52d09757bd14a202477cf69c9b78786
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
a3fabff98590d26f0c362cb09dc378fece66215c |
|
28-Mar-2012 |
Michael Jurka <mikejurka@google.com> |
Add frame counter to dumpGfxInfo Change-Id: I016f706e32cbdbce014795d8fc537b15c389dc7a
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
a998dff5d49a423aaf7097aa8f96bf5bdc681d25 |
|
24-Mar-2012 |
Romain Guy <romainguy@google.com> |
Destroy the hardware renderer when ViewRootImpl's die is post-poned Bug #6109035 ViewRootImpl.die() can be invoked in such a way that doDie() will be executed later. On memory limited device, an eglTerminate() may happen before doDie() is executed which leads to unstable behaviors. This change makes sure the renderer is destroyed as soon as possible. Change-Id: I3322410cdd744b464951e2055aeade6069d1d673
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
27ff913d56de8400083a13fc572e2812b32c890c |
|
06-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Work on more low memory reporting to apps. There are now some new trim memory levels that are sent to non-background applications as RAM becomes low. There is a new API for an application to retrieve information about memory trimming and such on demand. Fixed various checks against the memory trim level to be robust (not compare against exact values). Change-Id: Ifd1c6151124350168aef20a94e517166fd2e03eb
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
4a00ab2563d829822cf564c9a91bdc49db405b6e |
|
02-Mar-2012 |
Teng-Hui Zhu <ztenghui@google.com> |
Make sure egl context is valid for the onTrimMemory call It turns out that terminateHardwareResources can call into destroySurface to make the current context 0, like in Gmail. bug:6079959 Change-Id: I07b2f3e91d6276b6c8e1b48f72bc87d28337fe2f
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
d9624138723c55a0ac2af58a2e78e98cd51eba27 |
|
02-Mar-2012 |
Teng-Hui Zhu <ztenghui@google.com> |
Allow webview to delete GL resource in a valid EGL context bug:6079959 Change-Id: Idee1031b0bcc4aeb498a18eb01970a8ed7efd285
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
a676ad7e34c9afbaafaeca8c3fe96e95c518828e |
|
14-Feb-2012 |
Romain Guy <romainguy@google.com> |
New debugging tool in adb shell dumpsys gfxinfo This tool lets you visualize the time it took, in ms, to: - Build display lists ("Draw" phase) - Process display lists ("Process" phase) - Swap GL buffers ("Execute" phase) To use this tool: - adb shell setprop hwui.profile true - adb shell dumpsys gfxinfo <process name> - Copy the profile data and paste it in a spreadsheet - Generate a graph (stacked graph) and enjoy Change-Id: I7840c0ea0f153550425aa798e3ada2f357688cf5
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
211370fd943cf26905001b38b8b1791851b26adc |
|
02-Feb-2012 |
Romain Guy <romainguy@google.com> |
Add optional metadata to initiliaze the render threat. The render threat is likely to break your application if you initiate it. As such it must be explicitely requested using the following meta-data tag in your manifest's application tag: <meta-data android:name="android.graphics.renderThread" android:value="true" /> Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
/frameworks/base/core/java/android/view/WindowManagerImpl.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/core/java/android/view/WindowManagerImpl.java
|
31f2c2e94656530fbf6282803e62edb47e9a894d |
|
21-Nov-2011 |
Romain Guy <romainguy@google.com> |
Notify views when EGL resources are about to be destroyed Bug #5639899 Change-Id: I7c5d8bebf02294426f5b3ab1358a31c38a4fd064
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
717a25dc2a411edb548859cd6870363346c71b01 |
|
16-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Add new ManagedEGLContext class to help apps participate in memory trimming. This class provides an API for an application to know when it is time to destroy its EGL context when memory is being trimmed. By having this in the framework, we can still detect whether it will be useful to destroy any EGL contexts (because we know if doing so will destroy all of them). Change-Id: I1eac8d640052778052926b875c7928008f752182
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
8ff6b9ebeeb24a6161ec6098e6bfdf8790ee5695 |
|
10-Nov-2011 |
Romain Guy <romainguy@google.com> |
Terminate EGL when an app goes in the background This does not happen on high end gfx devices. This happens only if only one EGL context is initialized in the current process. Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
65b345fa22b878e141b8fd8ece9c208df00fa40f |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Reclaim more memory, more often. Yay. Change-Id: I04557ad575c307a55088549f48f0e9ad994b7275
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
6dd005b48138708762bfade0081d031a2a4a3822 |
|
18-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
I. Can. Not. Stand. ViewAncestor. It was done so we would have the name "ViewRoot" available for a public API. However, the name "ViewAncestor" just makes no sense. So instead, change it to ViewRootImpl. Change-Id: If9599ca67896f339f6fefa7d1dde121201171d97
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
bdf7609867a3f886455c51dba91623a86cceb6e2 |
|
19-Jul-2011 |
Romain Guy <romainguy@google.com> |
Trim OpenGLRenderer's memory usage whenever possible Change-Id: I9225077184f374b1a43300add15cc1d5b6869d1c
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
7bbf6f7d11877496502c20e8998a6984ab05cd39 |
|
10-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
am 8297f669: am 3aabdeac: am 5ba2e872: Merge "Fix for not reporting correct "sw" in compat mode." into honeycomb-mr2 * commit '8297f669356ee997c5faa745815e8b9a7009fba7': Fix for not reporting correct "sw" in compat mode.
|
f741e679c496f7345304a6543f01d7048e31d1a7 |
|
10-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of e2aa0490 to master Change-Id: Id0448a1598fc93aca0652b29253e02586e35a067
|
48a7651823030ed3c0f4c084b423430044425fea |
|
09-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix for not reporting correct "sw" in compat mode. Change-Id: Ia225c94b36ccc3589d417aafd5680247678eddfd
/frameworks/base/core/java/android/view/WindowManagerImpl.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/core/java/android/view/WindowManagerImpl.java
|
fee1c69a49d03b651e481983432ade94fc07650a |
|
26-May-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 77dd616e to master Change-Id: Idb7180177b01e7d822327ccc7c76617220860da2
|
5be8de3420ba4c9d816b98e29bdec11715f6b626 |
|
25-May-2011 |
Dianne Hackborn <hackbod@google.com> |
More compatibility mode improvements. We now correctly adjust display metrics, fixing for example issues seen in Barcode Scanner. In addition the decision about when to use compatibility mode has a bug fixed where certain apps would not go out of compatibility mode even though they should be able to. Change-Id: I5971206323df0f11ce653d1c790c700f457f0582
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
c6cc0f8c19d9eccf408a443fa2bf668af261dcd0 |
|
12-Apr-2011 |
Joe Onorato <joeo@google.com> |
Rename ViewRoot to ViewAncestor. ViewRoot is about to be a new public class for poking at ViewAncestor. Change-Id: Ie95d707c6d8bbb48f78d093d7b2667851812a7d5
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
43a17654cf4bfe7f1ec22bd8b7b32daccdf27c09 |
|
07-Apr-2011 |
Joe Onorato <joeo@google.com> |
Remove the deprecated things from Config.java. These haven't been working since before 1.0. Change-Id: Ic2e8fa68797ea9d486f4117f3d82c98233cdab1e
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
ce418e661ab52a08a2a2c3b2f10a4dd9adf33305 |
|
01-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3495749: Crash on choosing to open the downloaded images This is due to the window doing a relayout after its activity is stopped, at which point it may need to interact with the adapter to load data. The fix here is to tell ViewRoot about an activity being stopped and, if in this state, hold off on doing any new measurements and layouts of the hierarchy until it is no longer stopped. In this case the relayout was happening due to the cursor being deactivated, with causes the adapter to invalidate its data. Because this is now in a dialog window, this allows the window to actually be resized smaller (unlike when in a full screen activity), and boom. Change-Id: I26442b4679819b4a4e6bc56289afd3445526750b
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
7eec10e6c99c30d5ee061fec08ac89ad4254ac32 |
|
13-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Get rid of the extended themes. We now decide whether to use a bitmap background based on whether the window's drawing is hardware accelerated. To do this, there is a new "state_accelerated" that state list drawables can be parameterized on, and the standard window background uses this to select a solid color or bitmap drawable as appropriate. Introduces a little hackery to have wm preview windows pretend like they are hardware accelerated even if they aren't, so the preview looks closer to the actual app. Also Add a DialogWhenLarge variation for the light theme. Change-Id: I215a79d5df65ba3eed52ab363cade9d8218a6588
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
75986cf9bc57ef11ad70f36fb77fbbf5d63af6ec |
|
15-May-2009 |
svetoslavganov <svetoslavganov@google.com> |
Accessibility feature - framework changes (replacing 698, 699, 700, 701 and merging with the latest Donut)
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/WindowManagerImpl.java
|