a94c3194ffa896632f025b983ca57095cd4ba277 |
|
01-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Cannot click on partially visible views in touch exploration. 1. In touch exploration mode the system clicks in the center of the accessibility focus rectangle. However, if this rectangle is only partially shown on the window or on the screen the system may not be able to perform the click, if the accessibility focus center is not on the screen, or click on the wrong window, if the access focus center is outside of the window. This change clips the rectangle to the window bounds which and the display bounds. This will ensure no clicks are sent to the wrong window and no clicks are sent outside of the screen. bug:7453839 Change-Id: I79f98971e7ebcbb391c37284467dc76076172c5f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6757572b39d3802c4d7b69467b5ebf69a96c208b |
|
24-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Add throwing InvalidDisplayException from addView." into jb-mr1-dev
|
fbba753f62f13a12d9287c67921d1ea60e92768d |
|
24-Oct-2012 |
Chet Haase <chet@google.com> |
Merge "Handle offscreen animations correctly" into jb-mr1-dev
|
6018aeec27914f138f36b00d8f00136a87562fd3 |
|
23-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Add throwing InvalidDisplayException from addView. Throw an InvalidDisplayException to addView if the display being added to has been removed. Handle this exception in Dialog.show() by removing the view after it has been added and rethrow the exception from there. Add javadoc to ViewManager.addView and Presentation.show explaining the new exception and how best to handle it. Bug: 7368565 partially fixed. It remains for the Videos app to handle Presentation.show throwing the InvalidDisplayException. Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3561d062ff01f3455c984e4cfcd101a64a2e902f |
|
23-Oct-2012 |
Chet Haase <chet@google.com> |
Handle offscreen animations correctly A bug in software rendering caused animations on views that are offscreen to not get drawn, therefore the animation doesn't continue (since old-style animations depend on the logic in the drawing code to keep running). Fix is to special case the isAnimating case in ViewRoot to go ahead and schedule a traversal even if the dirty rect does not intersect with the visible region. Issue #7396035 Animations starting offscreen don't draw run/end/draw properly (sw rendering only) Change-Id: Iae25b3a424ddc5a16ba431ecd68cf42d5500db3f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3a2d6aaf8e71a89f82517369acc03d46ffe9bb22 |
|
23-Oct-2012 |
Romain Guy <romainguy@google.com> |
Use existing display list to render the resize buffer Bug #7400903 Change-Id: Ia2e534e47b4f67c280e2de7ce99cae0202751c42
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
41308e2936c768103d0e9c82500e97938d6797f1 |
|
23-Oct-2012 |
Romain Guy <romainguy@google.com> |
Properly draw the window background on window resize Bug #7385090 This change gets rid of two silly asumptions: - That a layer needs to be cleared with opaque black (it shouldn't, it's already cleared to transparent and the view will cover it up with its own background) - The the clip should be dirty at the beginning of a frame only when the render target is opaque Change-Id: I415b6d3cab196057fb0281419a53fef601a44e28
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
398a6713c355cf59af071e944268aec7c0096b5a |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #7367429 Popup window should get its direction from it Anchor View if it can" into jb-mr1-dev
|
b003e28c1d65d06fcb5690ff2955d007d8f7a626 |
|
18-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7367429 Popup window should get its direction from it Anchor View if it can - set the popup layout direction depending on the anchor view's layout direction (if not defined before) - make first pass of ViewRootImpl.performTraversals() and configuration update not override any layout direction that could have been set before Change-Id: I8e86ca805f0caf52c058d06aa7861df56fb862e6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
9911d18f0ebc9a68e41838471de507a04ea8fd9d |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
Fix for previous commit on non-interesecting invalidations An error in the logic meant that some valid invalidations weren't getting through, causing Launcher (for one) to get stuck sometimes. Change-Id: I180622623b19770cd61034a5bd7991a5e2fd0a64
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
d95316e2c78c7e6cfacac9cced66f7ace36d6497 |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
Merge "Skip drawing offscreen objects" into jb-mr1-dev
|
b78ee0ef60e5323b15b4ffdc97be4d889e272b79 |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
Skip drawing offscreen objects Previous logic in ViewRoot would schedule and perform a draw when it was requested by offscreen objects. The problem was that the logic checking for an interesection between the offscreen invalidation rectangle and the onscreen display rectangle was flawed. The fix was to use the return value from Rect.intersect() to do the right thing and skip drawing. Issue #7366568 Offscreen invalidates can cause useless work for framework Change-Id: Ie4e277c695dacee39848a8a223f0c4ee34d9bb4d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
e9a33c6098f51c687665adbed799860df2569ad0 |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware" into jb-mr1-dev
|
cf12897cf553bfd07734dad3de071915fd21d4eb |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware - set the Configuration's layout direction in ViewRootImpl instead of PhoneWindow$DecorView - then remove unecessary API on ListPopupWindow for passing the layout direction Change-Id: Ia2c6e4aa8cb82aed9b088bc3b8004ea0a1ded1f3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
78bd9835eb99fd829026a05dc543c6708367ca5b |
|
16-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus drawing does not take into account view's transformation matrix. 1. We are using the view drawing bounds but did not take into account the transformation matrix. This leads to showing ugly artifacts on the launcher's hotseat which is pretty much the first thing we see. 2. Updated the documentation of View.getDrawingRect to be more explicit that the results does not have the transformation matrix applied. bug:7354033 Change-Id: Ief2e0ea8da05471d71e215ce4497d94ff6e92d1a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c8860602726d771c69a3fefedfa03419d1c03b1c |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect temporary detach of accessibility focused view may lead to a crash. 1. If an app naither reattaches nor removes detached view that has accessibility focus, an exception in the drawing of accessibility focus occurs since we are trying to compute the focused rect by offseting the bounds of the focused view in coords of the root but the focused one is not attached. bug:7297191 Change-Id: Ib69d52e474b8ea365754f5311f5e809bd757dd1a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
dfab363807b3b44be4032e410f016e0a0d018426 |
|
03-Oct-2012 |
Romain Guy <romainguy@google.com> |
Fix rendering artifacts on tiled renderers Bug #7275145 This change fixes ViewRoot and adds extra debug information. It does not solve the problem entirely. Another CL will. Change-Id: I7e604ba38aad7f421769783dcbd998d6905ab2d9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
391fef0f5d99c13df3d86a5798614c0695046732 |
|
28-Sep-2012 |
Chet Haase <chet@google.com> |
Force redraw of new/resized windows Our use of the GL flag EGL_SWAP_BEHAVIOR_PRESERVED_BIT caused a problem with windows that are resized, where some of the contents were not being updated when the window was first placed/resized. The fix is to force the window to redraw completely when it is first resized. Issue #7246918 Label selection view disappears Change-Id: I3562141569502af581a3d63b1290c598abb57ade
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3b84206bba19ae2bc9decef6a88f97951c2a205c |
|
23-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7184877: Calendar Locksceen Widget crashes and forces phone to reboot Don't kill the system uid if we are running out of RAM. Change-Id: Ie1818a3241fc80d4dfa19f8e8bdad22d164d7baa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
11cb642756093a4af901b1525375b1eb2b5c3e2b |
|
21-Sep-2012 |
Romain Guy <romainguy@google.com> |
Update layers in a single batch at the beginning of a frame Bug #7186819 Change-Id: Ice5926dfedfb3be3a3064e65008dafa2852407da
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
603f6de35f21d74ae242d52d501f4f5c25ff4f4c |
|
15-Sep-2012 |
Chet Haase <chet@google.com> |
Fix occasional crash bug with layers Launcher occasionally crashes with a stack trace indicating that the memory of a Layer object is corrupt. It is possible for us to delete a Layer structure and then, briefly, use it to draw a DisplayList again before that DisplayList gets recreated (without the layer that got deleted). When this happens, if the memory got corrupted, it's possible to crash. The fix is to add Layer to the other objects which we currently refcount (bitmaps, shaders, etc.). Then instead of deleting a Layer, we decrement the refcount. We increment when creating it, then increment it again when it's referenced from a DisplayList. Then we decrement the refcount instead of deleting it, and decrement when we clear a DisplayList that refers to it. Then when the refcount reaches 0, we delete it. Issue #6994632 Native crash in launcher when trying to launch all apps screen Change-Id: I0627be8d49bb2f9ba8d158a84b764bb4e7df934c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f84208faf8e9ab7bbf81224006662fc3219c6ad4 |
|
14-Sep-2012 |
Romain Guy <romainguy@google.com> |
Prevent crash when invalidating all Views Bug #7165793 A ViewRootImpl's root view can be null. Check for this condition to prevent an NPE invalidateWorld(). Other messages perform a similar check to properly handle the case where mView == null. Change-Id: I5bcfc41c48a469d38b21be74df2f6c715b0f9352
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
dcd8c81bf4beb719888b6be1b9418303c9075938 |
|
13-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Propagate systemUiVisibility changes to window manager" into jb-mr1-dev
|
7eac0f557cd87486d0f10b7c72e25aeb195a4351 |
|
13-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Propagate systemUiVisibility changes to window manager The mAttachInfo.mSystemUiVisibility value was changing in View.dispatchAttachedToWindow but mAttachInfo.mRecomputeGlobalAttributes was not being set. Consequently ViewRootImpl.collectViewAttributes was returning without updating the subtreeSystemUiVisibility. This is fixed by calling needGlobalAttributesUpdate in dispatchAttachedToWindow. WIthin ViewRootImpl.collectViewAttributes the assignment to subtreeSystemUiVisibility was only being made if mAttachInfo.mSystemUiVisibility was changed within collectViewAttributes. But mAttachInfo.mSystemUiVisibility was changing outside of collectViewAttributes in dispatchAttachedToWindow. Consequently subtreeSystemUiVisibility was never updated. By looking for a mismatch between subtreeSystemUiVisibility and mSystemUiVisibility subtreeSystemUiVisibility gets assigned whenever it is out of sync. Fixes bug 7091817. Change-Id: I1e97a7dec14dc9594876175ae26370fb9030a8a6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
8d5e6f8d4a2bd39c6656cbac4f963d2527d707bf |
|
11-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #7146119: exception in FragmentManager Seems like we should never be dispatching input events to windows that currently don't have focus. Change-Id: I524796df69f3fdda4147cb37e7b85b79bad88762
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
b38070caa5143ab9fd1883e0c7c879533a480bc7 |
|
24-Aug-2012 |
Victoria Lease <violets@google.com> |
IME support for trackball and generic motion events Trackball and generic motion events now pass through the IME in case it would like to handle them before passing them on to the view hierarchy. While I was at it, I also... ...fixed the documentation on InputMethodService.onKeyUp() ...added documentation to InputMethodService.onTrackballEvent() ...added trackball and generic motion events to the "input" command ...fixed input consistency verification involving ACTION_OUTSIDE Bug: 7050005 Change-Id: I40ab68df4a9542af6df25de6ec2ec500e4c02902
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
df2390adc3879b7040425e75e4acc64729612b9c |
|
30-Aug-2012 |
Craig Mautner <cmautner@google.com> |
Don't die(immediate) if from performTraversals. The Drive application was calling PopupWindow.dismiss from within onMeasure. This caused dispatchDetachedFromWindow to be called from within performTraversals. Since dispatchDetachedFromWindow destroys much of what performTraversals uses this was a disaster waiting to happen. This fix adds a check for seeing if die(immediate=true) is being called from within performTraversals. If it is then die doesn't execute doDie immediately, but instead treats it as a call to die(immediate=false). Fixes bug 6836841. Change-Id: I833289e12c19fd33c17a715b2ed2adcf8388573a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support. Split WindowManagerImpl into two parts, the WindowManager interface implementation remains where it is but the global communications with the window manager are now handled by the WindowManagerGlobal class. This change greatly simplifies the challenge of having separate WindowManager instances for each Context. Removed WindowManagerImpl.getDefault(). This represents the bulk of this change. Most of the usages of this method were either to perform global functions (now handled by WindowManagerGlobal) or to obtain the default display (now handled by DisplayManager). Explicitly associate each new window with a display and make the Display object available to the View hierarchy. Add stubs for some new display manager API features. Start to split apart the concepts of display id and layer stack. since they operate at different layers of abstraction. While it's true that each logical display uniquely corresponds to a surface flinger layer stack, it is not necessarily the case that they must use the same ids. Added Display.getLayerStack() and started using it in places where it was relatively easy to do. Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
4702a856973a553deb82f71b1d3b6c3db5dbf4ba |
|
18-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
More view hierarchy, fragment debugging. Add a View.toString() method. Rename all of the View private flags to have a PFLAG prefix to avoid going insane trying to figure out which constant goes with which flag. Activity.dump() now includes a summary of the activity's view hierarchy, using the View.toString() method. All exceptions thrown by FragmentManager now perform a dump of the owning activity state, where appropriate. Change-Id: I6482e397e10cb5a0612ab02ce6ed5131823437a6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c89b14bba0f6cc2c91629080617f7ed215f697f3 |
|
08-Aug-2012 |
Romain Guy <romainguy@google.com> |
It seems that apparently useless public APIs are actually useful Bug #6953651 Change-Id: Ic47ce504e63262711f5d3edc76f7d2b9c12471ad
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
17112ad8a21a77620eb1ff14dcf8bdd6b7859712 |
|
07-Aug-2012 |
Romain Guy <romainguy@google.com> |
Cleanup of libhwui Change-Id: Ib7f5771548462c00027a8ad57badfb68c50644f9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
758143ecfedbe08cc6c4fed0ad8ad7a854194ca4 |
|
07-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Window position not reported if the window is not moved. 1.If a window is shown but never moved the window window is never notified for its current location. Therefore, accessibility nodes do not contain correct bounds in screen coordinates. bug:6926295 Change-Id: I7df18b095d33ecafffced75aba9e4f4693b0c393
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
908aecc3a63c5520d5b11da14a9383f885b7d126 |
|
01-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Start moving away from DisplayMetrics.DENSITY_DEVICE. This puts in most of the infrastructure needed to allow us to switch between different densities at run time. The main remaining uses of the global are to initialize the Bitmap object (not sure what to do about that since it doesn't have anything passed in the constructor to get this information from), and being able to load drawables if we need a different density than what was preloaded by zygote. Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6881a10557acf3b0270de54799d6f19437acf584 |
|
27-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Small step towards supporting multiple displays Change-Id: I353449c2b464394988c7e0203656b5851a0c9127
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
a8b9defade5b937d4ad64f9aff4bca792298f43c |
|
23-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Stop using raw display size except in window manager. We don't actually need the raw size in these places. The logical size is good enough. Starting to move dependencies on surface flinger and window manager out of the Display class. Change-Id: I2065bee8e5bf7f42c5a452dd1e8479e40ebb0d37
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
63cf0752226383cfc8fa35a3233413301b49fab7 |
|
25-Jul-2012 |
Romain Guy <romainguy@google.com> |
Merge "Make HardwareRenderer able to target generic Surface objects"
|
786fc93d71b833ab6b02b0c7ea5e30f25cceeedf |
|
25-Jul-2012 |
Romain Guy <romainguy@google.com> |
Make HardwareRenderer able to target generic Surface objects Change-Id: I4b7199a1eb30e0df354ae12c4819adc69db5df40
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
23e7c35ab5d43242d35b1019ce1a50bfb495cd27 |
|
20-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove dead code in window manager. The 'nest' parameter is always false so we can get rid of support for redundantly added views. Change-Id: I30c6a856797bdc72c4e1aa4cb26b930a33ce9a16
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c9c9a48e7bafae63cb35a9aa69255e80aba83988 |
|
16-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Removing a workaround for incorrect window position on window move. 1. The window manager was not notifying a window when the latter has been moved. This was causing incorrect coordinates of the nodes reported to accessibility services. To workaround that we have carried the correct window location when making a call from the accessibility layer into a window. Now the window manager notifies the window when it is moved and the workaround is no longer needed. This change takes it out. 2. The left and right in the attach info were not updated properly after a report that the window has moved. 3. The accessibility manager service was calling directly methods on the window manager service without going through the interface of the latter. This leads to unnecessary coupling and in the long rung increases system complexity and reduces maintability. bug:6623031 Change-Id: Iacb734b1bf337a47fad02c827ece45bb2f53a79d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
fbf885b652272013f44da71e9f77923333bf62eb |
|
10-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Notify client side of window movement."
|
05e91ed5a7ea17f021e1811166942a7d758e1cce |
|
03-Jul-2012 |
Chet Haase <chet@google.com> |
Force invalidates on non-visible views to traverse the hierarchy An optimization prunes invalidates on views which are not inside their parent's bounds. This works in most cases, but it is possible to run a situation where a view has been invalidated (and is thus waiting to be redrawn), but the pruning logic ensures that that draw call will not happen. Further, when/if the view comes into the bounds of its parent again, it may still not be redrawn, because now future invalidates on the view are noop'd because it is already in an invalidated state (and thus will not propagate invalidates up the hierarchy). The fix is to remove the optitmization. This will cause some overhead sending the invalidation request up to the view root, but this overhead is minimal (and only extra for cases of out-of-bounds views), and the more expensive part of rendering these views will still not be done since the view root will avoid re-drawing the hierarchy when the dirty rectangle is empty. Issue #6773607 Layered views animating from offscreen sometimes remain invisible Change-Id: Ia2c1a2b9d3e7f267253cb325ccceff1e7fdbe8bd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
27e2da7c171afa39358bbead18fbe3e6b8ea6637 |
|
03-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove the accessibility focus search code. 1. In JellyBean we have added some APIs to search for next accessibility focus in various directions and set accessibility focus from hover. However, we have decided that there is not clean answer for how this should behave and the APIs were hidden. Now the accessibility service is responsible for that. The unused code is now taken out. 2. This patch also takes out the hidden attribute accessibiligyFocusable since we moved the responsibility for implementing focus search strategy to accessibility services and we did not need that for Jellybean which is a good sign that this is not needed. I general this is one less thing for an app developer to worry about. We can add this if needed later. bug:6773816 Change-Id: I0c858d72c93a2b7ff1f8f35a08d33ec4b9eb85fd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
5702d4dfb5b81491f873a3617f8d8fc8dc5279e6 |
|
30-Jun-2012 |
Craig Mautner <cmautner@google.com> |
Notify client side of window movement. Add a one way method to notify Views that the window has moved on the screen. Fixes issues arising from the IME popping up and translating the window that uses it. Accessibility was left unaware of these movements and was drawing the box around the wrong widgets. Similarly PopupWindow used getLocationOnScreen to determine how much screen real estate was above and below the anchor point to determine where to put an anchored window. Fixes bug 6623031. Change-Id: I4731a94d5424c1ec77bf1729fba8fc9ea34cae46
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c32b2091d6441e7709342ca62f0976fc4a0367e4 |
|
18-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 45c4a8df: am ec7c7ebf: Merge "API for finding accessibility focus in virtual tree not needed." into jb-dev * commit '45c4a8df9487f53af37ded1f5a1ebe500e89b493': API for finding accessibility focus in virtual tree not needed.
|
45a02e0809c14a52aa24658666df0d41ce661857 |
|
18-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
API for finding accessibility focus in virtual tree not needed. 1. The function for finding where the accessibility focus in a virtual node tree presented by an AccessibilityNodeProvider is not needed API since the framework already keeps track of the accessibility focused virtual node in order to draw the focus rectangle. This API adds unnecessary complexity to developers of AccessibilityNodeProviders. bug:6675330 Change-Id: I84774686b06a995073a39e45b8ef22f2cd04b773
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
04ddf3c0508f3d50e6ab82cecc0adc92f52b7803 |
|
14-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Allow applications to recover from IME related ANRs. Timeout after 2.5 seconds. Because communication with an IME occurs asynchronously using oneway binder calls, it's possible for an input event that was delegated to the IME to be dropped on the floor. When this happens, the app (not the IME!) will get blamed for the problem and will ANR forever. Even if an event is not dropped on the floor, we should eventually time out event dispatch to the IME if it's being too slow. This patch implements a timeout on all events delegated to the IME. When the timeout expires, the event is marked as having not been handled by the IME and the application gets a crack at it. We also write a message to the log when this occurs. Ensure that we do not invoke the event finished callback while holding the InputMethodManager's lock to avoid potential deadlocks. Fixed a minor bug where the InputMethodManager would not remember the id of the current input method. This caused the log messages and dumpsys state to print "null" as the current input method id. Bug: 6662465 Change-Id: Ibb3ddeb087ee6998996b0b845134e16a18aa3057
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
54ab347fdde0e4d14d923cca80e5bcc7b879fc52 |
|
14-Jun-2012 |
Romain Guy <romainguy@google.com> |
Don't create a giant layer for all notifications Bug #6642475 When expanding the status bar, create one layer per notification instead of a single giant layer for the pile of notifications. This prevents layer creation failure when the total height of the notifications is larger than the maximum allowed texture size in OpenGL ES 2.0. This change only enables layers on notifications that will be visible once the notification area is fully expanded. Change-Id: I3c791a66cf5ac0973f3a65cfcd84b95209d580f3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
9d0908919a65a4f3158a8fc50aaf320dfed36278 |
|
12-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6634325: View.setKeepScreenOn and... ...MediaPlayer.setScreenOnWhilePlaying seem broken We need to correctly clear the keep screen on flag when the view hierarchy request is gone... and to do that, we need to keep the actual state of the flag requested by the app. Also when the app changes its state, we need to compute the proper value based on both the app request and any requests in the view hierarchy. Bug: 6634325 Change-Id: I060e9a34a10faffbaa77c06098cf21298bb4969f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
527ee91b60426b5a344e9905c7f9a14d6d26219e |
|
11-Jun-2012 |
Romain Guy <romainguy@google.com> |
Prevent crash in WebView when disabling the hw renderer Bug #6596807 A crash would occur in the following situation: - WebView registers a functor with the hardware renderer - The hardware renderer gets disabled - WebView attemps to unregister its functor Unregistering the functor fails because the hardware renderer is now disabled. When the renderer becomes enabled again, the functor is invoked, which leads to a native crash. This change simply allows functors to always be unregistered, even when the renderer is disabled. A disabled renderer only means that it will not be used for rendering; as such, unregistering a functor is a valid operation and should be allowed. Change-Id: I0ff897a0cca7e048c609033215cd0f7f5c940bcc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
86783474fdec98a22bc22e224462767eab13e273 |
|
07-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Cannot interact with dialogs when IME is up and on not touch explored popups. 1. If the last touch explored location is within the active window we used to click on exact location if it is within the accessibility focus otherwise in the accessibility focus center. If the last touch explored location is not within the active window we used to just click there. This breaks in the case were one has touch explored at a given place in the current window and now a dialog opens *not* covering the touch explored location. If one uses swipes to move accessibility focus i.e. to traverse the dialog without touching it one cannot activate anything because the touch explorer is using the last touch explored location that is outside of the active window e.g the dialog. The solution is to clear the last touch explored location when a window opens or accessibility focus moves. If the last touch explored location is null we are clicking in the accessibility focus location. bug:6620911 2. There is a bug in the window manager that does not notify a window that its location has changed (bug:6623031). This breaks accessibility interaction with dialogs that have input because when the IME is up the dialog is moved but not notified. Now the accessibility layer gets incorrect location for the accessibility focus and the window bounds. The soluion is when the accessibility manager service calls into the remove thress to obtain some accessibility node infos it passes the window left and top which it gets from the window manager. These values are used to update the attach info window left and top so all accessibility node infos emitted from that window had correct bounds in screen coordinates. bug:6620796 Change-Id: I18914f2095c55cfc826acf5277bd94b776bda0c8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
932b7f6765968bd526c03512f3805fbc3924dc29 |
|
06-Jun-2012 |
Chris Craik <ccraik@google.com> |
Revert "Add more temporary logging for investigating detachFunctor" bug:6608646 This reverts commit 8857b2f76abad1e4ec742dfd85d0c997880be376 Change-Id: I1563b5974c52b84201ae448298f804eb0dcc235d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
8857b2f76abad1e4ec742dfd85d0c997880be376 |
|
05-Jun-2012 |
Chris Craik <ccraik@google.com> |
Add more temporary logging for investigating detachFunctor bug:6596807 Change-Id: Ic9e34e323b12a887f2e8df0773a6155627b6a64f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
41ee465734d0006797a8fd36e88976c1e85d161c |
|
01-Jun-2012 |
Chris Craik <ccraik@google.com> |
Force webview invalidates on unsuccessful functor attach Functor attach should always be successful, but adding a fallback just in case. Also invalidates the WebView on initial content arriving. bug:6511995 Change-Id: Ibca16505afec9f693ea4a7cc4966cd6d7353725c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
38c2ece5ce4c59f30e5832779bf1d86d68b1c442 |
|
24-May-2012 |
Romain Guy <romainguy@google.com> |
Clear bitmap references from display lists as early as possible Bug #6555840 Apps like Google+ with large bitmaps displayed in listivews could run into memory issues because of these references. Change-Id: I39486bda13ce00c5a3b6481139ad54547506a8b4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f40628645df750991ced8dde803dd57225fca04f |
|
22-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Accessibility focus and input focus do not sync - part 2" into jb-dev
|
525ae2075cf96d3a2ac67cd3a662069fd579f42d |
|
22-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus and input focus do not sync - part 2 1. This patch has somecode that syncs input and accessibility focus or tries to put accessibility focus on the top most container that was missed by the previous patch. Change-Id: I08f21670b1c6e9f363d5714b1976fb52d84baae4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
e2d7f182ff2db26723089206c7d01f6695bd3dfc |
|
21-May-2012 |
Romain Guy <romainguy@google.com> |
Remove DEBUG_LATENCY flag This flag was replaced with the more versatile and powerful systrace. Change-Id: I2267698f86fe9ba9e1102856795ca641001fecd5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
13b907353f18215b52b5ceda24bbf520d91d72a1 |
|
21-May-2012 |
Romain Guy <romainguy@google.com> |
Remove unused, obsolete debug code All these features have either been abandonned and left un-maintained for years or can be replaced by systrace. Change-Id: I42e4579a8078744047e5fe08a7a15254970b09bc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
dddcd22b7ea56b1d3e31f2bbc35c80cb047de879 |
|
19-May-2012 |
Romain Guy <romainguy@google.com> |
Don't crash on Surface.unlockAndPost() but log & try again Bug #6482593 Change-Id: Ib477b58e2b7a6cb19a87d05f2aa0448e04d82f7c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
648337b3a8024b22a77977024cdf171f83999d56 |
|
17-May-2012 |
Adam Powell <adamp@google.com> |
Merge "Fix a bug where late-invalidating views with animations would be held for too long by ViewRootImpl" into jb-dev
|
3e3c4ee0475ad7096201a5f00f2e9be22fb891dd |
|
17-May-2012 |
Adam Powell <adamp@google.com> |
Fix a bug where late-invalidating views with animations would be held for too long by ViewRootImpl Change-Id: I1e32bf2683b50f8834f215a753f881b5d4b8dbc9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c8d2668bc4506aa9e771931534c6379cf687d41e |
|
17-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Add systrace method tags for measure and layout. Change-Id: I739f6384b390d1b34b09b622ca0f752de1dd7304
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
413baf8a03db180607efaca0bb60c15a153c4322 |
|
16-May-2012 |
Romain Guy <romainguy@google.com> |
Don't draw onto a hw surface using the software renderer Bug #6485955 If an invalidate gets scheduled right before the EGL surface is destroyed, the next draw pass is done in software. This causes the software renderer to connect to the surface forever which prevents the hardware renderer from coming back when the screen is turned back on. The fix here is to ignore the draw request when hw acceleration is requested but not yet available. Proper software fallback will still happen when an error is encountered with hardware rendering (in which case hw acceleration will not be marked as requested anymore.) Change-Id: I1edc4a51c8dd38240aa2345092a18a081a756fc1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
78cb7cf7d1d82834c4405650a17e387370004570 |
|
15-May-2012 |
Chris Wren <cwren@android.com> |
Allow animations to run past cancelled draws, if the view is visible. Bug: 6475482 Change-Id: Iecb3a04744282135efa0049f1b70a46dc4a6bb23
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
791fd31a68c59395952005886ba799169f80a29a |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus traversal in virtual nodes. 1. Finished the implementation of support for maintaining accessibility focus in view with virtual descendants. 2. Finished the NumberPicker implementation of virtual subtree such that all requred attributes are reported and ensuring that it support accessibility focus in its virtual descentants. 3. Fixed a bug where if a predecessor of the view that is accessiiblity focused is removed the accessibliity focus host in ViewRootImpl is not cleared leading to a crash when trying to draw the accessibility focus highlight.: bug:6472646 bug:6433864 Change-Id: I3645642b87b4a26025c0b2ba9dfaad92d11a48f1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
8ce2d78aa89e89e9a5607d8809bf6d248508a531 |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Improving accessibility focus traversal." into jb-dev
|
e5dfa47d84668376b84074c04570fb961870adeb |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility focus traversal. 1. Now the views considered during the accessibility focus search are the ones that would get accessibility focus when thovered over. This way the user will get the same items i.e. feedback if he touch explores the screen and uses focus traversal. This is imperative for a good user experience. 2. Updated which focusables are considered when searching for access focus in ViewGroup. Generally accessibility focus ignores focus before/after descendants. 3. Implemented focus search strategy in AbsListView that will traverse the items of the current list (and the stuff withing one item before moving to the next) before continuing the search if forward and backward accessibility focus direction. 4. View focus search stops at root namespace. This is not the right way to prevent some stuff that is not supposed to get a focus in a container for a specific state. Actually the addFocusables for that container has to be overriden. Further this approach leads to focus getting stuck. The accessibility focus ignores root names space since we want to traverse the entire screen. 5. Fixed an bug in AccessibilityInteractionController which was not starting to search from the root of a virtual node tree. 6. Fixed a couple of bugs in FocusFinder where it was possible to get index out of bounds exception if the focusables list is empty. bug:5932640 Change-Id: Ic3bdd11767a7d40fbb21f35dcd79a4746af784d4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
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/ViewRootImpl.java
|
78b8ef3f3ad8ab935f677d8d672db0d97bff8119 |
|
07-May-2012 |
Jamie Gennis <jgennis@google.com> |
Surface: replace active rect with window crop This change replaces the setActiveRectCrop method on Surface, which was called from app processes, with the setWindowCrop method that is to be called from the window manager. Bug: 6299171 Change-Id: Ica51efcd8c488a526e7013b83d80df4856694519
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
cf67578c7f99492273a8f8446dd18ddc5af2ae76 |
|
11-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6475693: OnSystemUiVisibilityChangeListener reporting... ...incorrect visibility when the ActionBar overflow menu is opened Don't report layout flags in system UI visibility callback. Update docs to reflect this. Change-Id: Icfa411b5537de037cafbcac04991101e8b9138c4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
a482d36635cbfbbfb4aee9fc79d55514bf6b7464 |
|
10-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fixed typo in findAccessibilityFocus API." into jb-dev
|
57aab755441a28c2e5c78c35a57b940afc2799e0 |
|
10-May-2012 |
alanv <alanv@google.com> |
Fixed typo in findAccessibilityFocus API. Change-Id: I3ca1448792a1b712f781c1bfa73823ca08ea3d39
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
571d4cbeec4adad050b8e188770e7e7dedc558f1 |
|
10-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Fix bugs in fallback key handling." into jb-dev
|
a53de0629f3b94472c0f160f5bbe1090b020feab |
|
09-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Add callback hack to find out when to load system properties. Use this to reload the trace and layout bounds properties. This is ONLY for debugging. Change-Id: I1c4bdb52c823520c352c5bac45fa9ee31160793c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
fd23e3ed976b22b9a92ddb2cb3a46f9d2a0ce23f |
|
09-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix bugs in fallback key handling. If a fallback key is generated using a key plus a modifier, then it's possible we might get a different fallback key generated if the modifier has changed. PhoneWindowManager needs to remember which fallback is last generated for a given key code so that it can apply the same fallback action. When generating cancellation events, it's important to have preserved the policyFlags of the original event. Otherwise we may not dispatch the cancellation properly. For example, some actions are not performed if the POLICY_FLAG_TRUSTED is not specified. Remember the metaState associated with a key event so we can include it when canceled. Tell the policy when a fallback is being cancelled so that it can clean up its state. After a SEARCH shortcut is invoked, clear the flag indicating that a shortcut is pending. This is to prevent SEARCH from getting stuck down in the case where we might forget to send the up. (Shouldn't happen anymore after the prior fixes.) Bug: 5616255 Change-Id: I68f0a9679c7af464eaf31c099f2aa50b53fecf1f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
2a0f228a30c85a124f92a5a7c1b10a81cf69af6d |
|
08-May-2012 |
Romain Guy <romainguy@google.com> |
Invalidate display lists immediately when views are removed/added quickly The deferred invalidation of display list could cause problems with view like TextureView who destroy resources when detached from the window but only recreate them later at draw time. This would cause temporary flashes or other visual glitches on screen. Change-Id: I018488ba09743df21c6434ea610813014fb80a85
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
ec4d9040f603b57b1706299f51838b6cc68b8f99 |
|
06-May-2012 |
Romain Guy <romainguy@google.com> |
Merge "Attempt to recover from apps destroying their window at draw time Bug #6436642" into jb-dev
|
1f59e5c19bf72f88eed6f8de08b0a879d999f61c |
|
06-May-2012 |
Romain Guy <romainguy@google.com> |
Attempt to recover from apps destroying their window at draw time Bug #6436642 Change-Id: I906b9c68225683f97b9c97c153a1132cf9ac6509
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
139e5aa1da51b27231ab36344cf2d0dafab23f1e |
|
06-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6404215: New ActionBar auto-hide can conflict with application The action bar now maintains separate states for the things that can impact its visibility (calls from the app, action mode, system UI) so that the changes in these won't incorrectly mix together. Also added a hack to force the status bar to be shown when showing the action bar for an action mode, when the UI is in a state where the action bar would be shown with a gap above where the status bar is. Change-Id: Ib0950a7f585c5d2c9e77d11b237ba6e150f15ebd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3556c9a8068497d0de8964fd3be719c68eae1f00 |
|
05-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Implement cropping of windows based on system UI elements. Start calling Surface.setActiveRect(). Change-Id: I94197059c971c6ab7820e615ea8f285482b86c75
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3fe38c0e73e520c6c38454a41a4cffa16faaf67d |
|
04-May-2012 |
Craig Mautner <cmautner@google.com> |
Retain current visibility when copying layoutparam The LayoutParams members, systemUiVisibility and subtreeSystemUiVisibility are derived values rather than app-generated values. When copying LayoutParams members make sure these values are not overwritten. Overwriting them was causing the STATUS_BAR_DISABLE_XXX flags to be overwritten exposing elements that should have remained hidden. Fixes bug b6374541. Change-Id: Iaae4b4167e1b148bbdba4d05f473844f7fa3bf8d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
fb68fdb9c6e915e38ec5c7f4b0d526b613e4ea8b |
|
01-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Accessibility should not change input focus behavior." into jb-dev
|
cf8a3b82241a320f568f8448184df6da5bbcf152 |
|
01-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility should not change input focus behavior. 1. Removed a change in the input focus behavior I forgot to take out when submitted the main accessibility focus patch. Ugh.. bug:6320098 Change-Id: Id7942e8aac64ba4bf6df7e19f733fa70b368d1bb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
1e945c4fda0242e8ae02ccb7a2262556f41b42cc |
|
30-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add system insets to windows." into jb-dev
|
2f87014ea2f177e715032b07004d05e2549a63a8 |
|
30-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Enabling accessibility focus only if explore by touch is on." into jb-dev
|
18dcf2f1cd3f84cbdffd8394e16475a13d6243df |
|
30-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Fixing crash when drawing accessibility focus indicator." into jb-dev
|
07b726c86b1d0b22e51b08cb4234f8212864d9f9 |
|
30-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Enabling accessibility focus only if explore by touch is on. 1. Now we will enable the accessibility focus only if Explore by Touch is enabled. Enabling this feature allows a blind user to touch the screen and set the accessibility focus at this location as well as get spoken feedback. Also an accessibility service can move the accessibility as a result of user gestures detected only if Explore by Touch is enabled. Since we will handle some gestures by default if not accessibility service does so to provide reasonable built-in navigation of the UI by "objects" we need the accessibility focus functionality. bug:6383361 Change-Id: I13ce6072a90f5838c7656379788144c99a772bf0
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
1d74df226619101d905d872c8e609d315409695e |
|
29-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing crash when drawing accessibility focus indicator. 1. Added a lacking null check for the accessibility node info returned by an accessibility node provider. If the provider implementation is not correct this may happen. 2. Added clearing of the current accessibility focused node when the window focus changes. Now it is cleared in every case and if it happens that accessibility is enabled when the window gets focus, the accessibility focus will be properly set. bug:6381296 Change-Id: Ieea1b07762745e6d932fc4ed4febfe77760b25b7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
79c6346100b555a8a3d51b3b1c34dbbe99305b9a |
|
28-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "When a window is first shown only draw once while animating." into jb-dev
|
771526c88f5cc4b56a41cb12aa06a28d377a07d5 |
|
28-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Resample touch events on frame boundaries. Bug: 6375101 Change-Id: I8774e366306bb2b6b4e42b913525bf25b0380ec3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
12d3a94397c33fdb773a1eaaaa13cab80bf0c571 |
|
27-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
When a window is first shown only draw once while animating. On some hardware allocating a new graphics buffer is quite expensive, which blocks updates to the UI. This can cause glitches when performing window animations. To reduce these glitches, the view hierarchy will now only allow itself to be drawn once if its window is being shown while the window manager is animating, not resuming draws until it is told that the animation is done. Change-Id: Ie15192f6fddbd0931b022a72c76ddd55ca266d84
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
330314c6fb7c178c0f0da65d6aa8c9e7d3004568 |
|
27-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Simplify the consume before traversal heuristic. Calling doConsumeBatchedInput() from doTraversals() can result in redundant attempts to consume batched input. Instead of making this call directly, just schedule consume batched input at the same time as traversals are scheduled. This should have the same overall effect. Bug: 6375101 Change-Id: Ie5799e6a68fedbd1978cca6d03852d9a7f1b1f64
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
97d5c418730946a0332f601cd140ed0b12ea19c1 |
|
27-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove unused pipelining optimization. Bug: 6375101 Change-Id: I5fcbbabfafae9e1661adac7b2becc748e42c4b66
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
ba6be8a62dcdb3ffd210cd36b9af4e3a658eac47 |
|
24-Apr-2012 |
Romain Guy <romainguy@google.com> |
Prevent WebView from crashing when detached from the window Bug #6365056 WebView enqueues a functor in the hardware renderer to handle animations and this functor is called at a later time by the hardware renderer. However, the functor was not removed from the queue when WebView was removed from the window. This could cause the hardware renderer to attempt to execute an invalid functor and lead to a crash. Change-Id: I9d38e80f3fdc5e29d4d0cdfa1e893c251a954508
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
72de2062485f711c9a2291c204fd2c0fb6c4e20f |
|
21-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding support for traversing the content of a node info at granularity."
|
aa780c110922148a6a4ba06734bb2b0bb8c98f93 |
|
20-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding support for traversing the content of a node info at granularity. 1. A view that creates an accessibility node info may add to the info a list of granularity labels. These are granularities by which the source view can iterate over its content. For example a text view may support character, word link while a web view may additionally support buttons, tables, etc. There are actions on accessibility node info to go to the next/previous at a given granularity which is passesed as an argument. 2. Added Bundle argument to the APIs for performing accessibility actions. This is generic and extensible. bug:5932640 Change-Id: I328cbbb4cddfdee082ab2a8b7ff1bd7477d8d6f9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
d6b1098e1f46530528dfea415655468ec994bbb6 |
|
20-Apr-2012 |
John Reck <jreck@google.com> |
Support fallback action if unhandled key event Bug: 6023055 Change-Id: Ib802c4b9d1b606f9ea7a5081e30c50b5bd78e30c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
b78c284bd535f48207750e5a406474ea22381edd |
|
19-Apr-2012 |
Chet Haase <chet@google.com> |
Always execute actions on the runQueue A View that is not attached will place posted actions on the ViewRoot's runQueue. Previously, this runQueue was only ever executed during a layout (during performTraversals()). This works in most situations (a View that is added to or removed from the hierarchy will force a layout in general), but not in all cases. For example, a new View being added to a ListView will not cause a layout, so any actions posted to that View prior to its being attached will not be run until some indeterminate time later when a layout happens to run. The fix is to execute the (typically empty) runQueue on every traversal. Issue #6366678 View.post() ignored when called on an unattached ListView item Change-Id: I94e6fdd9da6bb57fd83b547f8d742cd0ddfecbd6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f01d3dd710e8b86b3e2846af62835158fd4e0db1 |
|
18-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding some more gestures and actions for accessibility."
|
005b83b0c62d3d0538f0d566b08bd457015ec661 |
|
17-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding some more gestures and actions for accessibility. 1. Added more gesture for accessibility. After a meeting with the access-eng team we have decided that the current set of gestures may be smaller than needed considering that we will use four gestures for home, back, recents, and notifications. 2. Adding actions for going back, home, opening the recents, and opening the notifications. 3. Added preliminary mapping from some of the new gestures to the new actions. 4. Fixed a bug in the accessibility interaction controller which was trying to create a handled on the main looper thread which may be null if the queried UI is in the system process. Now the context looper of the root view is used. 5. Fixed a bug of using an incorrect constant. 6. Added a missing locking in a couple of places. 7. Fixed view comparison for accessibilityt since it was not anisymmetric. bug:5932640 bug:5605641 Change-Id: Icc983bf4eafefa42b65920b3782ed8a25518e94f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
09dd116cd39613a3736dbbf028544e1655002430 |
|
17-Apr-2012 |
John Reck <jreck@google.com> |
Fix a bug with enterTouchMode removing focus Bug: 6347083 Fix an issue where enterTouchMode would remove focus from the view that already has focus and is focusableInTouchMode. This causes issues with WebView, as it updates internal state when losing and gaining focus. Change-Id: I5c1f72cc08baf3445e2be9e0496606a53fb9929e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
4213804541a8b05cd0587b138a2fd9a3b7fd9350 |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus - framework Usefulness: Keep track of the current user location in the screen when traversing the it. Enabling structural and directional navigation over all elements on the screen. This enables blind users that know the application layout to efficiently locate desired elements as opposed to try touch exploring the region where the the element should be - very tedious. Rationale: There are two ways to implement accessibility focus One is to let accessibility services keep track of it since they have access to the screen content, and another to let the view hierarchy keep track of it. While the first approach would require almost no work on our part it poses several challenges which make it a sub-optimal choice. Having the accessibility focus in the accessibility service would require that service to scrape the window content every time it changes to sync the view tree state and the accessibility focus location. Pretty much the service will have to keep an off screen model of the screen content. This could be quite challenging to get right and would incur performance cost for the multiple IPCs to repeatedly fetch the screen content. Further, keeping virtual accessibility focus (i.e. in the service) would require sync of the input and accessibility focus. This could be challenging to implement right as well. Also, having an unlimited number of accessibility services we cannot guarantee that they will have a proper implementation, if any, to allow users to perform structural navigation of the screen content. Assuming two accessibility services implement structural navigation via accessibility focus, there is not guarantee that they will behave similarly by default, i.e. provide some standard way to navigate the screen content. Also feedback from experienced accessibility researchers, specifically T.V Raman, provides evidence that having virtual accessibility focus creates many issues and it is very hard to get right. Therefore, keeping accessibility focus in the system will avoid keeping an off-screen model in accessibility services, it will always be in sync with the state of the view hierarchy and the input focus. Also this will allow having a default behavior for traversing the screen via this accessibility focus that is consistent in all accessibility services. We provide accessibility services with APIs to override this behavior but all of them will perform screen traversal in a consistent way by default. Behavior: If accessibility is enabled the accessibility focus is the leading one and the input follows it. Putting accessibility focus on a view moves the input focus there. Clearing the accessibility focus of a view, clears the input focus of this view. If accessibility focus is on a view that cannot take input focus, then no other view should have input focus. In accessibility mode we initially give accessibility focus to the topmost view and no view has input focus. This ensures consistent behavior accross all apps. Note that accessibility focus can move hierarchically in the view tree and having it at the root is better than putting it where the input focus would be - at the first input focusable which could be at an arbitrary depth in the view tree. By default not all views are reported for accessibility, only the important ones. A view may be explicitly labeled as important or not for accessibility, or the system determines which one is such - default. Important views for accessibility are all views that are not dumb layout managers used only to arrange their chidren. Since the same content arrangement can be obtained via different combintation of layout managers, such managers cannot be used to reliably determine the application structure. For example, a user should see a list as a list view with several list items and each list item as a text view and a button as opposed to seeing all the layout managers used to arrange the list item's content. By default only important for accessibility views are regared for accessibility purposes. View not regarded for accessibility neither fire accessibility events, nor are reported being on the screen. An accessibility service may request the system to regard all views. If the target SDK of an accessibility services is less than JellyBean, then all views are regarded for accessibility. Note that an accessibility service that requires all view to be ragarded for accessibility may put accessibility focus on any view. Hence, it may implement any navigational paradigm if desired. Especially considering the fact that the system is detecting some standard gestures and delegates their processing to an accessibility service. The default implementation of an accessibility services performs the defualt navigation. bug:5932640 bug:5605641 Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
067b091d46c3c2d11a33d25e81c8348fb609b7ab |
|
13-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility query APIs report invisible views. 1. The accessibility querying APIs failed to check whether all predecessors of a view are visible before reporting it. bug:6291855 Change-Id: I364a6f08e8d02c7105c00c9fdff0fec033829554
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
aa6f3de253db6c0702de0cc40028750c1fcfb22c |
|
10-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Some view not shown on the screen are reported for accessibility. 1. Some applications are keeping around visible views off screen to improve responsiveness by drawing them in layers, etc. While such a view is not visible on the screen the accessibility layer was reporting it since it was visible. Now the check is improved to verify whether the view is attached, is in visible window, is visible, and has a rectangle that is not clipped by its predecessors. 2. AccessibilityNodeInfo bounds in screen were not properly set since only the top left point was offset appropriately to take into account any predecessor's transformation matrix and the not transformed width and height were used. Now the bounds are properly offset. bug:6291855 Change-Id: I244d1d9af81391676c1c9e0fe86cf4574ff37225
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
edbca1285e4757900e43d31087451d1953555d7d |
|
05-Apr-2012 |
Romain Guy <romainguy@google.com> |
Make sure we clean up after ourselves Because of the mAdded=false statement a few lines above, a large section of doDie() was not executed. Things would eventually get cleaned up but it seems better to do it at the right time. Change-Id: I1a2f3a8e05057dd7cd7205b6d3f9c145d6c0241d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
25eba5c5029bd91ff7e396b2cca0e4ce024124ed |
|
05-Apr-2012 |
Romain Guy <romainguy@google.com> |
Add a new OnDrawListener to ViewRoot This can be used by app to efficiently listen for draw passes. This listener is guaranteed to not generate any garbage unlike OnPreDrawListener. Change-Id: Ida40d11a3f8a5d2617bafe722906ee5c9af48602
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3a3a6cfd8ec12208ca75c0d0d871d19d76c34194 |
|
26-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature to let apps layout over status bar / system bar. The main change is a few new flags you can supply to View.setSystemUiVisibility(). One is a new visibility mode, SYSTEM_UI_FLAG_FULLSCREEN, which is basically the same as the global FLAG_FULLSCREEN option for windows, but driven as part of the system UI state. There are also three new flags for telling the framework that you would like to have your application's UI ignore screen decorations -- SYSTEM_UI_FLAG_LAYOUT_NO_NAVIGATION for going behind the navigation bar and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN for ignoring full screen decorations (that is the status bar). In combination with this you can use SYSTEM_UI_FLAG_LAYOUT_STABLE to have the framework report consistent insets to your application. When using NO_NAVIGATION, when the user taps the screen we now also automatically clear ONLY_CONTENT, so that we atomically show both UI elements. This should make it easy for apps like video players that want to move between fully full-screen and regular modes. The ActionBar has also been extended when in overlay mode so that it will adjust the system window insets to also account for its space, and allow it to be hidden using the new SYSTEM_UI_FLAG_FULLSCREEN. Change-Id: Ic8db1adec49a0f420bfe40c1d92eb21307856d0b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
fa8b27c858438554fd94c014de959d8ec6b208bb |
|
30-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve responsiveness by always consuming batched events. Change-Id: I2eb88f8fde97ce0cd820f39da4ebe8698a7db95c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
a08f3e866a46c990e786defa95013ee0313b0887 |
|
30-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Enable vsync traversals by default."
|
ebb2d8d708c5c58c79ae88ac2bd10450a856f702 |
|
24-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Enable vsync traversals by default. Improved how the various callbacks are managed and sequenced to reduce code duplication. Added a heuristic to avoid postponing traversals until the next vsync frame if we did not actually do any drawing during the previous frame. This helps in the very common case where drawing occurs in response to input. Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
a998dff5d49a423aaf7097aa8f96bf5bdc681d25 |
|
24-Mar-2012 |
Romain Guy <romainguy@google.com> |
Destroy the hardware renderer when ViewRootImpl's die is post-poned Bug #6109035 ViewRootImpl.die() can be invoked in such a way that doDie() will be executed later. On memory limited device, an eglTerminate() may happen before doDie() is executed which leads to unstable behaviors. This change makes sure the renderer is destroyed as soon as possible. Change-Id: I3322410cdd744b464951e2055aeade6069d1d673
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
006f0e41abca961bade88908d7ef56ae63c429fb |
|
21-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Override not drawing to screen when screen is off. A new test had been added to performDraw to provide an early return if the screen was off. Drawing should have proceeded however if mReportNextDraw is set. Otherwise views that turn on the screen (such as the alarm) are not shown. Fixes bug 6168158. Change-Id: If9013d9dbd39d60ee1de8aeb3e0c1facbc5a7db5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
7b2f8b8fb7064a1d3b6d942b978c30c24c9d7299 |
|
20-Mar-2012 |
Romain Guy <romainguy@google.com> |
Pre-scale bitmaps on the native heap Change-Id: I9819b532b89a997ab775b31ffee46445f1d16e20
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
51e4d4db296c252641161b39e98f49acebc46062 |
|
16-Mar-2012 |
Romain Guy <romainguy@google.com> |
Better implementation to clear display lists Change-Id: I58f9af4bae70a8117db1455a50c0c5daf19b2f4a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
481c1570dc5cdf58265b53f657801709dd05d1df |
|
09-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Add Java wrappers for new atrace functionality. Instrument a few parts of the input dispatcher and the view hierarchy. Change-Id: I49285c9fb3502253baa1ffed60f521b8c24fccaf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
df813c03b16ed32c25a8c8fee82a7a98088ac940 |
|
09-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Use the Choreographer for Drawable animations."
|
bb9908b828a8cfd5965553be66faa6af89973697 |
|
08-Mar-2012 |
Romain Guy <romainguy@google.com> |
Dispatch screen state change events to Views Bug #6120957 Using this new callback, views can interrupt and resume their animations or other periodic tasks based on the current state of the display. Change-Id: I398f4abd421e9c5f207107bf1009a7b92cf45daa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
250069bf6bf3d7e2ef85c49e0cd100e80c3c8b7d |
|
08-Mar-2012 |
Romain Guy <romainguy@google.com> |
Merge "Ignore draw requests when the display is off"
|
7ae9d5faad5816f7e567ec1ec77e78d746cf7e5c |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Use the Choreographer for Drawable animations. Change-Id: Ifcbf33434bf3c32d1900fd0b3f5bde004604ce8a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
5bebea436e631aa77aeb0f39a34c9e830c9638f5 |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Rename remove callback methods. Change-Id: Ib9ef32fedbe0db2ea5efd250693915d626d7d8ae
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6cb7b46c56449e84434b11eb12f9b8977fcd0398 |
|
05-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Change widgets to post invalidate to the animation timer. Change-Id: I8377e924529fb9d8afd8a834003a17de616e8e87
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
7e4e561bc717a6eea4e0d06ec4173ad27420425f |
|
05-Mar-2012 |
Romain Guy <romainguy@google.com> |
Ignore draw requests when the display is off When WindowManagerService's events are enabled/disabled, the state of the display is dispatched to the known windows. This allows ViewRootImpl to ignore draw requests until the screen is turned back on. This can potentially lead to significant battery savings. For instance, a launcher widget showing a repeating animation will cause the CPU and the GPU to wake up regularly without this change. (Change submitted by Intel and merged manually) Change-Id: I7f93b0e60c3e6de1705f619e80860c36b1cdb978
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
00d0c14a0fe8e6dff8dd3e230ee4b61dd275f860 |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Regression: Cannot query the content of certain windows. 1. A bad merge on my part caused ViewRootImpl not to register for accessibility state change. bug:6064348 Change-Id: Idf7b8b444e9021e9d9ec3749164cfe448c8268ab
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
42d840b91d161fe98ebe3305f011b3b0f6d4561c |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Fixing issues with the AccessibilityNodeInfo cache."
|
57c7fd5a43237afc5e8ef31a076e862c0c16c328 |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing issues with the AccessibilityNodeInfo cache. 1. Before there were two caches one in the app process that kept track only the ids of infos that were given to a querying client and one in the querying client that holds the infos. This design requires precise sync between the caches. Doing that is somehow complicated since the app has cache for each window and it has to intercept all accessibility events from that window to manage the cache. Each app has to have a cache for each querying client. This approach would guarantee that no infos are fetched twice but due to its stateful nature and the two caches is tricky to implement and adds unnecessary complexity. Now there is only one cache in the client and the apps are stateless. The client is passing flags to the app that are a clue what nodes to prefetch. This approach may occasionally fetch a node twice but it is considerably simpler and stateless from the app perspective - there is only one cache. Fetching a node more than once does not cause much overhead compared to the IPC. Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
cfef12374c15b11b3c2a1041582be9728152e15d |
|
23-Feb-2012 |
Romain Guy <romainguy@google.com> |
Perform early intersect to avoid unnecessary draws Change-Id: I48d61c4488e622f93733d8e53a50c93e6a20166d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
0d04e245534cf777dfaf16dce3c51553837c14ff |
|
21-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility APIs used for UI automation. 1. UiTestAutomationBridge was accessing the root node in the active window by tracking the accessibility event stream and keeping the last active window changing event. Now the bridge is stateless and the root node is fetched by passing special window and view id with the request to the system. 2. AccessibilityNodeInfos that are cached were not finished, i.e. not sealed, causing exception when trying to access their children or rpedecessors. 3. AccessibilityManagerService was not properly restoring its state after the UI automation bridge disconnects from it. I particular the devices was still in explore by touch mode event if no services are enabled and the sutomation bridge is disconnected. 4. ViewRootImpl for the focused window now fires accessibility events when accessibility is enabled to allow accessibility services to determine the current user location. 5. Several missing null checks in ViewRootImpl are fixed since there were scenraios in which a NPE can occur. 6. Update the internal window content querying tests. 7. ViewRootImpl was firing one extra focus event. bug:6009813 bug:6026952 Change-Id: Ib2e058d64538ecc268f9ef7a8f36ead047868a05
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
539ee8716b4f81260bab2e9f3dc5d88d81c99985 |
|
04-Feb-2012 |
Adam Powell <adamp@google.com> |
Add transient state tracking to Views Transient state is temporary bookkeeping that Views need to perform that the app should not need to be aware of. Examples include text selection regions and animation state. Transient state is a problem for AdapterViews like ListView that do view recycling. Unless the app takes responsibility for tracking and restoring transient state as if it were a part of the adapter's data set, it cannot correctly recycle views. Selections disappear when an EditText is scrolled out of sight and animations seem to play on the wrong views. Views can now flag themselves as having transient state. (As the name implies, this should be a temporary condition.) If a ViewGroup contains a child with transient state, that ViewGroup also has transient state. AbsListView's recycler now tracks views with transient state separately. Views with transient state will be retained, and until a data set change occurs the same view will be reused for that position instead of calling the adapter's getView() method. The API to set and check transient state is currently hidden. Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
e0dbd002750856e55d637e883b629e09adfc8a4e |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Mark input and sensor messages as asynchronous. Set a barrier on traversals. Vsync is still not enabled by default in this patch so there should be no observable effect from these changes. Change-Id: Ie12081b95a8f1e81ed686edf747cc62f2e044b7e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
a175a5b7ea3682cb58cca7f9726d0b8171cd549d |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Encapsulate the ViewRootImpl's handler. This change makes it much easier to make sense of the messages that get posted to the ViewRootImpl's handler by encapsulating their point of dispatch within the ViewRootImpl itself. As part of this change, the View.AttachInfo now carries a reference to the ViewRootImpl itself, which simplifies some code that used to try to find the ViewRootImpl by getting the root view's parent. In principle, it might have been nice to hide the ViewRootImpl from the View hierarchy but in practice the two were coupled in many ways. Change-Id: I51ebccdf5f8c8c505cd6f17cdf594174d041dc54
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
4a06c8008b2edd6677f9a411af79b0a4971b87fe |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Simplify Choreographer API. Removed the listeners and schedule animation / draw methods. Instead all requests are posted as one-shot callbacks, which is a better match for how clients actually use the Choreographer. Bug: 5721047 Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
b36a0ac9709e9e1c7098559c0435cfbdc09e6c46 |
|
15-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus v2.0. The framework tries to have a focused view all the time. For that purpose when a view's focus is cleared the focus is given to the first focusable found from the top. The implementation of this behavior was causing the following issues: 1. If the fist focusable View tries to clear its focus it was getting focus but the onFocusChange callbacks were not properly invoked. Specifically, the onFocusChange for gaining focus was called first and then the same callback for clearing focus. Note that the callback for clearing focus is called when the View is already focused. 2. If not the first focusable View tries to clear focus, the focus is given to another one but the callback for getting focus was called before the one for clearing, so client code may be mislead that there is more than one focused view at a time. 3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup was calling the super implementaion when there is a focused child. Since there could be only one focused View, having a focused child means that the group is not focused and the call to the super implementation is not needed. 4. Added unit tests that verify the correct behavior, i.e. the focus of the first focused view cannot be cleared which means that no focus change callbacks are invoked. The callbacks should be called in expected order. Now the view focus clear precedes the view focus gain callback. However, in between is invoked the global focus change callback with the correct values. We may want to call that one after the View callbacks. If needed we can revisit this. Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
dd29f8c4e3db3338bc055302145c3bc51a27566f |
|
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Merge "Revert "Incorrect behavior of View clear focus.""
|
73eb97f628b298c7bd032aa9db11dadf05f5b539 |
|
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Revert "Incorrect behavior of View clear focus." This reverts commit c6fd88e213703a581fe4680259981f09ae0444f2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
072ec96a4900d4616574733646ee46311cb5d2cb |
|
07-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Implement batching of input events on the consumer side. To support this feature, the input dispatcher now allows input events to be acknowledged out-of-order. As a result, the consumer can choose to defer handling an input event from one device (because it is building a big batch) while continuing to handle input events from other devices. The InputEventReceiver now sends a notification when a batch is pending. The ViewRoot handles this notification by scheduling a draw on the next sync. When the draw happens, the InputEventReceiver is instructed to consume all pending batched input events, the input event queue is fully processed (as much as possible), and then the ViewRoot performs traversals as usual. With these changes in place, the input dispatch latency is consistently less than one frame as long as the application itself isn't stalled. Input events are delivered to the application as soon as possible and are handled as soon as possible. In practice, it is no longer possible for an application to build up a huge backlog of touch events. This is part of a series of changes to improve input system pipelining. Bug: 5963420 Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f9261d20b3773f9785d98f32f62ccfedefba8083 |
|
03-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Process input events immediately when received. Reduce the latency for handling input events by ensuring that they are handled as soon as they are received from the dispatcher. This also makes it easier for the input system to intelligently batch motion events. This is part of a series of changes to improve input system pipelining. Bug: 5963420 Change-Id: I0b3f6cbb3de5ac3c4eed35dfc774d6bd4a0b07fc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c38fa1f63674971f9ac6ced1a449fb81026b62f7 |
|
02-Feb-2012 |
Chet Haase <chet@google.com> |
Add Developer Option setting for Animator scaling. This new setting allows users to set a scale factor for the duration and startDelay of all Animator-based animations. This setting is very similar to the Transition animation scale and Window animation scale settings, except this one applies specifically to Animator animations. The property is only accessible by users through the Settings UI, not programmatically. The value applies system-wide and is picked up per-process at the time of the first ValueAnimator construction. This is an update to a previous CL; this approach uses the WindowManager to store the animator scale settings, instead of SystemProperties. Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
bbf1bc8b6c3348265930ce08506efbbd3c5ab61f |
|
02-Feb-2012 |
Romain Guy <romainguy@google.com> |
Merge "Add optional metadata to initiliaze the render threat."
|
211370fd943cf26905001b38b8b1791851b26adc |
|
02-Feb-2012 |
Romain Guy <romainguy@google.com> |
Add optional metadata to initiliaze the render threat. The render threat is likely to break your application if you initiate it. As such it must be explicitely requested using the following meta-data tag in your manifest's application tag: <meta-data android:name="android.graphics.renderThread" android:value="true" /> Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
2eecea3b48ece6f45b30fef9b41dc20075ccc94f |
|
01-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Speedup the accessibility window querying APIs and clean up."
|
c6fd88e213703a581fe4680259981f09ae0444f2 |
|
26-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus. The framework tries to have a focused view all the time. For that purpose when a view's focus is cleared the focus is given to the first focusable found from the top. The implementation of this behavior was causing the following issues: 1. If the fist focusable View tries to clear its focus it was getting focus but the onFocusChange callbacks were not properly invoked. Specifically, the onFocusChange for gaining focus was called first and then the same callback for clearing focus. Note that the callback for clearing focus is called when the View is already focused. Also note that at the end the View did not clear its focus, hence no focus change callbacks should be invoked. 2. If not the first focusable View tries to clear focus, the focus is given to another one but the callback for getting focus was called before the one for clearing, so client code may be mislead that there is more than one focused view at a time. 3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup was calling the super implementaion when there is a focused child. Since there could be only one focused View, having a focused child means that the group is not focused and the call to the super implementation is not needed. 4. Added unit tests that verify the correct behavior, i.e. the focus of the first focused view cannot be cleared which means that no focus change callbacks are invoked. The callbacks should be called in expected order. Now the view focus clear precedes the view focus gain callback. However, in between is invoked the global focus change callback with the correct values. We may want to call that one after the View callbacks. If needed we can revisit this. Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
79311c4af8b54d3cd47ab37a120c648bfc990511 |
|
18-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Speedup the accessibility window querying APIs and clean up. 1. Now when an interrogating client requires an AccessibilibtyNodeInfo we aggressively prefetch all the predecessors of that node and its descendants. The number of fetched nodes in one call is limited to keep the APIs responsive. The prefetched nodes infos are cached in the client process. The node info cache is invalidated partially or completely based on the fired accessibility events. For example, TYPE_WINDOW_STATE_CHANGED event clears the cache while TYPE_VIEW_FOCUSED removed the focused node from the cache, etc. Note that the cache is only for the currently active window. The ViewRootImple also keeps track of only the ids of the node infos it has sent to each querying process to avoid duplicating work. Usually only one process will query the screen content but we support the general case. Also all the caches are automatically invalidated so not additional bookkeeping is required. This simple strategy leads to 10X improving the speed of the querying APIs. 2. The Monkey and UI test automation framework were registering a raw event listener for accessibility events and hence perform connection and cache management in similar way to an AccessibilityService. This is fragile and requires the implementer to know internal framework stuff. Now the functionality required by the Monkey and the UI automation is encapsulated in a new UiTestAutomationBridge class. To enable this was requited some refactoring of AccessibilityService. 3. Removed the *doSomethiong*InActiveWindow methods from the AccessibilityInteractionClient and the AccessibilityInteractionConnection. The function of these methods is implemented by the not *InActiveWindow version while passing appropriate constants. 4. Updated the internal window Querying tests to use the new UiTestAutomationBridge. 5. If the ViewRootImple was not initialized the querying APIs of the IAccessibilityInteractionConnection implementation were returning immediately without calling the callback with null. This was causing the client side to wait until it times out. Now the client is notified as soon as the call fails. 6. Added a check to guarantee that Views with AccessibilityNodeProvider do not have children. bug:5879530 Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
44d79747b5e434e8f43928b5548442c65e40e5c3 |
|
13-Jan-2012 |
Romain Guy <romainguy@google.com> |
Remove unused parameter Change-Id: I0896b2cdb9f1fa9c5e191e4ea425e22ac6f10f29
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
bdc18b28eb04b8c8cc00313096f8bfb142e407e3 |
|
09-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
am 03e63427: am 8e0ecbfc: Merge "Shortcut keys should be handled on down, not up." into ics-mr1 * commit '03e634270d880407316b51fac2278e604fc82703': Shortcut keys should be handled on down, not up.
|
7bedf2449041a425899448cb672e91b0a5c97c62 |
|
08-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Shortcut keys should be handled on down, not up. Bug: 5720360 Change-Id: I3afc278e576ea992c76f024c8b6bad14b214239c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
07069a04ef2e52ad6cebd9041b5288bebd811a38 |
|
07-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix PIN pad. Some widgets apparently inject keys into the ViewRoot by sending a DISPATCH_KEY message to its handler. Ugh. Bug: 5711577 Change-Id: Ibe9aaf705095d152ec866c536f31f5d85e27b97f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
96e942dabeeaaa9ab6df3a870668c6fe53d930da |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Use a Choreographer to schedule animation and drawing. Both animations and drawing need to march to the beat of the same drum, but the animation system doesn't know abgout the view system and vice-versa so neither one can drive the other. We introduce the Choreographer as a drummer to keep everyone in time and ensure a magnificent performance. This patch enabled VSync based animations and drawing by default. Two system properties are provided for testing purposes to control the behavior. "debug.choreographer.vsync": Enables vsync based animation timing. Defaults to true. When false, animations are timed by posting delayed messages to a message queue in the same way they used to be before this patch. "debug.choreographer.animdraw": Enables the use of the animation timer to drive drawing such that drawing is synchronized with animations (in other words, with vsync or the timing loop). Defaults to true. When false, layout traversals and drawing are posted to the message queue for execution without any delay or synchronization in the same way they used to be before this patch. Stubbed out part of the layoutlib animation code because it depends on the old timing loop (opened bug 5712395) Change-Id: I186d9518648e89bc3e809e393e9a9148bbbecc4d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
92cc2d8dc35f2bdd1bb95ab24787066371064899 |
|
02-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Remove type tests when recycling input events. Change-Id: I1c2d5980a763c457a0546bbf601e686c601a4c03
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
32cbc3855c2a971aa5a801fd339fb6a37db91a1a |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Refactor InputQueue as InputEventReceiver. This change simplifies the code associated with receiving input events from input channels and makes it more robust. It also does a better job of ensuring that input events are properly recycled (sometimes we dropped them on the floor). This change also adds a sequence number to all events, which is handy for determining whether we are looking at the same event or a new one, particularly when events are recycled. Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
4952dfd16a0f839559ffa78f5016394caf85294f |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Ensure input events are processed in-order in the application. As it turns out, it used to be possible for there to be multiple input events simultaneously in flight in an application. Although it worked, it made it hard to reason about what was going on. The problem was somewhat exacerbated by the introduction of a queue of "InputEventMessage" objects as part of an earlier latency optimization. This change restores order from chaos and greatly simplifies the invariants related to input event dispatch within the application. Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
95db2b20d7bc0aaf00b1d4418124f5cf0a755d74 |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Improve latency instrumentation. Change-Id: I4edfa0a5659d207f7e46722e48ffa1dc43d2aa13
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c0b7f65ae0594e19d1272e5caf2d83638041d19c |
|
29-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
am 496f6e2a: am b54980d1: Merge "Fix issue #5588689: Black camera preview after coming back from gmail" into ics-mr1 * commit '496f6e2ad656c5bb8a277e191554d16abd290b58': Fix issue #5588689: Black camera preview after coming back from gmail
|
b54980d1d4d903f68cdfa952256afff01902cd94 |
|
29-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5588689: Black camera preview after coming back from gmail" into ics-mr1
|
d3ea6b40bb8f0fbc2a877963db1ab4fa0fc02b2f |
|
29-Nov-2011 |
Chet Haase <chet@google.com> |
am 38928899: am 8990cb57: Merge "Fix flashing wifi dialog after rotating back from landscape." into ics-mr1 * commit '3892889952b0ad3fa0b095c96d8ae2ae110585e2': Fix flashing wifi dialog after rotating back from landscape.
|
08837c246c9c27902c59b41c8661c2f27a4aa2bc |
|
28-Nov-2011 |
Chet Haase <chet@google.com> |
Fix flashing wifi dialog after rotating back from landscape. There was an error in some of the OpenGL layer logic such that we would occasionally set up a layer for rendering and then not clean up when it was done. This caused future OpenGL rendering to go into that layer instead of to the buffers being displayed on the screen, resulting in artifacts including flashes and displaying of stale content. This happened specifically when using the wifi settings dialog with the InputMethod keyboard displayed, but it was probably visible in other situations as well. Issue #5628248: Flickering/flashing after entering password for WiFi Change-Id: I38139f620b310f4309570fa7224552d2ee633999
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6d05fd3c795088ac60f86382df5a66d631e8a0cb |
|
19-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5588689: Black camera preview after coming back from gmail Make surface management between SurfaceView and the window manager much more controlled, to ensure that SurfaceView always gets to report the current surface is destroyed before the window manager actually destroys it. Also a small tweak to allow windows that have a wallpaper background to still have a preview window. This makes launching home after it has been killed feel much more responsive. Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3526b00a53a2582a51ff8b98ac1400a48f351107 |
|
22-Nov-2011 |
Romain Guy <romainguy@google.com> |
am c26e4d18: am 8cd39e3a: Merge "Notify views when EGL resources are about to be destroyed Bug #5639899" into ics-mr1 * commit 'c26e4d18a20ab0b3e769fb3e547994f1c27d6713': Notify views when EGL resources are about to be destroyed Bug #5639899
|
31f2c2e94656530fbf6282803e62edb47e9a894d |
|
21-Nov-2011 |
Romain Guy <romainguy@google.com> |
Notify views when EGL resources are about to be destroyed Bug #5639899 Change-Id: I7c5d8bebf02294426f5b3ab1358a31c38a4fd064
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
1333742bedc9b462024302f302e3a7f27053df66 |
|
11-Nov-2011 |
Akwasi Boateng <akwasi.boateng@ti.com> |
am cb0db030: Merge branch \'ics-mr1-plus-aosp\' of ssh://android-git:29418/platform/frameworks/base into ics-mr1-plus-aosp * commit 'cb0db0306b5849a35d3d99eea1b34ce019c6f0d8': Make the overridden ImageView#setVisibility remotable Clamp non-monotonic stats instead of dropping. DO NOT MERGE. Fix leak in LayoutTransition Fix lastVisible/global rects Fix Wimax-less build. Fix leak in LayoutTransition Deferring wallpaper update to improve workspace scrolling (issue 5506959) Terminate EGL when an app goes in the background boot animation is dithered and scaled Fix NdefRecord byte-stream constructor. PopupWindow dismiss() can get into a recursive loop. Fold WiMAX state into the mobile RSSI. Remove dedicated wimax icon to fix RSSI layout.
|
8ff6b9ebeeb24a6161ec6098e6bfdf8790ee5695 |
|
10-Nov-2011 |
Romain Guy <romainguy@google.com> |
Terminate EGL when an app goes in the background This does not happen on high end gfx devices. This happens only if only one EGL context is initialized in the current process. Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
2a639347aebb56febdef21a78c70fb0433adc1e5 |
|
05-Nov-2011 |
Chet Haase <chet@google.com> |
resolved conflicts for merge of aa4d2f69 to master Change-Id: Iadb63ecf52d8bd2911276fa3db55a43c9c378620
|
1f4786bbe1ed7ae54b94cd52c0e1a4a826fecd68 |
|
02-Nov-2011 |
Chet Haase <chet@google.com> |
Improve Launcher drag performance. Launcher swiping looks choppy. It's because we deliver the motion events of the drags asynchronously, and sometimes we may get an event to redraw before the motion event is posted, so we end up drawing again without updating to the latest motion information. This fix makes input event processing more proactive. Every time we run ViewRootImpl.performTraversals() (which is what happens whenever we need to layout, measure, and/or draw), we first process all pending input events, ensuring that we are completely up-to-date with posted events prior to drawing, so that the drawing we do is synchronous with the events we've received. This eliminates the choppiness and means that we can now get the full refresh rate on the screen with drag events. The fix was done for Launcher, but it is pervasive in the system, so this may fix other laggy drag behavior as well. Change-Id: I8dbed6acadc2662f317f736e769f536f555701aa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f31aba7346c6991ac8848f3b3992651a68781a10 |
|
29-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build breakage due to bad merge. Change-Id: I2804bccc44e061229c3f7b2ad9e00b9e0a0ba916
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
f79f476fd1e25d3d7bf77e890d064a503537e939 |
|
29-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
resolved conflicts for merge of c00d2ddc to master Change-Id: I075cc5b5df2909152ee463f8a0c7534344b47c62
|
af5b4f471df108ffbe1c3861d18b2141710d7bf8 |
|
28-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing a memory leak in accessibility enteraction APIs. 1. AccessibilityInteractionConnection was non-static inner class, hence keeping a handle to the enclosing ViewRootImpl resulting in leaking activities. bug:5525412 Change-Id: Ie438861663d623d503995844125d9e15d677fc32
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
021078554b902179442a345a9d080a165c3b5139 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding APIs to enable reporting virtual view hierarchies to accessibility serivces. Added an interface that is the contract for a client to expose a virtual view hierarchy to accessibility services. Clients impement this interface and set it in the View that is the root of the virtual sub-tree. Adding this finctionality via compostion as opposed to inheritance enables apps to maintain backwards compatibility by setting the accessibility virtual hierarchy provider on the View only if the API version is high enough. bug:5382859 Change-Id: I7e3927b71a5517943c6cb071be2e87fba23132bf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
972b7d2c3bbb54a61a505d9d78927a158356ffb6 |
|
21-Oct-2011 |
Gilles Debunne <debunne@google.com> |
Merge "Typo in ViewRootImpl"
|
5ac84423a28fea4924eb1c389d647defe1c1b93c |
|
19-Oct-2011 |
Gilles Debunne <debunne@google.com> |
Typo in ViewRootImpl Change-Id: I4a5acfb091ce05f56cdbaa0a56809f377cbf9b39
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
841d79497d9eff2d4df6948380b79db316d24dc3 |
|
18-Oct-2011 |
Chet Haase <chet@google.com> |
am 87bc53de: Merge "Make notification panel delete-all animation smoother" into ics-mr0 * commit '87bc53de2adf479ad5a5e226bf3d8fd31af6dc21': Make notification panel delete-all animation smoother
|
2f2022afa1eb85018368398bd150e9575fc099c9 |
|
11-Oct-2011 |
Chet Haase <chet@google.com> |
Make notification panel delete-all animation smoother Making the notfication delete-all animation smoother by carefully choreographing the various parts of it. The problem with the previous animation was that there was simply too much going on at the same time, causing things like layout and recreating display-lists in the middle of animations that became choppy as a result. This approach swipes all items off quickly, then scrolls the shade up to the top, making both sets of animations smoother as a result. Fixes #5431207: Notification delete-all should be smoother Change-Id: Iefe8ab5d661e05adcd10379dab85227d17904450
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
856d4e1a872b5aed6792b33e0360554cb3d19eed |
|
15-Oct-2011 |
Romain Guy <romainguy@google.com> |
Disable hardware acceleration for apps in compatibility mode Change-Id: I2d1c01a30c6fe6fff85c2a9bd6ee6de98e1ed422
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
85b9edf2da0534bc53d139bb88cda8866d265afe |
|
07-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately"
|
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/ViewRootImpl.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/ViewRootImpl.java
|
2588a07730ff511329c87b5f61b20419b2443d48 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "The logic for not populating text to some accessibility events is scattered."
|
2cdedffcfa5594f9d516fa235d5edf4d4f92c21d |
|
03-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility services cannot obtain the source of an event coming from a root namespace descendant. 1. The user can touch the screen at an arbitrary location potentially crossing the root namespace bounday which will send an accessibility event to accessibility services and they should be able to obtain the event source. Also accessibility ids are guaranteed to be unique in the window. Added a package scoped findViewByAccessibilityId method that dives into nested root namespaces. 2. Added accessibility support to the AnalogClock. bug:5405934 Change-Id: I84edcb554bae41aafcbbc2723c5e62c1ef8a6ddf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
82e236d72ac197d6673d0b4d484fe5f0b9436731 |
|
30-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
The logic for not populating text to some accessibility events is scattered. 1. Some accessibility evenents should not and were not dispatched for text population but there was no centralized location for enforcing this - rather the system was firing them in a specific way or there were conditions in a few places enforcing that. Now this is centralized and clean. 2. Updated the documentation with some new event types the were lacking. 3. Explicitly stated in the documentaition which events are dispatched to the sub-tree of the source for text populatation. bug:5394527 Change-Id: I86e383807d777019ac98b970c7d9d02a2f7afac6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
4f59f8be0e177435a9a493668a74c793971b3bb5 |
|
16-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5300880: setSystemUiVisibility() always triggers a surface reallocation Change-Id: Ia0a9d8acba6b62ef095e4c615099466c52eec8e4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
ea515aeafa01de6f50c854ee381b972ef2478284 |
|
15-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Update the public APIs for finding views by text to optionally use content description. 1. Added flags to the search method to specify whether to match text or content description or both. 2. Added test case for the seach by content description. 3. Updated the code in AccessibilityManager service to reflect the latest changes there so test automation service works - this is the fake service used for UI automation. Change-Id: I14a6779a920ff0430e78947ea5aaf876c2e66076
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
180c48489f07ebd748700a5a312070583fefdb45 |
|
13-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5309443: Ninjump crashes on boot with... ...java.lang.IllegalArgumentException: Window type can not be changed after the window is added Change-Id: I4e34622c99d721fa214fd534a9bbfc8006184770
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
aacbf9111b58f10f7474fbd3a8debb02713f8b18 |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Not visible view should not be announced or interacted with."
|
0b0a41d8e26eaf0f1d9d922621494daf40964a9a |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Not visible view should not be announced or interacted with. 1. Some invisible views' text was reported by accessibility events. 2. Accessibility actions could have been perfromed on invisible views. bug:5264355 Change-Id: I68184fb436a3e10e947ec6f1eae02aa3d0d1cb7f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
d56c6951755a902a354e13e5fa05fb0984132cc6 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Add end functionality to LayoutTransition This new hidden API is called by ViewRootImpl when there is a pending transition but the parent window is not visible. Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3791dc9b1c849bfacbff6de7fb53b77f414d1e4b |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Merge "Fix issue with LayoutTransition on non-visible windows."
|
61158c621d0834d6d4e1e0310596d9b7a1071178 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Fix issue with LayoutTransition on non-visible windows. There's a problem with how LayoutTransition cleans up after itself when the target view is in a Window that is not on the screen. The quick fix is to always start (and therefore properly end and clear) transitions, regardless of whether the window is in the tree. Change-Id: I23f4f4f04176f3943e5c6e1d78acba0190a96930
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
6b0c11da5a7a7ea236fd9dc409d1ce7a33bff9c2 |
|
03-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5150899: Call activity takes 15MB we never get back."
|
3c4ce72c4d66d9ee041924259f20381b658c1529 |
|
03-Sep-2011 |
Chet Haase <chet@google.com> |
Fix artifact with LayoutTransitions on disappearing window. Logic in performTraversals() starts a transition running at the proper time. But when a view's parent window goes away, this transition may not start at that time because drawing gets canceled. But the transition still hung off of the ViewRoot, waiting until some later drawing operation to kick it off. This resulted in some weird animations like the Recents panel appearing and having a single item animate off of it. The fix is to delete pending transitions when drawing is skipped. Change-Id: I3ab7702c16e069644a163424f977350743e2cecc
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
08a1c04b9668e51ca3043a4e531b7649b018b245 |
|
01-Sep-2011 |
Romain Guy <romainguy@google.com> |
Merge "Dispatch onDetachedFromWindow before destroying everything Bug #5245686"
|
16260e73f6c1c9dc94acf0d328a3c564426b8711 |
|
01-Sep-2011 |
Romain Guy <romainguy@google.com> |
Dispatch onDetachedFromWindow before destroying everything Bug #5245686 Change-Id: I637178ee0bb47fbec9b59198b388bb8de22c1786
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
eca9b1f53c2c291cbfb89b5f3cc45db7bdca6c7d |
|
26-Aug-2011 |
Romain Guy <romainguy@google.com> |
Prevent crash in VPN settings Bug #5217245 Change-Id: Ibacf4cbd40537cd417f1518b5ac4367a3f3d7d03
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
12bde60b39affbfdcb7ef6317e0a5f99c3f41b10 |
|
25-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Intra-process view hierarchy interrogation does not work."
|
6ff0037792619c4441d9d3caa4f9ab4f45c11236 |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix to show the correct HW accel background in the preview window."
|
07213e6d8895af10951851435adf96a779863f6c |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix to show the correct HW accel background in the preview window. Also tweak wallpaper service to do a cleaner transition to a static wallpaper. Change-Id: I876a32091f92dd5a529d7fd809d3b8e730bb7d2a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
fa6b35be126ffcc3b5818393c26aff724ac65daf |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5050039: Launcher is sometimes rendering underneath the system/status bar It looks like this is caused by the change in HC to stop activities when the screen is off. ViewRootImpl (a.k.a. ViewRoot) has special code to avoid doing work when it is stopped, and it is now stopped when the screen is off. The problem here is if the window's activity is stopped when the window is first displayed, then it would never do the initial fitSystemWindows() with the status bar offsets given by the window manager, and never do this again until the status bar changes. Also included here is some re-arranging of the code dealing with the offsets changing, because it was dealt with in two places and only one had a bunch of code dealing with HW accelerated drawing and performing the fade transition between states. Now all of that is unified into one place. Change-Id: I9828f02664cc622dbf186effb1f685a8aa4456a1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
8bd69610aafc6995126965d1d23b771fe02a9084 |
|
23-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Intra-process view hierarchy interrogation does not work. The content retrieval APIs are synchronous from a client's perspective but internally they are asynchronous. The client thread calls into the system requesting an action and providing a callback to receive the result after which it waits up to a timeout for that result. The system enforces security and then delegates the request to a given view hierarchy where a message is posted (from a binder thread) describing what to be performed by the main UI thread the result of which it delivered via the mentioned callback. However, the blocked client thread and the main UI thread of the target view hierarchy can be the same one, for example an accessibility service and an activity run in the same process, thus they are executed on the same main thread. In such a case the retrieval will fail since the UI thread that has to process the message describing the work to be done is blocked waiting for a result is has to compute! To avoid this scenario when making a call the client also passes its process and thread ids so the accessed view hierarchy can detect if the client making the request is running in its main UI thread. In such a case the view hierarchy, specifically the binder thread performing the IPC to it, does not post a message to be run on the UI thread but passes it to the singleton interaction client through which all interactions occur and the latter is responsible to execute the message before starting to wait for the asynchronous result delivered via the callback. In this case the expected result is already received so no waiting is performed. bug:5138933 Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
50d133e290468fd149b5c03e46549afca2ee05f8 |
|
13-Aug-2011 |
Romain Guy <romainguy@google.com> |
<blink/> is not an acceptable default behavior. Bug #5156334 Change-Id: I9f803b090e81f4e490d0cccd6347a0f9f64bd20f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
70a3f677bf015d8641f41d149b76d362bb2b801c |
|
08-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5016544: IME keyboard hides folder rename text field. Tweak some issues in TextView with the focus rect used to determing where the scroll position needs to be. The ultimate problem was that in various situations it would use the right-most selection position cursor as the scroll location and when it adds 1 to make this a valid rect we end up with a rectangle that is outside of the view. Change-Id: Ia200c58e4e014d2a0a1be4761f9a1e5eb702a8e5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c3166e15f8898a2ba66fb177efbddb1d0edf6140 |
|
09-Aug-2011 |
Romain Guy <romainguy@google.com> |
Don't draw more than what we need. Change-Id: Ifeac66d379a48e8a1124188125e029421eb24226
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
1d0c708961f824ac5171238c205a7bf328d5d8a5 |
|
04-Aug-2011 |
Romain Guy <romainguy@google.com> |
Destroy the EGL surface when the ViewRootImpl surface is invalid Bug #5109839 Change-Id: Icebde9abf43b852397a73ffef519004993b46901
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
cf15efba0792b052dca5baa350d9fb00e6a60667 |
|
02-Aug-2011 |
Romain Guy <romainguy@google.com> |
Properly cancel pending buffers on window size change Change-Id: Id6108ce61a971673f3ebc8270e9dd00849c91ae5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c68c913d357e2955d4bd7ca52829071e531c7825 |
|
29-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Various work on out of memory managment. - Improve how we handle processes that have shown UI, to take care of more cases where we want to push them into the background LRU list. - New trim memory level for when an application that has done UI is no longer visible to the user. - Add APIs to get new trim memory callback. - Add a host of new bind flags to tweak how the system will adjust the OOM level of the target process. Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
ea83503e8683531fac2534047e50bc1e5979b6dd |
|
29-Jul-2011 |
Romain Guy <romainguy@google.com> |
Don't create hw layers when there's no hw context. Bug #5093805 Change-Id: Ia58b3381c83b9a200e80020e5c1b9c337ad6c35c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
b6f7a27c59fd170b5d7617e43e21bfd8587f234e |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Reclaim more memory, more often."
|
65b345fa22b878e141b8fd8ece9c208df00fa40f |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Reclaim more memory, more often. Yay. Change-Id: I04557ad575c307a55088549f48f0e9ad994b7275
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
c8ec222cd8e7d7056b0f01018ac0c38d2c7204c0 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Destroy layers and flush layers cache when a window is destroyed."
|
6d7475d666baefaa3ba9f0dcee25238739454241 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Destroy layers and flush layers cache when a window is destroyed. Change-Id: I3fa1bc3ff50fb99e3d2e490925bd6b0a0f809fff
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
3d5a703db83265f7914eed8580de986106abfad2 |
|
28-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Report the external display size to the input reader."
|
912a7b32d0c59ba38265c5dd6ff84ce93f909a7f |
|
27-Jul-2011 |
Romain Guy <romainguy@google.com> |
Make sure we have a current EGL context when invoking EGL Bug #5081795 Change-Id: Iee3382d362a71c1e6c5c498b319bf7f7bcf5a2f0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
bc68a59c024bdb745dac8e2ec7408a9f30595f1a |
|
25-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Report the external display size to the input reader. The input reader needs this information so that it knows how to interpolate touches on an external touch screen. Changed Display so that it asks the WindowManager what the real display size is (as opposed to the raw display size). This means it now takes into the forced display size set by adb shell am display-size. Replaced all calls to getRealWidth() / getRealHeight() / getRealMetrics() in the WindowManager and replaced them with direct usages of the mCurDisplayWidth / mCurDisplayHeight so that the WM doesn't end up making a reentrant Binder call into itself. Fixed the table status bar HeightReceiver so that it updates the height on all configuration changes since it is possible that the display size changed independently of an external HDMI display being plugged / unplugged. Improved the Display class documentation to make the distinctions betweeen the various sizes clearer. Change-Id: I3f75de559d3ebffed532ab46c4ae52c5e7f1da2b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
6dd005b48138708762bfade0081d031a2a4a3822 |
|
18-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
I. Can. Not. Stand. ViewAncestor. It was done so we would have the name "ViewRoot" available for a public API. However, the name "ViewAncestor" just makes no sense. So instead, change it to ViewRootImpl. Change-Id: If9599ca67896f339f6fefa7d1dde121201171d97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|