Bug #8667873
windowShouldResize means we need to layout the window, it doesn't mean
the dimensions of the surface have changed. We should only check the
width and the height. With this fix we can avoid a surface allocation
every time the window shade is opened or closed.
Change-Id: I8afe97b820a865723f2aab7a5aa4ddc8eaaec6e1
View.getOverlay().clear() can failed with an NPE if there are
no drawables in the overlay. Fix: add a null check before dereferencing
the mDrawables field.
Issue #8895794 getOverlay.clear() crashes if drawables were not added previously
Change-Id: I9b2a63036450915681ba3a89a0911e2490063702
We are prefetching accessibility node infos to minimize the number of IPC
calls when an accessibility service introspects the screen. It is however,
possible that the view we are prefetching is a child of an AbsListView whose
adapter changed its data but the AbsListView still did not perform a layout
pass to sync its children with the new adapter state. This may lead to an
exeption when trying to query for the state of a child's position. If the
data of the adapter is changed and the layout pass still not performed,
we return null for the AbsLIstView's children. When the layout pass
completes we already notify the accessibliity layer so it will be able to
refetch the children of the AbsListView.
bug:8433433
Change-Id: I56313c721aef3848b15fad50027d068ba1d291f7
Different devices have different precision, leading to different pixels
being touched during rendering operations. We need to ensure that the
dirty rect we draw with (and which gets erased on the following frame)
encompasses all possible pixels instead of some ideal rounded rectangle.
The bug from this code led to dropped-pixels artifacts on some devices,
where we'd scale a view, drawing it into some pixels, then invalidate
that same area on the next frame, but the invalidation rectangle didn't
cover the same pixels as the device drew into.
The fix is to floor() the left/top pixels and ceil() the right/bottom
pixels of the transformed invalidation rectangle.
Issue #8971348 dropped pixel artifacts during some scaling operations
Change-Id: Iedb1afd5621dff43bf7a3919bdbd8d2251647fd2
We added APIs to allow an accessibility service to extend the
selection while moving the cursor at a given granularity such
as word, character, etc. The problem is that the traversal was
extending only the end of the selection while moving forward
and the start of the selection while moving backward. This leads
to a case in which the user cannot shrink/extend the selection
because for example instead of shrinking the end of the selection
the implementation was extending the start.
Now extending the selection moves only the selection end. This is
the same behavior as text view using a keyboard.
Tests: https://googleplex-android-review.googlesource.com/#/c/307062
bug:8839844
Change-Id: Id6965b102647df909f61301fcc8ec05458dd5881
AbsListView is backed by an adapter. After the adapter data changes
the view sets a flag that its state is dirty and requests a layout.
If an accessibility service asks for the state of a list item at
this point, it may incur an error since the views and the adapter
are not in sync.
Now if an accessibility service queries for a list item when the
data set is changed and the item views are dirty, we pretend the
children do not exist. After the layout happens, we notify the
accessibility layer that the screen content changed so it can
refetch the views if desired (this notification mechanism is
already in place in AbsListView#handleDataChanged()).
bug:8433433
Change-Id: I4287a0ac2ef6bb33f1f988d5ddad973556c305ca
Internal state must be cleared before calling any methods on the focus
host, since the method may be called again from the host and attempt to
recycle the same AccessibilityNodeInfo twice.
BUG: 8856860
Change-Id: I0410989fd6f3ce3ce29de8edebdfbf3847188843
- dont bother children about resolving RTL properties if the ViewGroup parent
has not done anything
Change-Id: Iedf8a337097e04e1ab0054d59fc347e06b347ea7
There were many places where the native object was being
accessed improperly. Also some places where CloseGuard might
not be acquired or released correctly or where the generation
count might not be updated.
Fixed them all.
That said, Surface isn't intended to be used concurrently
so please don't do it. This is only intended to make
hard to find crashes less likely.
Bug: 8328715
Change-Id: I981ef33425823e0fd7ad6b64443f2ec9b0c8335e
Fullscreen window's will not resize when the keyboard comes on screen,
regardless of the setting of the window's softInputMode field. This fix
clarifies the docs to make this behavior more obvious.
Issue #8754615 Clarify behavior of adjustResize and fullscreen interaction
Change-Id: Ie056db4e328cefaf0edb54fe8cfa7a08f320c8d0
Previously, onHoverEvent() would return true if a view was hoverable
and consume the event. After the change, it would return the result of
dispatchGenericMotionEventInternal(). As a result, touch exploration
caused multiple hover events to be sent from every view under a given
touch point. This change reverts to the original behavior and fixes
touch exploration.
BUG: 8723842
Change-Id: I0c7362f19c51bf21ed842711a03b7f02613958d2
bug:8666842
In SW rendering, a previous optimization avoided clipping to the
bounds of views that are layers. This breaks if the view fails to
create a layer (such as if it's too big), so instead look at whether
the view has a layer.
Change-Id: I653882035512012aefd91f06ff0bdc73aa5e4430
1. The accessibility events for switching a widget were dispatched
before we update the important for accessibility property. We
were lucky to get events in some cases since the pages in the
pager had alpha grater than zero, i.e. the page was already
set as important for accessibility, due to a running animation.
2. Accessibility focus clear event not fired if we give focus to
another view. The old focus was correctly cleared just the
events were not dispatched.
bug:8599670
Change-Id: Ia2647d77eaa4e10fbaf3a047dc9ea5b728f9c3c3
A call to ViewGroup.bringChildToFront() or View.bringToFront()
(which delegates to the parent's bringChildToFront() method) needs
to be followed by a call to requestLayout() and invalidate() on the
parent container in order for the changes to
actually happen. That is, the order of the child views would change, but
the parent container would not run layout or even invalidation without
being told to, so there would be no visible change until something else
caused a layout and invalidation to occur.
This change clarifies this requirement in the javadocs.
Issue #8667065 bringtoTop does not work
Change-Id: Ibe41a6318dddf9fb79382e1c9fd1d21ab4510976
1. UiAutomation#executeAndWaitForEvent method was invoking the passed
runnable while holding the lock which may lead to a deadlock. For
example: a runnable that calls getActivity() gets us into a state
like this.
2. UI automation services did not get all capabilities such a
service can have. Now a UI test service gets all of them.
3. When UiAutomation was exiting for event fired as a result of a
performed action, it was checking whether the received evnet time
is strictly before the time of executing the command that should
fire the event. However, if the execution is fast enough, i.e.
less than one millisecond, then the event time and the execution
time are the same. This was leading to a missed signal in rare
cases.
4. AccessibilityNodeInfoCache was not clearing the relevant state
for accessibility focus clearing event.
5. Accessibility text traversal in TextView was partially using text
and partially content description - broken. Now we are using the
text since for text view and content desc for other views. In other
words, we are using the most precise text we have.
6. AccessibilityManagerService was not granting capabilities of a
UiAutomation service - plainly wrong.
CTS change:https://googleplex-android-review.googlesource.com/#/c/300693/
bug:8695422
bug:8657560
Change-Id: I9afc5c3c69eb51f1c01930959232f44681b15e86
The node id does not have to be decorated with spans like spannable
so it makes no sense to have these APIs use anything else but string.
bug:8657338
Change-Id: I2e7c31128ee9f2933bd0d58beac4ba31a498bb09
The current invalidation logic does not take into account the clipChildren
flag. When this flag is set to false on a container (an uncommon but
possible case), it is possible for views in the child hierarchy of
the container to be draw outside of the container's bounds. But invalidations
on that view hiearrchy can be clipped to the container's bounds, causing us to
not redraw views outside of those bounds.
Fix is to expand the dirty rect of an invalidation to encompass the complete
bounds of any container with clipChildren==false.
Issue #680037 Some transform combinations can leave old pixel values on the screen
Change-Id: I426beee15d04145fac2f6b4203748ae309e392b4
The rendering code optimizes by rejecting drawing operations that
lie outside of the bounds of their views. This works in most
situations, but breaks down when containers have called
setClipChildren(false), because we reject drawing that is outside
of that container, but which should be drawn anyway.
Fix is to pass in the value of that flag to the DisplayList drawing
routines which take that flag into account when deciding whether
to quickReject any particular operation.
Issue #8659277 animation clipping
Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
Clarified use of rotationAnimation. Did not add a comment
for ROTATION_ANIMATION_CHANGED as that would be inconsistent
with the other twelve <parameter>_CHANGED flags that it
follows in the source code.
Fixes bug 8657715.
Change-Id: I03b5caf3d6a93ca0044f58485c94c7a600e835a8
- in RTL mode only and if you have left/start or right/end at the same time,
the initial left/right padding (coming from the background drawable or from
some explicit definition) was still used.
- now, override the background left/right initial pading by the left/right one
only and only if there is no start/end padding defined at the same time
(because when start/end are defined, we do not care about left/right padding
except the background ones)
Change-Id: Icc6e69c95ace1307b0c5e9673cbdf3b611b62733
