Optimizations in drawing and invalidation in JB did not correctly
account for static child transforms
(View.getChildStaticTransformation()).
For the invalidation part, this meant that views were not properly
setting the invalidation bounds (which should be transformed by
the static transform), so the affected area of the invalidation
was potentially incorrect. For the drawing part, this meant that
views outside of their parent's bounds were being incorrectly
rejected when the static transform would, in fact, place the views
inside of those bounds.
The fix is in two parts:
- drawing: avoid the early quickReject() logic for containers that
have static transformations set on them
(ViewGroup.setStaticTransformationsEnabled()).
- invalidation: Include the static transform in the invalidation
area propagated up the view hierarchy.
Issue #6864203 The child position outside of parent is not drawn
even it will be drawn inside of the parent after applying static
transformation
Change-Id: I73bea01feab250bdcae2d575313be355a4a3c8f5
The objective of this refactoring is to remove the reliance on
WindowManager wrapper objects for compatibility mode and for
managing sub-windows.
Removed the WindowManager.isHardwareAccelerated() method since
it is never used.
Change-Id: I4840a6353121859a5e0c07d5cc307a437c595d63
1. If a view's important for accessibility attribute is set to auto the
framework is responsible to determine if it really is. Views with
accessibility node providers should be important for accessibilty
since they are roots of virtual view trees and such trees are
always important.
bug:6843043
Change-Id: I4b352c59fdefdf9ad220714a43ecb9e01d1c1c1f
Bug 6448164
generateViewId provides a way for applications to generate opaque ID
values suitable for use with View#setId that will not collide with
values generated by aapt for R.id.
Fix a bug where RadioGroup assumes object hash codes will always be
positive.
Change-Id: I3e2870cd672d6061bb465128f428c81aeef0c44b
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
View.draw() calls computeScroll() to initialize scrolling values correctly.
But getDisplayList() also calls computeScroll() for the same reason, resulting
in 2 calls to that method for hw-accelerated views.
Fix: avoid calling computeScroll() in View.draw() for views with display lists.
Change-Id: I57a3862e2d554752cd0fdb862513cbb3dfb3105c
Before this change, changing a View's opacity would not be reflected
by hardware layers. This could cause layers to retain their previous
opacity.
Change-Id: Iba2c8b4242deca021651df9324cc7c585a64653d
1. If the application does not accommodate different screen density the
system applies an application scale equal to the device density over
the a default density. The AccessibilityNodeInfo coordinates were not
reported after applying the compatibility scale, therefore the bounds
in parent and screen were not as perceived by the user.
bug:6764586
Change-Id: Id9de3de885210d0725d1f3fde38e769b0cfd12a7
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
1. If the application does not accommodate different screen density the
system applies an application scale equal to the device density over
the a default density. The AccessibilityNodeInfo coordinates were not
reported after applying the compatibility scale, therefore the bounds
in parent and screen were not as perceived by the user.
bug:6764586
Change-Id: Iae2d6ea81049364194c7cb09df2240b5eda3d939
1. The purpose of the View#announceForAccessibility method is to
give a message to the user that is not related to a predefined
view state change. The current implementation is grabbing the
source view's content description which in general overrides
the event text which defeats the purpose of the announcement.
bug:6721440
Change-Id: I8814914bea38c5f4c04f57391a64cf2bb06cb975
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
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
allow to resolve it even more lazily: if resolution is asked then do it
only if possible (the View needs to have a parent that can also do its
resolution)
Change-Id: I8e808f0ef392521e59b27b82f86e9058f20af9ba
