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
Apps using SYSTEM_UI_FLAG_HIDE_NAVIGATION to hide the nav bar
or SYSTEM_UI_FLAG_FULLSCREEN to hide the status bar can now
opt into hideybars by also using a new public sysui flag:
View.SYSTEM_UI_FLAG_ALLOW_OVERLAY
When opting in, apps accept the fact that bars can be overlayed
over their content, but gain the ability to use the entire gesture
space - something that was not possible before, particularly when
hiding the nav bar.
Swiping from the nav bar edge of the screen will reveal the new hidey
version of the nav bar, if applicable.
Bug: 8682181
Change-Id: I6405bee50e6516667ba6b9a62d4f1e43490b5562
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
The counter can be enabled by setting the system property called
debug.hwui.overdraw to the string "count". If the string is set
to "show", overdraw will be highlighted on screen instead of
printing out a simple counter.
Change-Id: I9a9c970d54bffab43138bbb7682f6c04bc2c40bd
