Merge commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3' into eclair-mr2
* commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3':
Fix issue 2192673: Music Pausing Even when notifications are set to silent.
We will need those values for new camera framework. And change the canned jpeg
image to match the new width and height setting.
Change-Id: I49f8fb63d2b859b9e9f1c5d27657a10203315bb6
Some camera HALs spin up a preview thread and need to wait for
the thread to exit. This can create a potential deadlock. In
stopPreview, we take the main lock. If a preview callback occurs
while the lock is held, the preview thread will block. If the
camera HAL is waiting for the preview thread to exit, this will
cause a deadlock.
This patch breaks out the preview buffer heap into a separate
mutex. This mutex is never held when the main lock is held, thus
preventing the deadlock from occuring.
copyFrameAndPostCopiedFrame was not holding a lock while it accessed
the preview heap. If the client process is torn down while the heap
is accessed, the memcpy could access memory that was deallocated.
This patch creates a local sp reference to the preview heap while
holding the lock, then releases the lock. This should prevent the
heap from being pulled out from underneath us.
We weren't checking to see if there was a valid camera client when
calling the notify callback function. Now we grab a strong pointer
before the callback to guarantee that the client is not destroyed
before we complete the callback. This change also fixes other
places in the code where we weren't holding a local strong pointer.
Occasionally we see references to the overlay hanging around long
enough to cause problems in applications when they tried to destroy
the overlay and re-create it. This patch causes the camera HAL to
retry the overlay creation call if it fails every 20ms up to 50
times before it gives up.
Initial commit for review.
Integrated comments after patch set 1 review.
Fixed lockup in AudioFlinger::ThreadBase::exit()
Fixed lockup when playing tone with AudioPlocyService startTone()
Merge commit 'c6a482e778e7b5fc5790edf22e554c93f53b1112'
* commit 'c6a482e778e7b5fc5790edf22e554c93f53b1112':
Only remove client after the hardware is teared down, so a new client
The reason we need this count is a new CameraService::connect() request may
come in while the previous Client's destructor has not been run or is still
running. If the last strong reference of the previous Client is gone but
destructor has not been run, we should not allow the new Client to be created
because we need to wait for the previous Client to tear down the hardware
first.
