This allows sending media buttons to any PendingIntent,
so they can be captured with a registered receiver.
Also add some new ViewTreeObserver APIs; this is all for
a new support library API to watch media buttons while an
app has input focus.
Change-Id: I3c51cef59460662b008c9a2cc87d6a6383c21855
Rather than wait for the IME to return before sending it the next input event,
send all available input events as soon as we receive them.
Bug: 7984576
Change-Id: Ie0b1086efc4f9e1ececac22afd997829304bf180
bug:8450062
- Fixes overdraw indication with DeferredDisplayList
- Fixes drawHardwareLayer called after flush
Additionally changes drawLayer to pass its paint to native via setLayerPaint
Wrap flush in save/restore so that reordering doesn't affect final
transform
Change-Id: I08befa42c28500da6387699eefd4be28aedf9f4c
Drawables added to a view's Overlay will now cause the Overlay to
be invalidated via the normal drawable-invalidation mechanism. That is,
changes to any of the drawables in the overlay should cause invalidation of
the proper area of the overlay and thus the hostView, causing the appropriate
area to be redrawn.
Also, fixed a bug in drawable invalidation so that bounds changes will now
correctly invalidate both the old and new bounds areas.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: Icae5fa0e420232ee17dc39be10084345bae8dbd8
it's still incorrect to use Surface from different
threads, however this shouldn't result to native crashes
anymore.
Bug: 8328715
Change-Id: I89ac5cc1218dc5aa0e35f8e6d4737879a442f0c6
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: I2fc25e71ed6655af30b9c3f47fdf014e9b667616
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 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
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
UiAutomation registers a fake accessibility service to introspect
the screen. Upon the death of the shell process that started an
instrumentation in which a UiAutomation resides the connection
between the UiAutomation and the system is kept alive allowing
the instrumentation to introspect the screen even after the death
of the shell process.
bug:8285905
Change-Id: I1a16d78abbea032116c4baed175cfc0d5dedbf0c
This also fixes "dead key -> same dead key" combination.
Both these key sequences should only give the non-combining
version of the combining character.
Bug: 8158374
Change-Id: I51f01685dd2997c2c5316ce6aa4f10ac9354c877
Keeping all activity=>task changes in master and removing them
from jb-mr2.
Revert "Update histories simultaneously."
Revert "Add null check to setAppGroupId."
Revert "Fix crashing bug in validator."
Revert "Switch topRunning* and moveTaskTo*"
Revert "Begin switch over to task based history."
Revert "Reset and reuse Iterators and don't new() one."
Revert "Remove AppWindowToken lists."
Revert "Fix build."
Revert "Remove unused App methods."
Revert "Stop using AppToken movement and start using Task."
Revert "Replace access to mAppTokens with AppTokenIterator"
Revert "Refactor setAppOpVisibility implementation."
Revert "Add AppWindowTokens to TaskList."
Revert "Make ActivityStack.mHistory private."
Revert "Migrate AppWindowToken lists into DisplayContent."
Change-Id: I5722c9a4956dccb52864207e2967690bc58e4ebb
