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
We had a gap in sync coverage between doing a check and waiting and a
matching gap between setting a condition and notifying. It was possible
to get context switched just so and have the notify hit before the waiter
had started waiting.
bug:6492166
Change-Id: Idc876cf85b35902a79fae932547957ed5ef00e4f
This reverts commit b999cc118fe430699e9a67d5dab355125b873abb.
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
* commit '7c5c86d7624646554156339b5f48e110fc53d8ed':
Always queue A2DP connection state message with wakelock held
Adding more logging for bug: 6499508
Fix bug 6558006: SystemUI native heap is huge. Fix memory leak
Fix build.
Revert "Make the protectionLevel of framework permissions consistent and related to sensitive user data. Dangerous permissions are applied only where sensitive user data may be exposed."
Survey says: NIET!
Fix 6580421: make sure MultiWaveView.reset() makes handle visible
Fix issue #6579824: Email crash observed after updating...
Fix 6398209: SearchPanel gesture improvements
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
Guard against cases where ListView might receive touch events while
detached.
Update ListMenuPresenter to dispatch a data set change when the
backing menu is changed.
Bug 6543282
Change-Id: If2fb9b6aa3cf4a1b7070a7cd0de0edf0fc2f4cca
Unlike previous versions of Android, we now show the current
wifi SSID in the carrier label if connected to wifi.
Bug: 6612419
Bug: 6620626
Change-Id: Ifb5ba8efe6dd387e960efc6a9b1da69a08e97d96
Indicate that if the device does not support Bluetooth or WiFI,
calling the API is a no-op.
Bug: 6620788
Change-Id: Ib261e0e7855d0914e97803b3b808015b72f3a186
Messages for changes to A2DP connection state are intended to be
queued in AudioService after acquiring a wake lock, which is
released after the message has been handled.
This was correctly done for connection messages when the system
is up and running, but wasn't when the BluetoothProfile service
listener gets an onServiceConnected() event, which is the case
the the device boots.
This change correctly uses the queueMsgUnderWakeLock() method
whenever a MSG_SET_A2DP_CONNECTION_STATE is to be sent.
Bug 6616292
Change-Id: Ie337a4641a89c522e2d233bccaac4e08ce324117
