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
This checkin has preliminary API (in flux, definitely changes still
to be made) and implementation for a new "Scenes & Transitions" feature.
The current implementation allows you to define different Scenes
(via layout resource IDs or callbacks) and Transitions to be used when
changing to those scenes. By default, scene changes will use AutoTransition,
which generally does the right thing.
There are no overview docs or tutorials yet. The best way to learn how things
work is to see the code for the various tests in
frameworks/base/tests/TransitionTests.
Expect the API to change. Expect the implementation to change (mostly to add
more functionality). Expect bugs, but tell me if things do not work
as expected.
Change-Id: Ib025a9f565678b225afa4759325cf6d496cc7215
Fix a few typos in InputFilter. Fix reference in InputEvent currently
causing public documentation breakage.
Change-Id: I6268ad165f11d4d9d5a4a66ed97f1538e174cf84
The invalidate region when the clip bounds are set needs to encompass both
the old clip bounds and the new bounds, to make sure that the right area
of the view gets erased as well as drawn.
Also, we need to keep our own internal copy of the bounds, not just use the
instance passed into the setter.
Issue #8634060 setClipBounds() problems
Change-Id: I123c49cff16e3debe8866974a5612a4efd010de4
Implement new mode for status bar, allowing it to overlay
windows that use WM.LP.FLAG_FULLSCREEN, and introduce
transparency.
No gesture is implemented yet, for now the auto-hiding
status bar can be shown using a debugging intent.
android.intent.action.HIDEYBARS
The auto-hiding status bar hides 3 seconds after shown,
or 3 seconds after last user-interaction with the shade.
Change-Id: Ie4bd625b9cbcddea8f818154719c7a6075972f2a
Adding a view to an overlay usually entails removing the
view from its current parent, if it has one. ViewOverlay.add() will
do this automatically. At the same time, it will check to see whether
the parent view is in a different global location than the overlay's
host view, and will adjust the added view accordingly. This enables
the caller to simply toss a view into an overlay and have it end up
at the same global position on the screen.
the problem is that the current code doesn't bother to check whether
the old parent is attached. If that parent has been removed from the
view hierarchy before this overlay operation, then it will show up as
being at (0,0) in the window, not its old location. This results in the
view being mis-positioned in the overaly.
Fix is simple: if the view's old parent is not attached, simply remove
it from that parent before adding it to the overlay; don't try to compensate
for its position which is based on wrong information.
Issue #8620319 Overlay should only use relative window locations for onscreen parents
Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
Split stacks and move tasks between them. Layout the windows
according to the new stack split.
After layout content rectangles are known split the available area
between all stack boxes. Then use those values for future layout.
Provide stack contents to ActivityManager.
Change-Id: I9746e6185445633810d506be514d0b7b540a7f99
