| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Removing cruft from a CAF patch. This fixes the shutter sound.
Change-Id: Ibefb50e7404a8a73336ae055ca0f6e815aed909b
|
|
|
|
|
|
|
|
| |
- Prioritize stopRecording call to avoid recording stop beep from being
recorded onto file.
Change-Id: Ia8c15b18699406ee2d32635fc83adecd290d0be1
CRs-Fixed: 234429
|
|
|
|
|
|
|
|
| |
Enable the MSG_VIDEO_FRAME message in startRecordingMode().
This will ensure that the mHardware->startRecording() call is
issued from CameraService.
Change-Id: I966c7d8955995417fa6fe0317615da4646b78878
|
|
|
|
|
|
|
|
| |
Disable VIDEO_FRAME message before stop recording is issed, which will
avoid the race condition that happens between stop recording and
receivePreviewframe on mRecordWait lock.
Change-Id: I3da4a22a1423390f5714edb8d24aef215148bee1
|
|
|
|
|
|
|
|
| |
Also destroy previous overlay and handle NULL instance.
Define BOARD_OVERLAY_FORMAT_YCbCr_420_SP for 7X30.
Change-Id: Ib2ca5e17aecd8d19841c0357594b3c4fed0a01d6
|
|
|
|
|
|
| |
Define BOARD_CAMERA_USE_GETBUFFERINFO if required.
Change-Id: Ieac0bed92c8a1517a6a7730b9636f3591c55bbcb
|
|
|
|
|
|
|
|
| |
* Handle NULL instance of camera HAL
* Use YCbCr_420_SP overlay format
* Properly destroy overlay before starting new snapshot
Change-Id: Ie72552f508f1fdc818928bf5329640b3fb9f9673
|
|
|
|
|
|
|
|
| |
Reworked to avoid ABI breakage.
This reverts commit b5d9f64973f06b45423b2216050aa0d2d2513f96.
Change-Id: I602faec8e85d80a30dadceed8c7942dc133989b8
|
|
|
|
| |
This reverts commit 57495aafa6ab172c2d2cfe32ca8a4fa57f98cb9b.
|
|
|
|
|
|
|
|
|
| |
Add getBufferInfo() API which gets the recording
buffer information from the HAL layer. The opencore
uses this API to query the details of the recording
buffers allocated by the HAL layer.
Add getBufferInfo() to Stub Camera to avoid compilation
error for generic/emulator builds.
|
|
|
|
|
|
|
|
|
| |
Terminate the old client connection properly when an ANR occurs and
the user requests to re-launch the camera application.
CRs-fixed: 250354
Change-Id: I9989aa32ff1ecd1a3a49a3155a27d02a18a5a87d
|
|\
| |
| |
| | |
git://android.git.kernel.org/platform/frameworks/base into froyo
|
| |
| |
| |
| | |
Change-Id: I33b0f68f2da34ca4728211d83159cf32a127f6dd
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was:
1. In handleShutter(), thread A in CameraService calls
registerBuffers(IMemoryHeap) and it's received by thread B
in system_server. [transaction 1]
2. While thread A is waiting for the reply, thread B calls
back to thread A to get the id of the heap
(IMemoryHeap.getHeapID). [transaction 2]
3. Thread A replies transaction 2 and is preemptied in kernel.
Thread B gets the reply and finishes registerBuffers and send
reply for transaction 1.
4. When thread A runs again, it gets the reply for transaction 1
and returns to handleShutter().
5. At this point the transaction buffer for transaction 2 (which
holds a reference to IMemoryHeap) is not freed because the
BC_FREE_BUFFER command is kept in thread A's local command
queue and not sent to the kernel.
6. Normally when thread A makes next transaction, the
BC_FREE_BUFFER command will be sent together (piggyback) with
the commands for that transaction. But in this case thread A
is a callback thread from camera driver, so it does not make
any binder calls afterwards, and the IMemoryHeap is never freed
(until the next time handleShutter is called).
Change-Id: I435a258187509bdbbaf353339eb9ea577610cbd2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was:
1. In handleShutter(), thread A in CameraService calls
registerBuffers(IMemoryHeap) and it's received by thread B
in system_server. [transaction 1]
2. While thread A is waiting for the reply, thread B calls
back to thread A to get the id of the heap
(IMemoryHeap.getHeapID). [transaction 2]
3. Thread A replies transaction 2 and is preemptied in kernel.
Thread B gets the reply and finishes registerBuffers and send
reply for transaction 1.
4. When thread A runs again, it gets the reply for transaction 1
and returns to handleShutter().
5. At this point the transaction buffer for transaction 2 (which
holds a reference to IMemoryHeap) is not freed because the
BC_FREE_BUFFER command is kept in thread A's local command
queue and not sent to the kernel.
6. Normally when thread A makes next transaction, the
BC_FREE_BUFFER command will be sent together (piggyback) with
the commands for that transaction. But in this case thread A
is a callback thread from camera driver, so it does not make
any binder calls afterwards, and the IMemoryHeap is never freed
(until the next time handleShutter is called).
Change-Id: I435a258187509bdbbaf353339eb9ea577610cbd2
|
| |
| |
| |
| |
| |
| | |
camera changes and audio changes for compilation
Change-Id: Ic1ed590eed00e2c7093e6b2f9dc5188b6aee4926
|
| |
| |
| |
| |
| | |
Change preview overlay dimensions to 768X432 if the recording resolution
is 1280X720,
|
|/
|
|
|
|
| |
older devices.
Change-Id: I6a1dbe519df3b07292d738ffa9f6be95b794875e
|
| |
|
|
|
|
| |
original version, but it should be ok as the original Y,Cb,Cr are all incorrect.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
headers when specifying the uri of media data to be played.
related-to-bug: 2393577
Original change by Andrei Popescu <andreip@google.com>
|
| |
|
|
|
|
| |
portrait mode.
|
| |
|
| |
|
|
|
|
|
| |
executable but not specified. It is included via dependency of another shared
object.
|
|\
| |
| |
| |
| | |
* changes:
Add CameraServiceTest.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Merge commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3' into eclair-mr2
* commit 'bb3bb57a6330f71323fcd7e93e88dbdab55daec3':
Fix issue 2192673: Music Pausing Even when notifications are set to silent.
|
| |/
| |
| |
| | |
Do not play ringtones, notifications or camera sounds if ringer mode is 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.
|
|
|
|
| |
b2060030
|
|
|
|
| |
Change-Id: I13bda991b32aee47e82b5cf9d43b3021c416a9a2
|
|
|
|
| |
bug 2116866
|
|
|
|
| |
Originally from: https://partner.source.android.com/g/#change,829
|
|
|
|
| |
architecture as camera services
|
|
|
|
| |
since we won't be going through the binder in single process mode.
|
|
|
|
|
|
|
| |
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()
|
|
|
|
| |
Enable hardware overlay support for camera and video playback use cases
|
|\ |
|
| |
| |
| |
| | |
Bug 1927069.
|
|\ \
| |/
| |
| |
| |
| |
| | |
Merge commit 'b8a10fe45657f2dcc50cae8a06805f8438a6937e'
* commit 'b8a10fe45657f2dcc50cae8a06805f8438a6937e':
Allow setPreviewDisplay after startPreview.
|