Merge commit '1ac56b602aa6a1ac54c608e5a8b76f44638db23b' into eclair-mr2
* commit '1ac56b602aa6a1ac54c608e5a8b76f44638db23b':
Fix issue 2292062: Audio freezes for three seconds when choosing ringtones with a headset connected and music playing.
Merge commit 'f27eb3264d4b5d3fd154834a709a9a53cc878b58' into eclair-mr2
* commit 'f27eb3264d4b5d3fd154834a709a9a53cc878b58':
DATE_TAKEN should be in millisecond instead of second.
If a touch event was targeted at a ScrollView child, the content would jump after
the user moved her finger by the required threshold. This is inconsistent with
ListView's behavior.
Fixes#2296622.
Merge commit 'a80a75f34a98fe1e41afab93c97aca505939903a' into eclair-mr2
* commit 'a80a75f34a98fe1e41afab93c97aca505939903a':
Register Handsfree profile before headset profile. DO NOT MERGE.
Merge commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6' into eclair-mr2
* commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6':
Fix more of bug 2290852: Don't wake screen when bluetooth headset is connected or disconnected.
There was bug in the logic that calculated the relative timeout, the start time was
reset each time an event was received, which caused the timeout to never occur if
an application was constantly redrawing.
Now we always check for a timeout when we come back from the waitEvent() and
process the "anti-freeze" if needed, regardless of whether an event was received.
Merge commit '926492d9cc51f28f0471352cde77d2d91ae9becd' into eclair-mr2
* commit '926492d9cc51f28f0471352cde77d2d91ae9becd':
Import revised translations. DO NOT MERGE
Merge commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3' into eclair-mr2
* commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3':
Fix issue 2192673: Music Pausing Even when notifications are set to silent.
Fixes#2296601.
WebView and its related APIs are keeping static objects that hold references to
Context instance. This could cause applications to leak their first Activity
and all the associated resources.
* changes:
A small sample tool to encode pcm audio data to amr, decode it again and play it. Some changes to OMXCodec to properly configure the AMR decoder(s).
The problem comes from a deadlock with AudioPolicyService mutex: When the second ringtone starts,
this mutex is locked by AudioPolicyService::startOutput() which in turn calls setParameters() to change the output device.
Audioflinger::ThreadBase::setParameters() signals the parameter change to the AudioFlinger mixer thread and waits for a condition
indicating that the parameter change has been processed.
At the same time, the mixer thread detects that the audio track corresponding to the first ring tone has been killed and calls its destructor.
This calls AudioPolicyService::releaseOutput() which tries to lock the AudioPolicyService mutex.
If this happens before the mixer thread can process the setParameters() command we are deadlocked.
The deadlock ends because setParameters() uses a timeout when waiting for the condition.
This regression was introduced by change 33736 fixing issue 2265163.
The fix consists in calling AudioPolicyService::releaseOutput() from Track::destroy() instead of from Track destructor: as detroy() is never called from the mixer thread loop (as opposed to the destructor) the deadlock described above cannot occur.
There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
Bug: 2293792
Dr No: Eastham
There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
