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.
- make sure that all binder Bn classes define a ctor and dtor in their respective library.
This avoids duplication of the ctor/dtor in libraries where these objects are instantiated.
This is also cleaner, should we want these ctor/dtor to do something one day.
- same change as above for some Bp classes and various other non-binder classes
- moved the definition of CHECK_INTERFACE() in IInterface.h instead of having it everywhere.
- improved the CHECK_INTERFACE() macro so it calls a single method in Parcel, instead of inlining its code everywhere
- IBinder::getInterfaceDescriptor() now returns a "const String16&" instead of String16, which saves calls to String16 and ~String16
- implemented a cache for BpBinder::getInterfaceDescriptor(), since this does an IPC. HOWEVER, this method never seems to be called.
The cache makes BpBinder bigger, so we need to figure out if we need this method at all.
Merge commit '7283fb18022674daee4dcdc3a218190791f8cd0e'
* commit '7283fb18022674daee4dcdc3a218190791f8cd0e':
AI 149133: Enable the camera permission check.
Merge commit 'db79edc5dc39e103356cad8781148a8794520bc5'
* commit 'db79edc5dc39e103356cad8781148a8794520bc5':
Fix permission hole in camera service. Some debugging code was added
Some debugging code was added to camera service. Later it was #ifdef'd
out, but this change also removed the camera permission check. This
change puts the permission check back in.
BUG=1869264
Automated import of CL 149133
to CameraService::onTransact() method during development. Later on
the entire onTransact() method was #ifdef'd out, which inadvertently
omitted the permissions check code. This change restores the code.
This is the second half of bug 1837832. Modifies the camera client
and camera service to use the new binder interface. Removes the
old binder interface. There will be one more part to this change
to surface the undefined callbacks to the Java layer so that
partners can implement new features without having to touch the
stack.
Current implementation of Camera service plays the camera shutter sound over the ALARM stream so that it cannot be muted by silent mode in order to comply to some country specific requirement. A recent change made it possible for the user to mute the ALARM stream thus making this stream not suitable any more for the camera shutter sound.
The fix consists in creating a new stream type only accessible by native code and that cannot be muted and use it to play camera sounds.
Original author: elaurent
Merged from: //branches/cupcake/...
Automated import of CL 143177
