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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
0da43029fd73129e39e8d00d17cd7423d99f9634 |
|
16-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix build Change-Id: I6d4bebf90c11a4a00d259aac34bb9459d973da9b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
4a13b870929e1461fba626559db69226ccbeac89 |
|
19-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Revert "Fix broken build" This reverts commit 88d753291c834c41ad6c9229082146be72cf8014. Revert required because the base class change has been reverted in http://ag/816441 Change-Id: Iee8a8272bda0a92aed8ae46af8439910d8f1ecdc
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
88d753291c834c41ad6c9229082146be72cf8014 |
|
18-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Fix broken build Followup to ag/808050 Change-Id: I9912eae6a8c09b90685e19b3a9080b2d557c857b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
faa09f531f3a6fcd6518057315a52fdd0ffd3cba |
|
03-Nov-2015 |
Brian Carlstrom <bdc@google.com> |
Fix layoutlib-tests build by adding dummy implementation of IWindowSession.repositionChild to BridgeWindowSession Change-Id: I9c3a609c76716b35595b82a33f32883d4f46c517
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
173b6c2d1abce67ce802802621eaef43023b24fd |
|
13-Sep-2015 |
Chong Zhang <chz@google.com> |
Fix build break with startMovingTask API Change-Id: I4dc44ca04c75a9dfed079338e4906d317f50a1e3
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
81f8cd92fa003a8625df1098662d0afa50f07e89 |
|
01-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
am 3ce79f6c: am 96496e2d: Merge "Build fix after changing IWindowSession." into cw-d-mr1-dev * commit '3ce79f6c0c3435eca05ea34c5a8b34ac59bcb992': Build fix after changing IWindowSession.
|
7e3b61e73d6971c35acfa0798eb4d8da412ec3af |
|
30-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Build fix after changing IWindowSession. Change-Id: I339fecb0138e8b8907fc53372b694021f6327260
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
919f93265de94156d2cb32b598b5e08aa8da27c3 |
|
01-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Revert "Fix build."" This reverts commit 944a6c937cd3576ecae5c3fdd0dcf265329e6bcf. Change-Id: I7daa255f331a1e39308eb626580aa00c63c5cb3e
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
944a6c937cd3576ecae5c3fdd0dcf265329e6bcf |
|
23-May-2015 |
Deepanshu Gupta <deepanshu@google.com> |
Revert "Fix build." This reverts commit 97b3ae1a8766616675ebf2323a97d8adfd41bfdc. Reverted since 4bb6b751fbbb218e8a298db4aa008472a0aa8d31 reverts the commit that warranted this change. Change-Id: I56d0eb8ffba44a673ae357e9543dd18f6c03c54f
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
97b3ae1a8766616675ebf2323a97d8adfd41bfdc |
|
21-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix build. Cherry picking because automerger is stuck. Change-Id: I49f669ee8eed53cf2fc30077cf0a066312865733 (cherry picked from commit c1b736a0cdf41ab5863bfe6901e46c95cc396342)
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
c1b736a0cdf41ab5863bfe6901e46c95cc396342 |
|
21-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix build. Change-Id: I49f669ee8eed53cf2fc30077cf0a066312865733
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
f5cc3644f6d246138d22f35d00f1ce562cd715d5 |
|
10-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix build. Change-Id: I92eabc35168acfe58641917179be0d90a14f2f11
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
9657804afb9eb628fa5485750c43e78458b2d002 |
|
02-Jul-2014 |
Adrian Roos <roosa@google.com> |
Fix layoutlib breakage due to I681b711f6f40a94c25b7acd3a44eb3539486afab Change-Id: I141f49718c4d538875a68c00101c098fdd7e967b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
a3874f0ac649a865d6ad7a8a032f57539bd0d0c3 |
|
13-Jun-2014 |
Ji-Hwan Lee <jihwan@google.com> |
LayoutLib: Fix broken sdk builds Change-Id: I301b312195eb3e57cb581d015e7c0b0492084b3e
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
282e181b58cf72b6ca770dc7ca5f91f135444502 |
|
24-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
Revert "Move frameworks/base/tools/ to frameworks/tools/" This reverts commit 9f6a119c8aa276432ece4fe2118bd8a3c9b1067e.
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
9f6a119c8aa276432ece4fe2118bd8a3c9b1067e |
|
28-Aug-2013 |
Mike Lockwood <lockwood@google.com> |
Move frameworks/base/tools/ to frameworks/tools/ Change-Id: I3ffafdab27cc4aca256c3a5806b630795b75d5c8
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
4ec6cc51087f310acf6f933ae2b69f1520b78453 |
|
05-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix build. Change-Id: Iaa70b05a3cfd372518ec35aa8bcea2f9d78b8292
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
39df578acddb739d7608e458533904bf5814c0da |
|
27-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Fix build. Change-Id: I52bbebae38912a4fb71c96174b3d4d8eb6be10c1
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda |
|
21-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Use two fingers to work some magic... Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
4286d6d115385391b75db8e6c4e397008ef9b3db |
|
14-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix build. Change-Id: I53263d509559c70100cd78ad49f225f0dafd8891
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
46d43ccfd8cef75b4315828073c094cf1efb05ff |
|
03-Feb-2012 |
Xavier Ducrohet <xav@android.com> |
Make Layoutlib compile on Java 6. Change-Id: Ic8f0e321c6c218de83664fc01f253a07fa80852c
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
310a4d815b693e358d151b9aa2823c5022993f9b |
|
13-Jan-2011 |
Xavier Ducrohet <xav@android.com> |
LAyoutLib: Fix build by adding missing IWindowSession implementation. Change-Id: I0af178d149b782cac3ae0c36fa5fc03f4dc6118b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|
c2e9651bf386a1f7bf7fc706cf5424950570470c |
|
10-Nov-2010 |
Xavier Ducrohet <xav@android.com> |
Layoutlib: New bridge implementation using the new API 5. Since the new API prepare for stateful layoutlib, major reorganization of the code. New "android" sub-package for all extended android classes. Also moved BridgeInflater in here so that all extended classes are in this package. Only delegates and classes replacing renamed classes are in their original android.* packages. Also created full file for the empty implementations of IWindow and IWindowSession. New "impl" for the dirty work implementation. Main package contains the basic implementation of the API. Most of the code that was in Bridge is now in .impl.LayoutSceneImpl, with the main init/inflate/render code split into the contrustrutor, inflate() and render(). Change-Id: Ie15b15e5a1b2388cd6ef82e518345b1fc02ec981
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindowSession.java
|