77bdfb512f963701082c5c78e9a9db00b167fcb6 |
|
03-May-2016 |
Robert Carr <racarr@google.com> |
Prepare to replace windows across recreate(). When the activity locally recreates itself, nothing on the server side is able to prepare preserving windows, or replacing windows. The activity was trying to defer removing the old window, but it was just waiting until the new one was created, not until it was drawn, thus resulting in a flicker. It's easy to backpack on the existing replacement infrastructure. Bug: 28221875 Change-Id: I55fc4ca78e9e11809473fedd8b30b6a6350cf852
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
0b10c335c72cb610e71432a61f315e7670b9af41 |
|
29-Mar-2016 |
Robert Carr <racarr@google.com> |
Ensure we change SurfaceView size from UI thread. We need to change the SurfaceView size from the UI thread so that we can appropriately deliver the SurfaceChanged callback. We also need to not preserve geometry in this case, as if we don't update the surface and layout size together we could get scaling. This still has some potential for holes, as transactions are not synced with the parent renderer, but we have other methods to avoid these in the case of resizing. This fixes the remaining issues with content sizing and surface view "out of sync". Bug: 27780983 Bug: 27687126 Bug: 27676101 Change-Id: Idd7864f00e5cf7a4eb32dd66c0b389292a788069
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
6136273888c42faad74dce19ec49904a55affc15 |
|
22-Mar-2016 |
Chong Zhang <chz@google.com> |
Don't change geometry in relayout if preserve geometry is requested This causes scaling to be applied in the relayout window since the requested size won't match the window size. Apply the requested size in repositionChild instead. bug: 27676101 Change-Id: I03beee2b9fe118a6be329b5fd1338d54e48d9a22
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
989b58a633ed6f2192a172855525d86477452884 |
|
10-Feb-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Update pointer icon when View.setPointerIcon is called Currently the updated pointer icon is only displayed after the next mouse move. Bug:27107871 Change-Id: Ieed57b07fe44699735179cf57968a9bb08981396
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
ba761124e624ffed2681a9e171cd3f7d8c6ed59e |
|
22-Jan-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Change mouse pointer when drag and drop is active Mouse pointer is set to STYLE_GRAB when the drag has started and reset to STYLE_DEFAULT when the drag has ended. Resetting the pointer shape to the one defined by an underlying view will be handled in a separate patch. Bug: 24415739 Change-Id: I8df0a08c5701a34a48f10ec6b43c2cf2e6362d61
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
0102a8a8e957c38e8fe40e6cd184339ea9f38906 |
|
19-Jan-2016 |
Rob Carr <racarr@google.com> |
Merge "Replace SurfaceViews across resize trigerred relaunches."
|
23fa16b759f023ea18ab9f84e89df50d4b449dfd |
|
13-Jan-2016 |
Robert Carr <racarr@google.com> |
Replace SurfaceViews across resize trigerred relaunches. In resize modes where we are preserving the main application window, we need to tell the WindowManager to prepare to replace the child surfaces, or they will dissapear across relaunches. Bug: 26070641 Change-Id: I864168688dc320e9280e651f9c5df614f52bc96c
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
2e95a488e0a12d4263d101e888fdd89fd123aec3 |
|
15-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
More optimization while dragging docked divider - Make sure mPendingBackdropFrame gets also set when if the window triggers a relayout on it's own, so it doesn't call into window manager all the time. - Set the insets of the docked divider to empty so we don't trigger a layout when we are just moving it - it doesn't need it in any case. - Send a window move message to the divider when it moved - Update attach info in all move cases, update light center The whole resize operation now only takes around 4ms per frame, and leaves a lot more resources for the apps to do configuration changes. Bug: 25015474 Change-Id: Ica48129570a0fc858a89c21f46abf3442efb0224
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
82063913ae6d3b158cb0c599141e473b691363a8 |
|
20-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement View.cancelDragAndDrop View.cancelDragAndDrop cancels a drag operation initiated by View.startDragAndDrop. It has to be called on a View in the same window (under the same ViewRootImpl) that the view which started the drag. Bug: 24415683 Change-Id: If9a265fd8cc4d26b207d582d0d02d5c9ae78eba1
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
54d6b95e86e9b248dd313ab72f4db6a681480d1e |
|
19-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Revert "Implement View.cancelDrag" This reverts commit 93cf731b26e2ab4db49bd80f60675b03e40512f3. This is required because adding View.cancelDrag conflicts with existing app code. Change-Id: I323fc5d2144266781d3168fe033c53cb5b37050e
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
93cf731b26e2ab4db49bd80f60675b03e40512f3 |
|
06-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement View.cancelDrag View.cancelDrag cancels a drag operation initiated by View.startDrag. It has to be called on a View in the same window (under the same ViewRootImpl) that the view which started the drag. Bug: 24415683 Change-Id: Iae5ff3534b6c747ae174f170fdd01ff4d3b1c312
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
64aadd08491172e90f6d6512d8affc9a4cfa04cc |
|
06-Nov-2015 |
Robert Carr <racarr@google.com> |
Clarify geometry management for SurfaceView In the hardware accelerated case, RenderThread needs to be the authority of information on the geometry of the SurfaceView (this will occur via moving the repositionWindow call to RenderThread). In order to support this we have to enable calling relayoutWindow without geometry (so that it will not fight with repositionWindow). Add such a mode to relayoutWindow and use it from SurfaceView. Add size to repositionChild while we are here. Bug: 22802885 Change-Id: Ie45132c22f34cc6ecfe2446912b30bd1df414406
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
7d73643f7a3fbd635ba1818d6f819e551b7ffcf6 |
|
06-Nov-2015 |
Bart Sears <bsears@google.com> |
Revert "Clarify geometry management for SurfaceView" This reverts commit 78a45f2bd8794d7a85e7443820862d466edf2324. Change-Id: I782f688f52a85df84d9facef2fbf88c28f4a7082
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
78a45f2bd8794d7a85e7443820862d466edf2324 |
|
03-Nov-2015 |
Robert Carr <racarr@google.com> |
Clarify geometry management for SurfaceView In the hardware accelerated case, RenderThread needs to be the authority of information on the geometry of the SurfaceView (this will occur via moving the repositionWindow call to RenderThread). In order to support this we have to enable calling relayoutWindow without geometry (so that it will not fight with repositionWindow). Add such a mode to relayoutWindow and use it from SurfaceView. Add size to repositionChild while we are here. Change-Id: I12f85f586a38bf86367f3d964cb49f19003d441f
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
64e516f5fa56d71bf6b5076e5620c30dc5810ba1 |
|
29-Oct-2015 |
Rob Carr <racarr@google.com> |
Sync SurfaceView position changes to parent render. In order to provide pixel perfect movement of SurfaceViews 'within' other views (e.g. scrolling) we need to be able to synchronize the attached (parent window) painting with the movement of the SurfaceView (recall, SurfaceViews are positioned behind their attached windows and the parent must render a transparent region for the SurfaceView to appear). Provide a new WindowManager method to reposition an attaching window (that is to say, a window which has an attached window like SurfaceView) and defer the transaction until the parent frame. SurfaceView is hooked up to use this for movement. This is still 'racy' in the hardware accelerated case as the render thread could be on either side of dequeing the frame we are working on. Bug: 22802885 Change-Id: I025d2bdcbe15c1c11047cc0dbca2cf2b7d67c632
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
7e1d861a9a3f76e1f79eb6806d4aa8bbeb560773 |
|
16-Oct-2015 |
Rob Carr <racarr@google.com> |
Revert "Sync SurfaceView position changes to parent render." This reverts commit 6104dc95606b3399356dd011ca6d71fcd954154c. Change-Id: If9d709bc65e7a817bd2c1b5768c7c33a9317638f
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
6104dc95606b3399356dd011ca6d71fcd954154c |
|
28-Sep-2015 |
Robert Carr <racarr@google.com> |
Sync SurfaceView position changes to parent render. In order to provide pixel perfect movement of SurfaceViews 'within' other views (e.g. scrolling) we need to be able to synchronize the attached (parent window) painting with the movement of the SurfaceView (recall, SurfaceViews are positioned behind their attached windows and the parent must render a transparent region for the SurfaceView to appear). Provide a new WindowManager method to reposition an attaching window (that is to say, a window which has an attached window like SurfaceView) and defer the transaction until the parent frame. SurfaceView is hooked up to use this for movement. This is still 'racy' in the hardware accelerated case as the render thread could be on either side of dequeing the frame we are working on. Change-Id: Ic33915043380ab8cd9eb4920e224b35234ed867d
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
8e89b31a62fb9ec5ad33908c5e8e9c7ab2fd949f |
|
10-Sep-2015 |
Chong Zhang <chz@google.com> |
Move window moving and resizing handling to WindowManager - add a startMoving API to initiate a window move from app, once the move starts WindowManager will take over the event handling. - detect touch events along window's outside border and start a resize if necessary Change-Id: Ic7e8baba34e0aa27a43173e044ffb46e93e219e0
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
2987f616faca534a792686a53304c9932634310c |
|
01-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
resolved conflicts for merge of 300ccf4a to mnc-dev Change-Id: Ia315e314bfde0c066a2c25d93f8cbdc71fee0a14
|
0ec1328f85a08a610868856c688ebb8196c79c17 |
|
25-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Calculate outset hint when adding window. Outsets aren't dynamic so they are a great candidate for a hint when the window is added through the window manager. Thanks to this during first view hierarchy measure or wallpaper window layout they are immediately available and don't require multiple measure/layout passes. Bug: 21593814 Change-Id: I573c15ffbbe4fcd8a6ed9c5e4fcd6cfbbcd7434f
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
2217f61e51ba4b19c56b19297c1e9cf74d7d860f |
|
26-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Revert "resolved conflicts for merge of 47249f2a to mnc-dev"" This includes the fix for the broken dialog windows. The outsets will only be calculated and applied if the window is full screen, since they don't make much sense otherwise. This reverts commit 4bb6b751fbbb218e8a298db4aa008472a0aa8d31. Change-Id: I977a85a78c990c1840784dc0be0dddd5a6d84e6b
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
4bb6b751fbbb218e8a298db4aa008472a0aa8d31 |
|
23-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Revert "resolved conflicts for merge of 47249f2a to mnc-dev" This reverts commit c7becb7ee78881646251ff4846e63eb6b96bf7ec, reversing changes made to 8562b08f04c1309cf40db1e749d612b6824f1d12.
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
c7becb7ee78881646251ff4846e63eb6b96bf7ec |
|
21-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
resolved conflicts for merge of 47249f2a to mnc-dev This is a merge of chin support. Change-Id: I436b751b3c4aaa6b46cfcdb475e02eedfa5a5635
|
3e11bf33a6094da92d97702213aa12c67b21c4d1 |
|
20-Apr-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Support for devices with a chin. Information about the chin is now part of the config.xml instead of the theme. It is retrieved by WindowManagerService and passed to the clients as insets. Clients can adjust their behavior in a way that makes it invisible to the user, that part of the surface doesn't actually exist. Bug: 19908853 Change-Id: Iedf57bf3c848201b854f91ffeb3b59187d375c1f
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
1fb55286438967f82e305a8449c0528a7cd07fce |
|
24-Feb-2015 |
Chad Jones <chadj@google.com> |
resolved conflicts for merge of 57bb5f5c to master Change-Id: Id5dfe7fc919305658312771a031c0764cef5515c
|
c2932a1be3e320679034212698aff376d5104dbe |
|
21-Nov-2014 |
Jeff Brown <jeffbrown@google.com> |
Hold a wake lock while dozing when display updates are pending. When the display state is DOZE or DOZE_SUSPEND, assume this means that the AP may go to sleep at any time so hold a wake lock for a little while starting when traversals are scheduled to ensure that the AP remains awake long enough to draw and post the frame to the display hardware. This patch is somewhat approximate but should be good enough for most devices today. Note that the implementation uses the window manager to ensure that the window which wants to draw is actually visible before acquiring the wake lock. There is a cost to this test (a round-trip) which should not be significant today since we do not expect apps to draw more than one frame or two while dozing. However, if we wanted to support animations in general, we might want to optimize it or eliminate the check altogether (since we can already account for the app's use of the wake lock). Another way to implement this functionality might be for the view hierarchy to listen for the power manager to report that it has entered a non-interactive power state before deciding to poke draw locks. This would be somewhat more accurate than watching the display state. Also, the draw lock timeout logic could be implemented more directly instead of using an ordinary timed wake lock. Bug: 18284212 Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
165be0c70d128f0ece876d54e1c7e95ef04c6960 |
|
28-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Remove TYPE_UNIVERSE_BACKGROUND from system An experiment that is over and has been occupying space. Fixes bug 18088522 item #7 Change-Id: Ib0fcaa24243ed9b0581143e1d5114c1fd2b0aa6e
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
37d7a68de7e353c31a3a4736054cd86f0e002eaf |
|
06-Nov-2014 |
Adrian Roos <roosa@google.com> |
Fix inset hinting when adding window Windows with FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS were getting an incorrect content inset hint, because the hinting didn't see the adjusted systemUiVisibility. Also adds hinting for the stable insets. Bug: 17508238 Change-Id: If9647277feb6811b15665b801accd896c51dbd12
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
067e5f68b9216b233df1c6529db182ff9b2887ab |
|
08-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Add new wallpaper features for insets and offsets. Issue #17394151: WallpaperService / Engines need to get notified of WindowInsets Issue #17394203 Wallpapers need a system API to be shifted in order to support burn in protection Adds a new API on WallpaperManager to set additional offsets to make wallpapers extend beyond the display size. Insets are now reported to wallpapers, to use as they may. This includes information about the above offsets, so they can place their content within the visible area. And to help with this, also expose the stable offsets APIs in WindowInsets which is also very useful information for the wallpaper. Another new API on WallpaperManager to set a raw offset to apply to the wallpaper window, forcing it to move on the screen regardless of what the wallpaper is drawing. Fix wallpapers when used with overscan enabled, so they still extend out across the entire screen. Conveniently, the above new window insets information is very useful for this case as well! And a new wallpaper test app for all this stuff. Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
fa10423fa00f3495e451016acba9b6848eb995c9 |
|
21-Jun-2014 |
Adrian Roos <roosa@google.com> |
Add stable insets for stable system windows Adds a new kind of inset that only accounts for stable system windows like the system or navigation bar. Bug: 15457292 Change-Id: I681b711f6f40a94c25b7acd3a44eb3539486afab
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
f7174e87b6007000777b0124de9cef70d8618788 |
|
12-Jun-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix backwards compatibility for introspected windows. 1. The APIs for introspecting interactive windows were reporting only the touchable windows but were missing the focused window. The user can interact with the latter by typing, hence it should always be reported. Also this was breaking backwards compatibility as if the focused window is covered by a modal one, the focused window was not reporeted and this was putting the active window in a bad state as the latter is either the focused window or the one the user is touching. 2. Window change events are too frequent as on window transition things are chanign a lot. Now we are trottling the windows changed events at the standard recurring accessibility event interval. 3. Fixed a wrong flag comparison and removed some unneded code. buy:15434666 bug:15432989 Change-Id: I825b33067e8cbf26396a4d38642bde4907b6427a
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
e3f23a36d86fedf6c8c6503378cd6d2190c5ab23 |
|
01-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new WindowId for cross-process monitoring of focus. This is a class representing a window and providing limited interaction with it, which can be handed across processes. Change-Id: I22885f2064a9cc8c68d690a5858c2e28bbb6a0f3
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
c4aad01cbbb69c916ef323693e1fd0560b0eccba |
|
23-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Formalize overscan metrics. The window manager now maintains and reports a new formal "overscan insets" for each window, much like the existing content and visible insets. This is used to correctly position the various UI elements in the various combination of layout options. In particular, this allows us to have an activity that is using fitSystemWindows to have the content of its UI extend out to the visible content part of the screen while still positioning its fixed UI elements inside the standard content rect (and the entire window extending all the way into the overscan area to fill the screen as desired). Okay, maybe that is not written so clearly. Well, it made my head hurt too, so suffer! The key thing is that windows now need to know about three rectangles: the overall rectangle of the window, the rectangle inside of the overscan area, and the rectangle inside of the content area. The FLAG_LAYOUT_IN_OVERSCAN option controls whether the second rectangle is pushed out to fill the entire overscan area. Also did some improvements to debug dumping in the window manager. Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
1cf70bbf96930662cab0e699d70b62865766ff52 |
|
06-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Screen magnification - feature - framework. This change is the initial check in of the screen magnification feature. This feature enables magnification of the screen via global gestures (assuming it has been enabled from settings) to allow a low vision user to efficiently use an Android device. Interaction model: 1. Triple tap toggles permanent screen magnification which is magnifying the area around the location of the triple tap. One can think of the location of the triple tap as the center of the magnified viewport. For example, a triple tap when not magnified would magnify the screen and leave it in a magnified state. A triple tapping when magnified would clear magnification and leave the screen in a not magnified state. 2. Triple tap and hold would magnify the screen if not magnified and enable viewport dragging mode until the finger goes up. One can think of this mode as a way to move the magnified viewport since the area around the moving finger will be magnified to fit the screen. For example, if the screen was not magnified and the user triple taps and holds the screen would magnify and the viewport will follow the user's finger. When the finger goes up the screen will clear zoom out. If the same user interaction is performed when the screen is magnified, the viewport movement will be the same but when the finger goes up the screen will stay magnified. In other words, the initial magnified state is sticky. 3. Pinching with any number of additional fingers when viewport dragging is enabled, i.e. the user triple tapped and holds, would adjust the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 4. When in a permanent magnified state the user can use two or more fingers to pan the viewport. Note that in this mode the content is panned as opposed to the viewport dragging mode in which the viewport is moved. 5. When in a permanent magnified state the user can use three or more fingers to change the magnification scale which will become the current default magnification scale. The next time the user magnifies the same magnification scale would be used. 6. The magnification scale will be persisted in settings and in the cloud. Note: Since two fingers are used to pan the content in a permanently magnified state no other two finger gestures in touch exploration or applications will work unless the uses zooms out to normal state where all gestures works as expected. This is an intentional tradeoff to allow efficient panning since in a permanently magnified state this would be the dominant action to be performed. Design: 1. The window manager exposes APIs for setting accessibility transformation which is a scale and offsets for X and Y axis. The window manager queries the window policy for which windows will not be magnified. For example, the IME windows and the navigation bar are not magnified including windows that are attached to them. 2. The accessibility features such a screen magnification and touch exploration are now impemented as a sequence of transformations on the event stream. The accessibility manager service may request each of these features or both. The behavior of the features is not changed based on the fact that another one is enabled. 3. The screen magnifier keeps a viewport of the content that is magnified which is surrounded by a glow in a magnified state. Interactions outside of the viewport are delegated directly to the application without interpretation. For example, a triple tap on the letter 'a' of the IME would type three letters instead of toggling magnified state. The viewport is updated on screen rotation and on window transitions. For example, when the IME pops up the viewport shrinks. 4. The glow around the viewport is implemented as a special type of window that does not take input focus, cannot be touched, is laid out in the screen coordiates with width and height matching these of the screen. When the magnified region changes the root view of the window draws the hightlight but the size of the window does not change - unless a rotation happens. All changes in the viewport size or showing or hiding it are animated. 5. The viewport is encapsulated in a class that knows how to show, hide, and resize the viewport - potentially animating that. This class uses the new animation framework for animations. 6. The magnification is handled by a magnification controller that keeps track of the current trnasformation to be applied to the screen content and the desired such. If these two are not the same it is responsibility of the magnification controller to reconcile them by potentially animating the transition from one to the other. 7. A dipslay content observer wathces for winodw transitions, screen rotations, and when a rectange on the screen has been reqeusted. This class is responsible for handling interesting state changes such as changing the viewport bounds on IME pop up or screen rotation, panning the content to make a requested rectangle visible on the screen, etc. 8. To implement viewport updates the window manger was updated with APIs to watch for window transitions and when a rectangle has been requested on the screen. These APIs are protected by a signature level permission. Also a parcelable and poolable window info class has been added with APIs for getting the window info given the window token. This enables getting some useful information about a window. There APIs are also signature protected. bug:6795382 Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
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/IWindowSession.aidl
|
6881a10557acf3b0270de54799d6f19437acf584 |
|
27-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Small step towards supporting multiple displays Change-Id: I353449c2b464394988c7e0203656b5851a0c9127
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda |
|
21-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Use two fingers to work some magic... Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
85afd1b6f871d471fdff1980134676a5f1690525 |
|
13-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Implement new window cropping. The window manager now performs the crop internally, evaluating it every animation from, to be able to update it along with the surface position. Change-Id: I960a2161b9defb6fba4840fa35aee4e411c39b32
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
5c58de3a523a384c47b0b1e0f5dd9728a74cd9f7 |
|
29-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Add system insets to windows. This will be used to determine which parts of a window a completely hidden by system UI elements (status bar, nav bar, system bar) so that they can be clipped out from rendering. Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
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/IWindowSession.aidl
|
9a230e01a1237749a8a19a5de8d46531b0c8ca6a |
|
06-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately This cleans up how ui flags are managed between the client and window manager. It still reports the global UI mode state to the callback, but we now only clear certain flags when the system goes out of a state (currently this just means the hide nav bar mode), and don't corrupt other flags in the application when the global state changes. Also introduces a sequence number between the app and window manager, to avoid using bad old data coming from the app during these transitions. Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
648251710162cdaf7371012a1cbb79b9bc5bc0e4 |
|
03-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3485923: Gmail crash Allow application to try to recover if a surface OOM error happens on the client side. Change-Id: I0308bd99647a35e4bcac448340b7fc6330a828f6
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
fbf097732137a32930d151f7ba6816a5b870c32a |
|
16-Jan-2011 |
Jeff Brown <jeffbrown@google.com> |
Support non-rectangular input regions. This enables the system bar to carve out a region through which events will be sent to the IME behind it. Bug: 3238092 Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
02d2b3ba9ba830a8147db2739613f7bbb2d0fcbf |
|
11-Jan-2011 |
Christopher Tate <ctate@google.com> |
API CHANGE: startDrag() now takes "int flags" instead of "boolean localOnly" There will be, in the future, a flag (View.DRAG_FLAG_GLOBAL) that means for the drag to be cross-application. For now that flag constant is @hide and furthermore the server-side implementation strips it, enforcing local-only drags. Change-Id: I8db840480ab90e18a5b8ecf29d62b4e6eafd405e
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
d4533f1469990582e4a2dd0898429093fe2690c0 |
|
20-Oct-2010 |
Chris Tate <ctate@google.com> |
Report drag success/fail in the DRAG_ENDED message DragEvent.getResult() returns 'true' if the drop was ultimately accepted; false otherwise. The validity of this datum is only guaranteed when the DragEvent's action verb is ACTION_DRAG_ENDED. Also fixes the drag-start timeout handling (though the offending app is not yet officially declared ANR). Implements bug 3097807 Change-Id: I6908ac628c72ff7d6193d87060d769a559a78d0e
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
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/IWindowSession.aidl
|
00fa7bdd69f0868fd17ea7c881c771d785b2fbbd |
|
03-Jul-2010 |
Jeff Brown <jeffbrown@google.com> |
More native input dispatch work. Removed old input dispatch code. Refactored the policy callbacks. Pushed a tiny bit of the power manager state down to native. Fixed long press on MENU. Made the virtual key detection and cancelation a bit more precise. Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
46b9ac0ae2162309774a7478cd9d4e578747bfc2 |
|
23-Apr-2010 |
Jeff Brown <jeffbrown@google.com> |
Native input dispatch rewrite work in progress. The old dispatch mechanism has been left in place and continues to be used by default for now. To enable native input dispatch, edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy. Includes part of the new input event NDK API. Some details TBD. To wire up input dispatch, as the ViewRoot adds a window to the window session it receives an InputChannel object as an output argument. The InputChannel encapsulates the file descriptors for a shared memory region and two pipe end-points. The ViewRoot then provides the InputChannel to the InputQueue. Behind the scenes, InputQueue simply attaches handlers to the native PollLoop object that underlies the MessageQueue. This way MessageQueue doesn't need to know anything about input dispatch per-se, it just exposes (in native code) a PollLoop that other components can use to monitor file descriptor state changes. There can be zero or more targets for any given input event. Each input target is specified by its input channel and some parameters including flags, an X/Y coordinate offset, and the dispatch timeout. An input target can request either synchronous dispatch (for foreground apps) or asynchronous dispatch (fire-and-forget for wallpapers and "outside" targets). Currently, finding the appropriate input targets for an event requires a call back into the WindowManagerServer from native code. In the future this will be refactored to avoid most of these callbacks except as required to handle pending focus transitions. End-to-end event dispatch mostly works! To do: event injection, rate limiting, ANRs, testing, optimization, etc. Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
694f79b5d1196640d1beb680b7d1fc68e6e77cbd |
|
18-Mar-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2519590: Lock screen stuck in landscape mode Well, mostly. There is still a problem here where the first time you show the lock screen it just doesn't draw itself. I assume this is something breaking in the view hierarchy as it floounders around removing and adding new views as it is first being shown... but no idea at this point what is the actual case. Change-Id: Iba99ae3242931c8673b17b106c86fc99e2c52abe
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
bf6956b1d95442e9d9c483894d578fe6b7044cbb |
|
10-Nov-2009 |
Marco Nelissen <marcone@google.com> |
Add a way for wallpapers to know the delta between virtual screens.
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
7580493b014a2c7ea883cd291255798dc72ebbff |
|
21-Oct-2009 |
Dianne Hackborn <hackbod@google.com> |
Implement feature #2117336: Create event communication APIs for live wallpaper Note: currently only implements an async version (no result), and not yet actually tested. Change-Id: Id47ed045a4b0eb309ea8c58daf41a0e03eff1d3a
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
19382ac1a4e4e7c23a1346d299368763f149de9c |
|
12-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Some optizations to wallpaper drawing/scrolling. First, fix some issues with the final wallpaper bitmap we use: ensure it is always 16bpp, and make sure dithering of its bitmap is turned off. We take of dithering when loading, to make sure we don't use it when drawing. Also add new APIs to return the wallpaper with the equivalent of Launcher's old FastBitmapDrawable. As doing this, also load the default wallpaper the same way as custom ones, taking care to resize it as needed at load time. Finally implement a mechanism for the window manager to wait for the wallpaper to redraw at its new position before returning from the application's call to change the offset. This ensures that the wallpaper better tracks the application. Note that there is a timeout in this wait that is relatively short, and if it expires we will run for a while without waiting. Change-Id: Ife449437746da85958bd447e0a6cf3d2223b398c
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
c8a0a75e1c61d1ab24bd46a8243041c107e738ac |
|
11-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Implement support for scrolling a wallpaper. This currently only works for a wallpaper that is larger than the screen. Set the scroll position with the new wallpaper API. Right now only does jump scrolls.
/frameworks/base/core/java/android/view/IWindowSession.aidl
|
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/IWindowSession.aidl
|
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/IWindowSession.aidl
|
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/IWindowSession.aidl
|
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/IWindowSession.aidl
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/IWindowSession.aidl
|