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 #6813661 offscreen views don't get invalidated properly (may remain invisible when returning onscreen)
Change-Id: Ic4b439540084a7163be9afc585bea6560d073280
The new display list properties introduces in JB were causing numerous
and expensive memory allocations while scrolling lists. During a scroll
ListView sometimes attempts to apply an offset to views before they are
drawn for the first time. This had the side effect of generating a new
IllegalStateException and its entire stack trace. The exception was
caught inside the display list and never seen by users.
Generating an exception is very expensive both in terms of allocated
memory and CPU time spent crawling the stack.
List scrolls/flings are a common case of this issue but it also happens
during various types of animations. A simple alpha animation, for instance,
can cause the problem to occur.
Another side effect of this issue is more frequent and longer GC pauses.
Change-Id: Ic1b37cc84f7c8f290209cfb990d030e96d6e0dc7
This change shows how much time is spent updating and executing
framework display lists within a frame.
This change also fixes a crash that happnes if you attempt to
perform a dumpsys gfxinfo while the app is drawing (we are telling
developers to use this new tool.)
Change-Id: Ia4047a78a42b545ab77176ef4f371c300686548c
A recent change to LayoutTransition noop'd animations in non-visible
parents, to avoid artifacts like scaling/moving from (0,0,0,0). But there
was logic in ViewGroup that didn't account for transitions that didn't actually
run an animation, causing a disconnect between the state of a parent (getting ready
to remove an item later) and the state of the transition (not running, therefore
not needing the child to be removed later).
The fix was to detect when the transition did not start and avoid adding the
view to the list of children to be removed later.
Issue #6602502 Playing video through crackle application only audio is heard no video is displayed
Change-Id: Id5260580ab0d6dd165c62006c7bd579fd821a5f5
Extend RemoteControlClient class to enable an applicaton to
specify more information about how it's playing media, now covering
usecases where media playback happens "remotely". This playback
information can be used to set the volume and maximum volume
used remotely.
Declare a new intent and associated extras in Intent,
ACTION_VOLUME_UPDATE, so an application can be notified that
the volume it handles should be updated. It can then use
the new RemoteControlClient.setPlaybackInformation() method
to notify AudioService what the volume is.
Extend AudioService to maintain playback information associated
with the RemoteControlClient information in the stack of
media button event receivers (mRCStack). The information
about the active remote is cached so the stack doesn't have
to be iterated over in order to retrieve remote playback info.
Events to "adjust" the remote volume based on hardware key
presses cause the client application to be notified of
volume updates, and the volume panel to display the volume
set by the app.
Revise which stream type is controlled when none is specified
according to latest guidelines for remote playback.
Update VolumePanel class to support a new pseudo stream type,
AudioService.STREAM_REMOTE_MUSIC, that corresponds to the
remote playback volume, and uses the new "media route" icon.
Enable it to receive asynchronously new volume values for
the remote that will be displayed if the UI is still up,
and ignored otherwise.
Now supports hiding/showing sliders dynamically so remote
volume only appears when AudioService has a remote control
client handling remote volume.
Define new java symbols for the two media route icons.
Modify lockscreen behavior: don't automatically control music
volume when music is active, consider also remote playback.
Still to do:
- playback information set by RemoteControlClient should post
a message for AudioService to update playback information
instead of updating it synchronously
Change-Id: I557aa687239f9acfe33a609f05876c67fa7eb967
Currently just grabbing the window state but we could grab
other things as part of the last ANR report.
Bug: 6680398
Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
1. The function for finding where the accessibility focus in a virtual
node tree presented by an AccessibilityNodeProvider is not needed
API since the framework already keeps track of the accessibility
focused virtual node in order to draw the focus rectangle. This API
adds unnecessary complexity to developers of AccessibilityNodeProviders.
bug:6675330
Change-Id: I84774686b06a995073a39e45b8ef22f2cd04b773
Improve the API around ActionProvider visibility overriding. Allow the
application to notify whatever is hosting the ActionProvider that
visibility has changed in a way that is friendly to alternate support
library-style reimplementations of MenuItem.
Allow MediaRouter.Callback implementations to add or remove themselves
or other Callbacks during dispatch of callback events.
Make MediaRouteActionProvider track the visibility of corresponding
menu items more accurately.
Change-Id: Ic7ddb6a87c3637904750d2661e4a9fa323b09ea0
* Add ActionProvider#overridesItemVisibility and isVisible.
These methods allow an ActionProvider to override the
visibility of a MenuItem that it is bound to. If a MenuItem
has been explicitly hidden by the application, it will not
be visible.
* Change MediaRouteActionProvider to not require a MediaRouter
callback, to avoid extra lifecycle management headaches.
Change-Id: I606fa98b3a6a3e60a953dd024274f9bf9c67acdd
1. Currently we are providing accessibility focus search algorithm in the
framework and we are also setting accessibility focus from hover. It
appears that implementing a focus search strategy that works for all
accessibility services is non trivial task if feasible. Based on
feedback from the developers of two such services at Google - TalkBack
and BarilleBack - the built in focus search does not quite match what
they need and they would like to implement a custom strategy.
Hence, having APIs for accessibility focus search in the framework does
not make. Therefore, we are hiding this APIs and later will take out the focus
search logic and allow the accessibility service to implement search.
Also putting accessibility focus from hover is tightly integrated with
the focus search since the set of views that get accessibility focus
from hover should be the same as the set of views returned by the
focus search routine. Therefore, we are letting the accessibility service
decide where to put accessibility focus when it gets an accessibility
hover event.
bug:6675330
Change-Id: Ie152230990a6602f3fd1d82de2177d0b1444d654
This reverts commit 858491ba13
It turns out that Surface Flinger is supposed to generate fake vsyncs while the screen is off, but sometimes it wasn't working due to a bug. That bug has now been fixed by the following change: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
When the screen is off, we might not receive real vsync pulses from
the hardware which would cause posted Choreographer callbacks to not run.
This is bad because messages in the Looper might be blocked behind a barrier
that is scheduled to be removed by one of those Choreographer callback
(see ViewRootImpl.doTraversals). Until the barrier is removed, those messages
will not run. To prevent starvation of the Looper, we synthesize fake vsync
pulses at a reduced rate whenever the display hardware stops generating them.
This change should fix a variety of rare non-deterministic bugs where
the system might appear to be unresponsive while the screen is off,
and spurious ANRs reported shortly after the screen is turned back on.
Bug: 6574842
Bug: 6636995
Bug: 6643559
Change-Id: I263f2fdf979afd79e5ac47a0cc5d34a93b860c21
Bug #6642475
When expanding the status bar, create one layer per notification instead of
a single giant layer for the pile of notifications. This prevents layer
creation failure when the total height of the notifications is larger
than the maximum allowed texture size in OpenGL ES 2.0.
This change only enables layers on notifications that will be visible
once the notification area is fully expanded.
Change-Id: I3c791a66cf5ac0973f3a65cfcd84b95209d580f3
Moved some duplicate code from SearchPanelView and LockScreen
over to SearchManager to avoid creating yet another copy of it
in PhoneWindowManager.
Bug: 6594275
Change-Id: Ib4ebcd6817639d17548952ab2ce7cb876c05777c
...MediaPlayer.setScreenOnWhilePlaying seem broken
We need to correctly clear the keep screen on flag when the view
hierarchy request is gone... and to do that, we need to keep the
actual state of the flag requested by the app. Also when the app
changes its state, we need to compute the proper value based on
both the app request and any requests in the view hierarchy.
Bug: 6634325
Change-Id: I060e9a34a10faffbaa77c06098cf21298bb4969f
When an ANR occurs, log the associated reason.
When an event takes too long to process (currently more than 2 seconds)
log basic information about the event including how long it actually
took.
Dump the contents of the inbound, outbound and wait queues as part
of dumpsys input.
Bug: 6574842
Change-Id: I9ab754c320f609cb86fe266c469a61e7032dfed6
Detect wonky vsync timestamps (should they occur) and
warn loudly about them.
Warn when too many frames are skipped. The threshold is pretty
conservative right now (only warn if at least 30 frames are skipped)
but it can be adjusted using system property. Even skipping just a
couple of frames is enough to generate noticeable jank.
The threshold is currently intended to help track down bigger problems
such when an app does too much work on the UI thread.
Bug: 6574842
Change-Id: I4aac7e5e17d1fb51adb0510e318a72a28b3775ed
Bug #6596807
A crash would occur in the following situation:
- WebView registers a functor with the hardware renderer
- The hardware renderer gets disabled
- WebView attemps to unregister its functor
Unregistering the functor fails because the hardware renderer is now disabled.
When the renderer becomes enabled again, the functor is invoked, which leads
to a native crash.
This change simply allows functors to always be unregistered, even when the
renderer is disabled. A disabled renderer only means that it will not be used
for rendering; as such, unregistering a functor is a valid operation and
should be allowed.
Change-Id: I0ff897a0cca7e048c609033215cd0f7f5c940bcc
1. The character and word iterators were use the application
context to keep track of locale changes. However, for widgets
the context from which the app context is obtained is custom
created therefore the app context is null and the iterators
code does not expect that. Now we are caching the locale
and update it when the configuration changes.
bug:6642281
Change-Id: I3fd201ab9e4efd79e3bdc8afd8ee644e4354a7fb
The edge slop code could violate invariants of ScaleGestureDetector,
such as the assumption that if an ACTION_POINTER_DOWN is observed
or if getPointerCount() >= 2, then there must be at least two
active pointers to choose from. But due to the edge slop handling,
it was possible for findNewActiveIndex to return -1 in this
case, resulting in a crash.
Bug: 6613154
Change-Id: I4e08e38a49ab27dac1be9484e19de086bc43624a
1. AccessibilityInput filter was not checking whether the touch
explorer instance is not null before passing it an accessibility
event. If the accessibility event is dispatched before the input
filter is installed but after it is created we runt into this
case.
2. Added a missing null check in accessibility node info.
bug:6635089
Change-Id: Ia389dc1f427427eb73794f6331ccb870e0b44c55
1. If the last touch explored location is within the active window we
used to click on exact location if it is within the accessibility
focus otherwise in the accessibility focus center. If the last touch
explored location is not within the active window we used to just
click there. This breaks in the case were one has touch explored
at a given place in the current window and now a dialog opens *not*
covering the touch explored location. If one uses swipes to move
accessibility focus i.e. to traverse the dialog without touching
it one cannot activate anything because the touch explorer is using
the last touch explored location that is outside of the active
window e.g the dialog.
The solution is to clear the last touch explored location when a
window opens or accessibility focus moves. If the last touch
explored location is null we are clicking in the accessibility
focus location.
bug:6620911
2. There is a bug in the window manager that does not notify a
window that its location has changed (bug:6623031). This breaks
accessibility interaction with dialogs that have input because
when the IME is up the dialog is moved but not notified. Now
the accessibility layer gets incorrect location for the
accessibility focus and the window bounds.
The soluion is when the accessibility manager service calls
into the remove thress to obtain some accessibility node infos
it passes the window left and top which it gets from the
window manager. These values are used to update the attach info
window left and top so all accessibility node infos emitted
from that window had correct bounds in screen coordinates.
bug:6620796
Change-Id: I18914f2095c55cfc826acf5277bd94b776bda0c8
This reverts commit b999cc118f.
There was an assumption in this earlier change that observer dispatching could not be
recursive - we could only ever have one iteration on the observer listener list. This
assumption broke down in a specific app, and maybe in more, so reverting the change for now.
We should probably find a way to accomplish the same allocation-minimizing goal without
causing exceptions when violating our assumptions.
Issue #6620795 [Application compatibility] Lufthansa app crashes
Change-Id: I1c1f9ad329c14398feb0e74ce77e1a07111f7d1f
A previous fix made it necessary for a frame to render something to GL
in order to cause a call to eglSwapBuffers(). Besides the calls being
tracked as part of issuing a DisplayList, there is also a potential call
to clear the canvas (via glClear()) on non-opaque surfaces. This call is also
good to track, since a surface that gets cleared without any other drawing operations
is worth flipping to the screen (to erase old contents on that surface).
This fix tracks the status of the pre-draw operations to find out whether
glClear() was called and then sets the drawing status appropriately.
Issue #6606422 QuickContact dismissal is janky again (Tracking)
Change-Id: I5fcaccfdc9293dd46b83f2fc279730a5d2740ebf
1. We have decided to let the accessibility services take care
for syncing accessibility and input focus. Some apps may
move input focus when a given view takes input focus which
dragging accessibility focus can lead to a loop in the
focus traversal. This change removes some leftover sync
code.
bug:6616861
Change-Id: I57cb44e315a386d13596794d3767b559e9ee3d99
