It is useful, particularly in animations, to be able to add a view, or at
least some graphics, on top of a view. For example, to have a child of a layout
fade away, we might want to remove the child from that layout and then fade it out
gradually. Meanwhile, we have to have a place to put that view where it will be
drawn. We could do this in the content container sometimes, but this is not a
reliable workaround in the general case, and may obscure other siblings/parents of
the layout/view in the hierarchy. A better approach would be to place a view/graphic
temporarily in the layout itself.
This feature adds the ability to add one or more Views and Drawables to an "overlay"
layer, after which the view will handle drawing that extra content when it redraws itself.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I70bf78c46ee3db8bd87ea1cdc2ecb5c0747ccbf9
In general, calling requestLayout() during layout is a Bad Idea.
However, ListView does this during the normal course of its layout, as it
removes and adds views during layout. However, it handles this properly,
ensuring that the views in its hierarchy are all measured and laid out
properly by the time its layout process is done.
A previous fix to the request-during-layout issue attempted to distinguish
the correct from incorrect behavior by checking whether views had been properly
laid out since the requestLayout() call, and making sure the views were
visible in the hierarchy (parented, attached, and !GONE), since otherwise
the views would not be laid out, the flags wouldn't be cleared, and requests
are superfluous anyway. However, this logic only checked whether the
requesting views were GONE, whereas the check should include the entire
parent hierarchy of the views (since a view with a GONE parent is still not
visible to the user).
This fix adds that additional check and cleans up other parts of the previous
code, such as not bothering to post() requests that occur during the second
layout pass unless those requests are also valid (coming from visible views).
Issue #8370042 Path seems to be in an infinite layout loop
Change-Id: I7aaf701229adfeee349a9a7c9ec14585735ba9f6
Fix a few things found in our "Constants" section.
- Close unclosed links.
- Avoid periods inside parens for summary sentences.
- Lowercasing in a few places for consistency.
Change-Id: I9aa689fd980b373614dae7c4f8257e0786d2340a
While the inset scrollbars may change padding and how backgrounds are
drawn such that an otherwise opaque view is no longer opaque. However,
OUTSIDE_OVERLAY scrollbars don't change the padding and should not
affect the determination of opacity.
Change-Id: I8c0c1408aeb540813de3351f0c0d1ad12ba5919c
This does not change anything in the practice since the only
time where timing of the endBatchEdit() call matters is when
sendCurrentText is a no-op. Still, it's theoretically correct
to do it in this order.
This concludes a four-step refactoring moving where the
editor calls updateSelection to warn the IME of a cursor move.
Change-Id: I3109a482ec1d4cd9b4ffb33cc363a4ce5128861a
This is a class representing a window and providing limited
interaction with it, which can be handed across processes.
Change-Id: I22885f2064a9cc8c68d690a5858c2e28bbb6a0f3
A Surface can trivially be created from a SurfaceTexture.
Update ElectronBeam to use this new API.
Bug: 6940974
Change-Id: I20459443d0d853e3f8ae23104c08d185c336abea
Removing view groups during a drag would cause an NPE here. The
child views will still get the drag-ended event as expected.
(Cherrypicked from downstream)
Bug 8298439
Change-Id: Ic14cbf9fdc305b91c1627f6882a45d34ee1c34ae
Removing view groups during a drag would cause an NPE here. The
child views will still get the drag-ended event as expected.
Bug 8298439
Change-Id: I665ba1d139e8aaa820f5f515186bc4ce8bcdb1ea
ListView child views with transientState (setHasTransientState(true)) are not
handled correctly when the data set changes, such as when an item is added
or removed. The problem is that the transient views are cached by their
position, but this position is out of sync between the ListView and the adapter
until the ListView layout process is complete.
A better way, which unfortunately only works on ListViews with stable IDs, is
to cache the views by their itemID instead, and to use that ID to determine when
and where to reuse/retrieve a transient view during the ListView layout.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: Ic3b1669ed79dd6cf9e4c1c6c26f9d75ccf074b3e
Bug #8230990
ViewRootImpl needs to know when the native Surface objects changes
to recreate the EGL surface. A recent refactoring in Surface broke
the behavior of getGenerationId(). This simply restores the old
behavior (every change increments the generation ID by 1.)
Change-Id: Ife1df1ffb2ee7a373b8ebf2431192702ba10f344
The system and some processes such as the keyguard and system UI
run across users. Hence, the local accessibility manager should call
into the backing system service with the id of the current user.
For all other processes the local manager uses the current user id.
There was a method that is to be called before the local accessibility
manager has been accessed to initialize it to work across users.
This had to be done for keyguard and system UI.
This change removed the workaround and now the local accessibility
manager determines under the hood which user id to use while calling
into the system. If the local manager is in the system process or
its process has permissions to work across uses, the manager uses
UserHandle.USER_CURRENT, otherwise it uses the user if its process.
Change-Id: I3e97fe98805adca01c1a0127a276828e90926f95
