The problem occurs when activating or deactivating A2DP connection
while SoudPool has a channel active. This can happen quite frequently now
that the UI sound effects are enabled by default.
If PCM data is remaining in the AudioTrack buffer when it is restroyed and
re-created on the new AudioFlinger output thread, this data is flushed.
As a consequence, no underrun or request for new data callback is sent to
SoundPool and the sound channel remains active for ever as the end of the
sample is never detected.
Change-Id: I13e0c11e4ce3f83bff7f58d347ca814b6a86712b
-Increased quicksettings and clearall inherent asset padding to 32 from 16dp
-new touchstates for quicksettings and clearall
-clear all remains on the right and quicksettings remains left aligned to the right of the date
Bug: 5076789
Change-Id: I45d7da2d79b94822c04aa162ebef99ac79ce0368
If the expiry time cannot be found in Contact header or Expires
header, use the default value of 3600 seconds, which is specified
in RFC 3261.
Change-Id: I2607a398b96743614b01713cfd9b28f40386fac1
- this really just calls cryptfs cryptocomplete
- needed so that UI logic can present a factory reset option if
encryption screwed up
Bug: 3384231
Change-Id: I553de87f0d03a65851030c9c5266e85866d30fa6
- Update the WifiP2pGroup class
- Add reason code response for all failures
- Fix display of self in peer list
- Retain p2p group when explicitly created by API and fix join behavior
Bug: 5247957
Change-Id: Ibd9b163887db1c8a9dd8213253fda20c436a49e3
The toIndex of accessibility events fired from a AbsListView
is exclusive but should be inclusive i.e. it was reported one
more that it has to be.
bug:5256286
Change-Id: I496959fdfb6760b0c74899730c4cc558e89234a6
1. Tuned the max angle between two moving fingers in touch
exploration mode for a gesture to be considered a drag.
The previous value was too aggressive and it was fairly
easy for the user to get out of dragging state if she
ingreases the distance between her fingers.
bug:5223787
2. Before clicking the explorer was sending hover enter and
exit resulting in firing the corresponding accessibility
events which leads to announcement of the content under
the tap that triggered the click. However, the click is
actually performed on the last touch explored location
(if in the distance slop of course) instead of the actual
tapping pointer location. Before fixing that the user was
confused since he was hearing announcement of one content
but actually was clicking on something else.
bug:5225721
Change-Id: I79fec704878f98c95f181bf8a9647e0bb1bd10ef
