- resolve layout params in ViewGroup when layout direction is changed
- layout param resolution is checking the previous layout direction to
check if we need to resolve
Change-Id: I70af2ad2b4ec83c2ec6c93b3ff445852500d1687
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
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
- 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
- when adding a View to a ViewGroup reset all RTL properties of the View
to be added instead of only resetting its layout direction
Change-Id: Idfa3acce1700c52e20ebfd4c9c4f4ecb3c1d7520
1. Sometimes unlocking the device when the IME is up and triple tapping on the keyboard
toggles screen magnification. The core reason is that when the kayguard window is
shown we hide all other windows and when it is hidden we show these windows. We did
not notify the screen magnifier for windows being shown and hidden. Also when the
windows are shown we may reassign layers to put the IME or the wallpaper in the
right Z order. The screen magnifier is now notified upon such layer reassignment
since window layers are used when computing the magnified region.
bug:7351531
Change-Id: I0931f4ba6cfa565d8eb1e3c432268ba1818feea6
This change makes WindowManager use the new eAnimation flag when animating
windows. This prevents some of the window updates from being combined with
updates from prior animation frames.
Bug: 7353840
Change-Id: I5a9f8fa2c1a2f5f08363a45cd9f28bb97cd77080
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
Some View.post*() methods can be invoked from arbitrary thread
independently of whether the View is attached to a window.
Change-Id: I587b5909ab8b06665978d001548d56c8c22043c1
- do correct resolution and reset propagation for all RTL properties (padding and drawables included)
- fix CheckedTextView padding too
Change-Id: Ie603683a2324b2a6ef2c03633d01d5726c883b90
1. Since the content description is generated dynamically we need to notify
clients when it changes so they can drop cached state to get the most
recent content. This really is used by the caching we do to optimize
the window query APIs. Otherwise, the user does not see the current
content.
bug:7327556
Change-Id: I9be46508e86864566e027c64565eb1d787ec9363
1. If a view is clickable or long clickable perfroming the corresponding
accessiblity action should return true no matter whether there is a
registered on click/long click listener. Currently true is returned
only if there is a listener but it is also possible that a sub-class
overrides performClick and does work there. For example CompoundButton.
Now if the view is clickable or long clickable we will call the
perfrom* method and return true, which is we clicked.
2. Fixed some JavaDoc indentation.
bug:7318777
Change-Id: Id603fee378b8f7d07f1128b5641ede57640bab53
The new attribute allows an Activity such as the alarm to appear
on all users screens.
Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
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
1. There was a path for removing a view without clearing its accessibility focus.
Then when we try to draw the focused rectangle we get an exception since the
accessibility focused view is not attached to the view tree when computing
the location of the rectangel to draw.
bug:7297191
Change-Id: I81e3c35e830e27cf95e73accb665629d0c456afb
