...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
Add action provider, button, and styles. Extend ActionProvider to
allow for getting references to MenuItem instances.
Implement toggle mode for the MediaRouteButton/ActionProvider. Dialog
selection yet to come.
Change-Id: Ibe3188570f503bbf8dd00cf154663435656a7171
1. Now after setting the content description on a view we mark is as
important for accessibility of the current important for accessibility
mode of that view is auto.
2. Minor tweak to a touch explorer coefficient to make performing double
tapping easier.
bug:6615353
Change-Id: I3b477f533a3ebde85d425caf32ace5e851240f88
