Merge commit '6d5c42ef00a46e0b560b3d15ba73d89d94072af8' into eclair-plus-aosp
* commit '6d5c42ef00a46e0b560b3d15ba73d89d94072af8':
Import revised translations. DO NOT MERGE
Merge commit '1ac56b602aa6a1ac54c608e5a8b76f44638db23b' into eclair-plus-aosp
* commit '1ac56b602aa6a1ac54c608e5a8b76f44638db23b':
Fix issue 2292062: Audio freezes for three seconds when choosing ringtones with a headset connected and music playing.
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 'f27eb3264d4b5d3fd154834a709a9a53cc878b58' into eclair-plus-aosp
* commit 'f27eb3264d4b5d3fd154834a709a9a53cc878b58':
DATE_TAKEN should be in millisecond instead of second.
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.
Merge commit 'a80a75f34a98fe1e41afab93c97aca505939903a' into eclair-plus-aosp
* commit 'a80a75f34a98fe1e41afab93c97aca505939903a':
Register Handsfree profile before headset profile. DO NOT MERGE.
Merge commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6' into eclair-plus-aosp
* commit 'abf7fed21bfa7eb899be558477d928a7c9f3e1f6':
Fix more of bug 2290852: Don't wake screen when bluetooth headset is connected or disconnected.
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
Merge commit '926492d9cc51f28f0471352cde77d2d91ae9becd' into eclair-plus-aosp
* commit '926492d9cc51f28f0471352cde77d2d91ae9becd':
Import revised translations. DO NOT MERGE
This fixes another case where the screen would turn on when the keyguard is open but hidden by another activity.
Change-Id: I2b7c8a329036401709e96ded4f4c138041192a71
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3' into eclair-plus-aosp
* commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3':
Fix issue 2192673: Music Pausing Even when notifications are set to silent.
Merge commit 'f817218e09a556f20efc81309ba2cdb3475a370b' into eclair-plus-aosp
* commit 'f817218e09a556f20efc81309ba2cdb3475a370b':
dumpstate: Pick up the last kernel log from /proc
