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/core/java/android/view/WindowManager.java
|
a8e5a2bcd6a0d35893187c6df42425c03be005da |
|
28-Oct-2011 |
Chet Haase <chet@google.com> |
Optimize handling of scrolled wallpapers Swiping the home screen causes the WindowManagerService to do a bunch of work to keep the wallpapers in sync. First, it lays out and places all windows. Also, it notifies the SystemUI process that the wallpaper position has changed. The layout/place operation is too much work - we only need to set the position values for the wallpaper, not relayout the whole system. The notification mechanism must exist, but should be optional. Most wallpapers don't care (especially static ImageWallpapers). So we'll give them a new API (WallpaperService.Engine.setWantsOffsets()) to allow wallpapers to opt out of this process and avoid the performance overhead. Change-Id: I66c38375438937f14f6f5550565b28eb204b1e06
/frameworks/base/core/java/android/view/WindowManager.java
|
df89e65bf0fcc651d20b208c8d8d0b848fb43418 |
|
07-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix how we hide and show the nav bar. The PhoneWindowManager is now responsible for hiding and showing the nav bar. For hiding, it just moves it off the screen (easy way to get a nice slide animation on and off). At the same time, we use a new WM facility to put up a fake input window to capture all touch events. When a touch event is received, we force the system UI to clear the navigation hiding bit so it will be shown again. This removes a bunch of code from the system UI for hiding and showing the nav bar. Also removes the code calling from userActivity() to the system UI, which was bad. (Also no longer using userActivity() fixes bugs around re-showing the nav bar due to key presses and other wrong things.) Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
/frameworks/base/core/java/android/view/WindowManager.java
|
40e0383dce630ed9b2b1aa0e497709b89dfab6ef |
|
06-Oct-2011 |
Chet Haase <chet@google.com> |
Fix issue #5384631: hw windows not resizing correctly When the SystemUi becomes visible, the activity window resizes. The hardware renderer was not begin resized to suit, so it was drawing to a surface larger than that of the activity window, and some of the rendering (like the action bar) appeared off the screen. The fix is to keep track of the surface size in HardwareRenderer and to recreate the surface when the size changes. This change also removes the BUFFER_CHANGE flag from WindowManager.LayoutParams. The only reason the flag existed was to trigger a hardware surface recreation, but checking the old/new size is a more direct way of handling this. Change-Id: I9d6bf6385794886d1d93c60609c170864cdcdfab
/frameworks/base/core/java/android/view/WindowManager.java
|
bfcb60ab0f696c8ef70830c365550e62fe2808bf |
|
09-Sep-2011 |
Jeff Brown <jeffbrown@google.com> |
Adjust layers for system overlays. Prevent system overlays from showing above the notification bar. Allow secure system overlays to be fullscreen, for the pointer location view. Show the drag layer above the notification bar. Change-Id: Ic8d663792a243cca2cd9952d241d001e0357d551
/frameworks/base/core/java/android/view/WindowManager.java
|
f21c9b0f52d5a1de5050f90f0818467fad014eaa |
|
07-Sep-2011 |
Romain Guy <romainguy@google.com> |
Don't destroy a window's buffers when moving it Change-Id: Ib08608373ae4299639c1b157421ba633e4293446
/frameworks/base/core/java/android/view/WindowManager.java
|
5d927c2d8e832fcfcb0154c8741f896001141ef4 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5150899: Call activity takes 15MB we never get back. Persistent process can no longer use hardware acclerated drawing when running on a low-memory device. Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
/frameworks/base/core/java/android/view/WindowManager.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/core/java/android/view/WindowManager.java
|
29aae6f36e565b8f2a99f2193597b964bb800ee8 |
|
19-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4279860: previous UI flashes before showing lock screen... ...(when turning display on after recently turning it off) Also clean up when we decide to turn the screen on to improve that transition. There are still problems here with turning it on before the wallpaper gets dispayed. Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
/frameworks/base/core/java/android/view/WindowManager.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/core/java/android/view/WindowManager.java
|
e8ecde10b33b1d050d2b63b3f4cd20e8bb7c96d4 |
|
04-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Whoops also need to move notification shade above lock screen. And this requires making a new layer for the volume toast. Change-Id: I4f272d56c87cf3b6bf886774b0fb02e610ab9164
/frameworks/base/core/java/android/view/WindowManager.java
|
474dcb5c3ddff737c4ac9fc44a1f7be569605e5f |
|
15-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Add support for disabling pointer gestures. Made it possible for individual windows to disable pointer gestures while the window has focus using a private API. Cleaned up the InputReader configuration code to enable in-place reconfiguration of input devices without having to reopen them all. This change makes changing the pointer speed somewhat nicer since the pointer doesn't jump back to the origin after each change. Change-Id: I9727419c2f4cb39e16acb4b15fd7fd84526b1239
/frameworks/base/core/java/android/view/WindowManager.java
|
98db5fabdad86dca379740d8050697950b9f026c |
|
09-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Allow touches to slide out of the navigation bar. Change-Id: I73cabba3d62f47829bf6217700ace56a27c42b1d
/frameworks/base/core/java/android/view/WindowManager.java
|
9e3b002d3f9141d54948a65e0330fdcd09e75a30 |
|
07-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Rename Gravity BEFORE/AFTER to START/END - following spec proposal for having CSS3 like naming Change-Id: Id5e316a2d9b54b9f20bbcb168fea6a3a83882e1b
/frameworks/base/core/java/android/view/WindowManager.java
|
6a03640539405afbdefe72894759281b98aa6e6f |
|
23-May-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add support for Gravity BEFORE and AFTER - update layouts - add Callback2 for RTL aware Drawable - add unit tests Change-Id: Ic64d0291e262170aff7297c6580b0b422eaa8d89
/frameworks/base/core/java/android/view/WindowManager.java
|
8956dbbc5f292d8b79072ae73b25f2114c8c7479 |
|
22-Apr-2011 |
Daniel Sandler <dsandler@android.com> |
On-screen navigation bar (separate from the status bar). In Honeycomb we introduced navigation controls in the status bar, for xlarge devices without physical buttons. What about phones? The status bar is pretty cramped already, and besides, it's at the top of the display most of the time, not at the bottom where your thumb is likely to be. Enter the navigation bar. It's a new window type that appears atop almost everything (including the keyguard); the window manager subtracts its rectangle from the default visible rectangle of other windows (including the status bar and notification shade). However, it behaves (on phones) like the status bar in that applications that request fullscreen windows can get access to those pixels. Well, almost; they need cooperation from the navigation bar implementation to make the navbar disappear, just like the status bar. The current SystemUI implementation of the navigation bar on phones is still rough, but it has the basics: + back, home, and menu keys (NB: we're showing menu all the time right now because checking the api level of the package owning the top window is currently a poor indicator of whether the app requires the menu key) + it tries to stick to the same physical end of the device, regardless of device orientation (on a phone, this is the strip of land closest to the microphone) Change-Id: Ic613a3351220af0bbfbdef63e1d99cbefd5ed1c2
/frameworks/base/core/java/android/view/WindowManager.java
|
3fa8a454f61c772036f5f38661d1a077fd3d8388 |
|
10-Mar-2011 |
Jim Miller <jaggies@google.com> |
Fix 3201849: Enable hardware acceleration in LockScreen WaveView Change-Id: Id64e82fe2e09ac231736d7867cd47b504d79b81b
/frameworks/base/core/java/android/view/WindowManager.java
|
d6f5bde96b2fe82bc7e5d4e64266d585108c4648 |
|
20-Jan-2011 |
Glenn Kasten <gkasten@google.com> |
Protected surface API To be used by DRM framework, implemented by display HAL Change-Id: I054a07a94f4d5dbe792f3a597e2e49a100d90eb2
/frameworks/base/core/java/android/view/WindowManager.java
|
a4a5ec5e748f99c40301c9c422b3d36cb44c6081 |
|
26-Jan-2011 |
Joe Onorato <joeo@google.com> |
am 1aadb210: Merge changes I48392c75,Id09437a4,I4a0aa878 into honeycomb * commit '1aadb2108d7614d9d1ff61b41c6c31cb8d211ab9': Expose the window flags for lights out mode. Make TabletStatusBar call into StatusBarManagerService when it goes out of lights out mode on its own. Make FLAG_FULLSCREEN not go into lights out mode anymore.
|
14782f705e94d4e563a48efc85fd25129fd38a7d |
|
26-Jan-2011 |
Joe Onorato <joeo@google.com> |
Expose the window flags for lights out mode. I hadn't wanted to do this, but it makes porting the FLAG_FULLSCREEN stuff over to this simpler because you don't have to go find a view to proxy through. This change also clears the flag everywhere when the window manager notifies the views that the change has come back. Change-Id: I48392c7550925bcca50c5bb9e1f263e99de6c7bc
/frameworks/base/core/java/android/view/WindowManager.java
|
faf083ef0b7b893acb871084231d20e08e208f8f |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
am 4c541b13: Merge "visibility ("lights out") API." into honeycomb * commit '4c541b1303b0ee2b9b0d19bee85d3780c5c4c110': visibility ("lights out") API.
|
664644d9e012aa2a28ac96f305b1ce6499ec8806 |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
visibility ("lights out") API. 1. Views may setSystemUiVisibility() to recommend that the system chrome (status bar or other UI) show or hide itself. (This functionality was previously available only via the FLAG_FULLSCREEN window flag for some SystemUI implementations.) 2. Views may register a OnSystemUiVisibilityChangedListener on a view, and find out when the system UI actually appears or disappears, allowing apps to coordinate the appearance of their own UI if desired. Bug: 3241144 Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
/frameworks/base/core/java/android/view/WindowManager.java
|
8a82de2fcae11a2a9cba25132c37cad83ccc859f |
|
21-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
am 4bb180d6: am ded2b006: Merge "frameworks/base: remove redundant code in WindowManager" * commit '4bb180d62f71658d04a7d6800707de83c10b01a5': frameworks/base: remove redundant code in WindowManager
|
be2c4f92a990ca48ad6ede252343dd9574dfe505 |
|
18-Jan-2011 |
Gilles Debunne <debunne@google.com> |
Race condition patched in Email autocompletion. Bug 3347962 Root cause of this problem: if the adapter's content gets updated by a backgroung thread, the PopupDataSetObserver will call showDropDown which will popup the list. Added a flag to make this call show the popup iif it is already visible. This relayout is needed to clear the mDataChanged flag set when the content was modified and which otherwise prevents touch events on the result list. ArrayAdapter didn't use its lock to protect access to mObject. ------------------------------------------------- However, the study of the this race conditions revealed an other bug: Updated adapter's content is not displayed in filtered AutoCompleteTextView Bug 3369097 Change-Id: Icd90d452f98231866f4d8a1f6994c1492febecb9
/frameworks/base/core/java/android/view/WindowManager.java
|
3f6875f143fbaf4de993025f6765dc8237eb2b0b |
|
18-Jan-2011 |
Vairavan Srinivasan <vairav@codeaurora.org> |
frameworks/base: remove redundant code in WindowManager Change-Id: I8a356ca36129645977d33129e0d56c1b89f97fb0
/frameworks/base/core/java/android/view/WindowManager.java
|
72f0a276ffd5f3d6513400e50de1a8bda547bed4 |
|
10-Jan-2011 |
Romain Guy <romainguy@google.com> |
Better documentation for FLAG_HARDWARE_ACCELERATED Bug #3154883 Change-Id: I2062781ba3b447b8ec4e0836b9ddeaa97c7aa60e
/frameworks/base/core/java/android/view/WindowManager.java
|
83c09685f2e62bc3cf7e71bc61d903f4b9ccaeb4 |
|
24-Dec-2010 |
Jeff Brown <jeffbrown@google.com> |
Add initial support for cursor-based pointing devices. Some parts stubbed out but you can plug in a mouse and move a green cursor around to interact with the UI. Change-Id: I80d597a7f11d3bd92041890f74b3c77326975e6e
/frameworks/base/core/java/android/view/WindowManager.java
|
d2112306330ce0c162bee4b864991962ca2b655a |
|
08-Dec-2010 |
Mathias Agopian <mathias@google.com> |
remove support for PUSH_BUFFER surfaces and overlays the same functionality is now supported through the h/w composer HAL, and YUV support in the GPU. Change-Id: I8146605449954b8e8fd7f78810b7d873c2d8f5bf
/frameworks/base/core/java/android/view/WindowManager.java
|
a89e903fd4b84778e1a7f2268fe025fe66a6e45e |
|
24-Nov-2010 |
Joe Onorato <joeo@google.com> |
this should be @hidden Change-Id: Ib372fa15a5284b30e2edef5a1d90544eb2166ee4
/frameworks/base/core/java/android/view/WindowManager.java
|
29fc2c9705e1bb8ae098fca016032d2325031587 |
|
24-Nov-2010 |
Joe Onorato <joeo@google.com> |
Allow status bar panels to be on top of the status bar. Change-Id: I3c74ece5f7042e6302717f4263746d59d5447ec9
/frameworks/base/core/java/android/view/WindowManager.java
|
8e11ef0d949a52fec15359ec35557b2e773b093d |
|
19-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Some work on issue #3201795: Improve transition when keyboard comes up Now try to slide dialogs if they end up moving due to the IME (or other system things) showing/hiding. Pretty hackish, but seems to work. Change-Id: Icd297e941cf847fa920c9605145c46be63043d52
/frameworks/base/core/java/android/view/WindowManager.java
|
d9b3b7e8e1d8c919c3e5f5851daa80a2651ea7d1 |
|
17-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3202866: system server crash Change-Id: Ied92164bea70f6cb8afe2c1c6ff4fc3836a209ab
/frameworks/base/core/java/android/view/WindowManager.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/WindowManager.java
|
8eb2e244f9b14d946ee587d0b673b866865026c0 |
|
01-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Various PreferenceActivity and related improvement. This is all about making the preferences implementation better. Well, mostly all about that. Change-Id: I8efa98cb5680f3ccfa3ed694a1586de3fb3a9e11
/frameworks/base/core/java/android/view/WindowManager.java
|
dea3ef7967228f0ddcc03f2455a4f1254758e584 |
|
28-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Add new resize mode to not resize, new web input types. Change-Id: Ib098c03793d08532c3c099b59d0cc6b567e54900
/frameworks/base/core/java/android/view/WindowManager.java
|
3b2b354ec1ba070eae13391d004d97a3e1403050 |
|
15-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for secure system overlays. Manual merge from Gingerbread. This change adds a new window type for secure system overlays created by the system itself from non-secure system overlays that might be created by applications that have the system alert permission. Secure views ignore the presence of secure system overlays. Bug: 3098519 Change-Id: Id876736fd8bf332ff9a5428bde59f5268aa49c3a
/frameworks/base/core/java/android/view/WindowManager.java
|
2d3f159aa9622e05a18e7f93cecd57ad673955ae |
|
15-Oct-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for secure system overlays. (DO NOT MERGE) This change adds a new window type for secure system overlays created by the system itself from non-secure system overlays that might be created by applications that have the system alert permission. Secure views ignore the presence of secure system overlays. Bug: 3098519 Change-Id: I8f8398f4fdeb0469e5d71124c21bedf121bd8c07
/frameworks/base/core/java/android/view/WindowManager.java
|
e02d808abf370965c3c4e4d38af11bc69110fde2 |
|
08-Oct-2010 |
Daniel Sandler <dsandler@google.com> |
Dynamically show the menu button on the system bar. Windows with FLAG_NEEDS_MENU_KEY (or windowNeedsMenuKey=true in their theme) will cause the system bar to show a menu icon. (Note that the phone's status bar currently ignores this, but phones tend to have hardware menu keys anyway.) Additionally, all windows whose package's SDK version is pre-Honeycomb will have FLAG_NEEDS_MENU_KEY set by default. Bug: 3003728 Change-Id: I2d983763a726ea4f32cd1af9b0390e30478b11d1
/frameworks/base/core/java/android/view/WindowManager.java
|
a53146c5569f8ff5f7eb55e9ad35d23ddacf2add |
|
07-Sep-2010 |
Christopher Tate <ctate@google.com> |
Drag/drop APIs and infrastructure A View initiates a drag-and-drop operation (hereafter just called a "drag") by calling its startDrag(ClipData) method. Within the processing of that call, two callbacks are made into the originating View. The first is to onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this callback must respond by calling setDragThumbnailDimension(width, height) to declare the size of the drag thumbnail image that should be used. Following this, the View's onDrawDragThumbnail(canvas) method will be invoked to actually produce the bits of the thumbnail image. If all goes well, startDrag() will return 'true', and the drag is off and running. (The other arguments to startDrag() provide reconciliation between the current finger position and where the thumbnail should be placed on the screen relative to it.) Potential receipients of the ClipData behind the drag are notified by a new dispatch mechanism, roughly parallel to motion event dispatch. The core routine is the View's onDragEvent(event) callback, with the mechanics of dispatch itself being routed through dispatchDragEvent(event) -- as in the case of motion events, the dispatch logic is in ViewGroup, with leaf View objects not needing to consider the dispatch flow. Several different event 'actions' are delivered through this dispatch mechanism: ACTION_DRAG_STARTED: this event is propagated to every View in every window (including windows created during the course of a drag). It serves as a global notification that a drag has started with a payload whose matching ClipDescription is supplied with the event. A View that is prepared to consume the data described in this event should return 'true' from their onDragEvent() method, and ideally will also make some visible on-screen indication that they are a potential target of the drop. ACTION_DRAG_ENTERED: this event is sent once when the drag point enters the View's bounds. It is an opportunity for the View to set up feedback that they are the one who will see the drop if the finger goes up now. ACTION_DRAG_LOCATION: when the drag point is over a given View, that View will receive a stream of DRAG_LOCATION events, providing an opportunity for the View to show visual feedback tied to the drag point. ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point leaves the View's bounds. The View should undo any visuals meant to emphasize their being the hovered-over target. ACTION_DROP: when the drag ends at a given point, the View under that point is sent this event, with the full ClipData of the payload. ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global broadcast that the drag has ended and all Views should return to their normal visual state. This happens after the DROP event. Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
/frameworks/base/core/java/android/view/WindowManager.java
|
464fb74e28b6d76d5e741abcdbb714eea2d9b4d1 |
|
27-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
am 9785bf0f: am 14a288da: Merge "Add suuport for splitting touch events across windows." into gingerbread Merge commit '9785bf0f2b6b8758aed7ded3b996a2ef0be89919' * commit '9785bf0f2b6b8758aed7ded3b996a2ef0be89919': Add suuport for splitting touch events across windows.
|
01ce2e9eee41cc0c24b0d16465710a28ea337d5d |
|
27-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
Add suuport for splitting touch events across windows. This feature is currently used to enable dragging the start and end selection handles of a TextView at the same time. Could be used for other things later. Deleted some dead code in ArrowKeyMovementMethod and CursorControllers. Change-Id: I930accd97ca1ca1917aab8a807db2c950fc7b409
/frameworks/base/core/java/android/view/WindowManager.java
|
529b60a3b16ac3dff24f2403d760ab8ebc9670ff |
|
04-Aug-2010 |
Romain Guy <romainguy@google.com> |
Add android:hardwareAccelerated to Activity. Hardware acceleration can now be enabled/disabled locally on each activity declared in the manifest. It can also be enabled/disabled directly on a window through the WindowManager.LayoutParams. Change-Id: I91dd0b26c4e7eb8cd7288e523ed6b7bda6d0990b
/frameworks/base/core/java/android/view/WindowManager.java
|
613dde4aa651e11dac3db859723cc6faf8fc0a82 |
|
21-Jun-2010 |
Daniel Sandler <dsandler@android.com> |
Revised "immersive mode" API. No longer a window bit, FLAG_IMMERSIVE is now set on ActivityInfo.flags and in the Activity's manifest as android:immersive="true" (ActivityInfo). [An "immersive" activity is one that wishes to avoid being paused by full-screen notifications (like an incoming call). An activity that sets FLAG_IMMERSIVE/android:immersive is sending a signal to the notification manager, status bar, etc. that they should try to find some other way to get the user's attention in high-priority situations.] [Originally: change Ie290c2e.] Change-Id: I967bb10b930b8f0772b10f81f2957a03fa3f1736
/frameworks/base/core/java/android/view/WindowManager.java
|
ae069f76ee65fd5d9252c8191429fa55296d0208 |
|
18-Jun-2010 |
Daniel Sandler <dsandler@android.com> |
Fix SDK docs build. Change-Id: I2d11682cdf2cdcd48f0299f8c168fddd5994dc65
/frameworks/base/core/java/android/view/WindowManager.java
|
611fae4c39edbeb23b53f789a0219c539cf32fa6 |
|
17-Jun-2010 |
Daniel Sandler <dsandler@android.com> |
New API for "immersive" activity windows. An "immersive" activity (as indicated by the new FLAG_IMMERSIVE) is one that wishes to avoid being paused by full-screen notifications (like an incoming call). An activity that sets FLAG_IMMERSIVE on its window is sending a signal to the notification manager, status bar, etc. that they should try to find some other way to get the user's attention in high-priority situations. FLAG_IMMERSIVE should be used exclusively in conjunction with FLAG_FULL_SCREEN (that is, only activities that hide the status bar should consider themselves immersive). Change-Id: Ie290c2e92fc391bcf55edfdb1fbd626cd284e3e2
/frameworks/base/core/java/android/view/WindowManager.java
|
f10e6331e3bf01653235d93aa523056c146a85a3 |
|
11-Jun-2010 |
Scott Main <smain@google.com> |
docs: fix markup error Change-Id: Icea017095f58068c55dd3c1c18cecbdf06afb595
/frameworks/base/core/java/android/view/WindowManager.java
|
20e9271cf25e48d8ea17bed74e87465ca3d77b8c |
|
02-Apr-2010 |
Daniel Sandler <dsandler@android.com> |
Add more WindowManager flags to ViewDebug. Bug: 2567955 Change-Id: Ia34aaa3cbf6e2bc2e59fe9ae83e4c8a6498612ca
/frameworks/base/core/java/android/view/WindowManager.java
|
8f2bd4328a7cc9dd70e597b7cc011be22c6ca566 |
|
25-Mar-2010 |
Joe Onorato <joeo@android.com> |
Add window flags and window types to hierarchyviewer. For debugging http://b/issue?id=2544870 Change-Id: I4b7775e6fd275bb7a9041bf5736e076122bfb5f1
/frameworks/base/core/java/android/view/WindowManager.java
|
95f7850a9d9c7c4f020d06986300f4740fb6a52c |
|
30-Jan-2010 |
Christopher Tate <ctate@google.com> |
Fix build: javadoc @link pointers need HTML-style #refname Change-Id: I0e061516fce2bcf5dea401f58180f2ff396482ab
/frameworks/base/core/java/android/view/WindowManager.java
|
ef73162887943e16587b8e737b19e59348338e8c |
|
27-Jan-2010 |
Mike Lockwood <lockwood@android.com> |
Support for triggering the lockscreen while the screen is on: Add new ALLOW_LOCK_WHILE_SCREEN_ON window manager flag, which when set causes the window manager to put up the lockscreen after the normal screen timeout has elapsed. Add plumbing to pass PowerManager.userActivity() to the window manager policy. Change-Id: I05adc52bad39c56031a08e8ec3cbcf5c2d9b9827 Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/core/java/android/view/WindowManager.java
|
980a938c1c9a6a5791a8240e5a1e6638ab28dc77 |
|
09-Jan-2010 |
Romain Guy <romainguy@android.com> |
Deprecate fill_parent and introduce match_parent. Bug: #2361749.
/frameworks/base/core/java/android/view/WindowManager.java
|
fb73f79340375013225618a5d87f46b958f698ef |
|
20-Nov-2009 |
Mike Lockwood <lockwood@android.com> |
Add window manager support for overriding button and keyboard backlight values. The new backlightBrightness field works similarly as the existing WindowManager.LayoutParams.screenBrightness field Needed for bugs: b/2233655 (under low ambient light the touch keys remain illuminated during video playback and never timeout) b/2221079 (Backlight for home/search/back/etc buttons should turn off when in dock in night mode) Change-Id: I60dfecdc7bb653b0db38094464de651220b3d438
/frameworks/base/core/java/android/view/WindowManager.java
|
badc47ecd1677d5f53bb16f8f30c158a879f5832 |
|
09-Nov-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2242440: Window screen brightness attribute is broken Um okay, that was dumb. And I guess this means it is time to make 6.xml. Change-Id: Ic42763b1c8a13448cf6db20b4cd6daadc7786ac1
/frameworks/base/core/java/android/view/WindowManager.java
|
3b3e145d3c41fd68974e08f799b1fd1f8f060cf0 |
|
25-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
A variety of work on animations. - The lock screen now fades in and out. - Fixed a bug where we would accidentally freeze the screen when switching to an activity with a different orientation than the current (but the screen itself is in the current orientation). This would mess up the animations on the car dock. - New API to force a particular animation for an activity transition (untested). - New wallpaper animations. - Resources now uses the next API version when in a development build, to help applications being developed against such builds. Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
/frameworks/base/core/java/android/view/WindowManager.java
|
9bfb707597898f54722460b48588007b682f3e2a |
|
22-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Various fixes and improvements to window, activity. - New meta-data you can add to a dock activity to have it launched by the home key when the device is in that dock. - Fix a deadlock involving ActivityThread's internal content provider lock. - New window flag to have a non-secure keyguard entirely dismissed when a window is displayed. - New WindowManagerPolicy APIs to allow the policy to tell the system when a change it makes during layout may cause the wall paper or overall configuration to change. - Fix a bug where an application token removed while one of its windows is animating could cause the animating window to get stuck on screen. Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
/frameworks/base/core/java/android/view/WindowManager.java
|
93e462b79d6896da10e15e74c5aec6beb098dddf |
|
16-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #1780928: Need support hiding nav keys. This implements support for devices whose hardware can hide their navigation keys. It works much like the existing keyboardHidden configuration, and for compatibility uses the same configuration change bit. Also add FLAG_TURN_ON_SCREEN for windows, which has the system cause the screen to be turned on when the window is displayed. Great fun when used with FLAG_SHOW_WHEN_LOCKED! Change-Id: I0b867f19af85cfd8786a14cea194b34f7bdd9b7a
/frameworks/base/core/java/android/view/WindowManager.java
|
317a6280cc109e873646e4652be1582d870eedfd |
|
14-Aug-2009 |
Mathias Agopian <mathias@google.com> |
Surface::GPU and Surface::HARDWARE are now deprecated; they will be set automatically if needed. this also ripples into the window manager API by making some constant there deprecated as well.
/frameworks/base/core/java/android/view/WindowManager.java
|
4c62fc0e1e5ea9c69a12a7d1cf8b3ec8b2d114a3 |
|
09-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Very primitive wallpapers in a surface. This is all of the basic pieces: - The WallpaperService now creates a surface with the window manager for its contents. - There is a simple service that displays a bitmap. - The wallpaper manager takes care of starting and stopping the service. - The window manager knows about wallpaper windows and how to layer them with the windows that want to be shown on top of wallpaper. Lots and lots of issues remain, but at this point you can actually write a wallpaper service, select it in the UI, and see it behind an activity.
/frameworks/base/core/java/android/view/WindowManager.java
|
61324e58c549670c015010d0be14c6af76e3e9f7 |
|
22-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
cast is floor. Use round instead. This fixes a few layout issues (that was due to smaller widnow size)
/frameworks/base/core/java/android/view/WindowManager.java
|
841f13c8e9ff3f7695b6c18a8abcec3c947983ff |
|
18-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
* Reverted the change in PackageParser that I checked by accident * More surface view fix. - correct event translation on surface view. - use compatible window * removed FLAG_NO_COMPATIBILITY_SCALE. It was my misunderstanding of how SurfaceView works, and this was not necessary. * Added compatibility related info to package dumpsys
/frameworks/base/core/java/android/view/WindowManager.java
|
5a2b91dc14e4c92e91c6abcc795f54ac98ee5866 |
|
17-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
* Use Fede In/Out animation if one of opening/closing apps is in compatibility mode. * preserve compatibility window flag when the app updates window's layout params. * Added assertion in DEFAULT_COMPATIBILITY_INFO object to prevent unintentional modification. * A few minor updates * log/dump message improvement * Removed unnecessary method in FadeInOutAnimator * Fixed 100 char issue in WindwoManagerServer.java
/frameworks/base/core/java/android/view/WindowManager.java
|
1ecf5d28817f0a051e77488380dcd5bc622ea169 |
|
07-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
Re-implementation of large screen support using window manager. * added background filler surface to fill the outer rim. Using the same layer as dim surface because they never co-exists (in the same window) * clean up the obsolete code in CompatibiltyMode/ViewRoot for support large screen support.
/frameworks/base/core/java/android/view/WindowManager.java
|
64f59342d41849bd365cb43fad7505d5e3daa417 |
|
21-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
* new screen resolution support impl. * use full window for activities, and shift & clip the content * refactored the compatibility code, and introdcued Translator class to handle cooridnate translations. * removed a workaround to handle an activity with configChagne=rotation in old implementation. * I'll fix background issue on rotation in next CL. * removed unnecessary scaling code in SurfaceView, which I forgot to remove when I changed SurfaceView not to scale the content.
/frameworks/base/core/java/android/view/WindowManager.java
|
7299807d1895ea25cbe45d32b6edfd9a5723ee7a |
|
22-Jun-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1933585. Don't dismiss ACTV's drop down when it's set to alwaysVisible. This change also resizes the drop down automatically whenever the soft input method is shown/hidden.
/frameworks/base/core/java/android/view/WindowManager.java
|
e5fb328825995aa33b5b7ecf8b5bee2b17f81715 |
|
10-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
resolution support fix/improvement * adding compatibility menu * backup gravity * set expanable=true if the screen size is hvga * density. * added "supports any density" mode. I'll add sdk check later. * disallow to catch orientation change event if the app is not expandable. This was causing layout problem under non-expandable mode. I discussed this with Mike C and we agreed to do this approach for now. We'll revisit if this causes problem to a lot of applications.
/frameworks/base/core/java/android/view/WindowManager.java
|
c4d5d02667af6989a3121072871f6a4b1e68b594 |
|
22-May-2009 |
Dianne Hackborn <hackbod@google.com> |
Add new window manager type for a hacking second-level media surface. This adds a new window type that is a surface that sits between the current media type and the application window, in theory allowing you to have two surface views in your hierarchy and control their Z-ordering. There is also another hidden API on SurfaceView to set the type of your window. All a big hack, but for the good of the commonwealth!
/frameworks/base/core/java/android/view/WindowManager.java
|
d1a9337380cf9f40f1aa095457b11242d483295d |
|
15-May-2009 |
Suchi Amalapurapu <asuchitra@google.com> |
Add a new window flag to display a window when keyguard is shown.
/frameworks/base/core/java/android/view/WindowManager.java
|
3d91492d694cf00474fec792134e496be6ee0313 |
|
14-May-2009 |
Mitsuru Oshima <oshima@google.com> |
fix window layout problem in ViewRoot * don't scale LayoutParams (this must be app's scale). * scale the layout params' coordinates & size only when requesting layout. In SurfaceView, window's x,y wasn't scaled before sending to window manager.
/frameworks/base/core/java/android/view/WindowManager.java
|
8169daed2f7a8731d478b884b1f455c747b88478 |
|
29-Apr-2009 |
Mitsuru Oshima <> |
AI 147976: Compatibility mode support. Part 2. * Introduced ApplicationScale (may not be good name. CompatibilityScale? CanvasScale? Pls let me know if you have better idea) * Changes to RootView / SurfaceView - Makes the app believe it's running in the supported density/resolution. - Makes the window manager believe it's running at the right density/resolution. * Added methods to Rect/Event for scaling up/down. Known issues: * certain kind of images (such as nine patch for buttons) seesm to be loaded not by app, thus does not take the scale into account, which, in turn, is causing layout issue. * ZoomButton in MapView is rendered in wrong place * Transparent region on Surface is not correct * Specifying different densities in one process is not working. BUG=1770627 Automated import of CL 147976
/frameworks/base/core/java/android/view/WindowManager.java
|
8d112675879a2b83197d3b4ae4fb623abd1a1ec3 |
|
27-Apr-2009 |
Mitsuru Oshima <> |
AI 147845: Compatibility mode support. Part 1 Adding supports-density tag to manifest file/ApplicationInfo. BUG=1752478 Automated import of CL 147845
/frameworks/base/core/java/android/view/WindowManager.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/WindowManager.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/WindowManager.java
|
3001a035439d8134a7d70d796376d1dfbff3cdcd |
|
19-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@132276
/frameworks/base/core/java/android/view/WindowManager.java
|
da996f390e17e16f2dfa60e972e7ebc4f868f37e |
|
13-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@131421
/frameworks/base/core/java/android/view/WindowManager.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/view/WindowManager.java
|
9266c558bf1d21ff647525ff99f7dadbca417309 |
|
16-Jan-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@126645
/frameworks/base/core/java/android/view/WindowManager.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/WindowManager.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/WindowManager.java
|