Add new binder calls to pass video native handle so the video native
handle can be passed between 32-bit and 64-bit processes.
Remove problematic code that used IMemory to pass video native
handle because the sizes of VideoNativeMetadata are different in
32-bit and 64-bit processes.
Bug: 28403412
Change-Id: I3341b1812ecc41d61846bb72ca926ecb1674c9ec
Fix error handling regressions from the Binder interface refactor
- Error codes from openLegacy became incorrect
- Client initialize() call error codes were not discriminated between
Bug: 27657269
Change-Id: I2379d45d5fe5c2ad43c78bcfd18ea4c833adc987
Modify StageFright's CameraSource to forward calling PID as
client PID when connecting to CameraService so CameraService
can check if the client PID has permission to use camera.
Change CameraService to check calling UID is trusted before
using the passed in client PID and client UID to verify permission.
Bug: 24511454
Change-Id: I4906ab73510e2c75714690bed675e3c13aca3ccf
Use a BufferQueue between Camera and StageFright to pass video
buffers for Camera HALv3 devices.
CameraSource in StageFright will try to use "buffer queue" mode
if it is supported by the camera device. In "buffer queue" mode,
CameraSource creates a buffer queue and a listener thread to recieve
video buffers from camera device. CameraSource then wraps the
ANWBuffer in MediaBuffer. If the camera device doesn't support
"buffer queue" mode, it falls back to "metadata in video buffer"
mode or "real YUV data" mode.
"Metadata in video buffer" mode is removed from Camera2Client and
only "buffer queue" mode is supported.
Bug: 24511454
Change-Id: Ice833b57bcd8d91852d6415402013f56f3e3970a
INVALID_OPERATION surfaces as an non-specific device-level error to
applications in the onError callback. This is not a condition apps
targeting camera2 in L will generally have to deal with.
Instead, return -EACCESS which maps to throwing
CameraAccessException.CAMERA_DISABLED, same as disabling camera access
with DevicePolicyManager.
The old camera API converts any error code to -EACCESS at the JNI layer,
so this doesn't change anything for the older API.
Also update the various native ICameraService binder connect calls to
check for the transact error code, and return it if it is not OK.
Without this, PERMISSION_DENIED transact errors from the camera
service cannot be distinguished from CAMERA_DISABLED errors in
some codepaths.
Bug: 21604925
Change-Id: Ifccc8989b8c20653429e2d3e51dba7abb2be9c35
A higher hal version device like HAL3.2 can be opened as HAL1.0 device
if HAL supports it. This only applies to camera API1.
Change-Id: I4ae9f59f4317158cc1bd7ed7726e4032cdd1fa07
- Use the controlledByApp flag to make sure application-bound
preview buffer queue is asynchronous as before
- Remove setPreviewDisplay in service, since it is no longer in
the binder interface
- Rename setPreviewTexture to setPreviewTarget, to make it clear it's
the only game in town now. Rename only on the binder level and service
for now.
Bug: 10312644
Change-Id: Icd33a462022f9729a63dc65c69b755cb7969857e
- Add call to set a preview callback surface
- Implement support for HAL2/3 devices
- Still need HAL1 implementation
Change-Id: I0dc0bd72e43d871aa487858d1665c1efca633ffe
Camera:
- Signal to AppOpsService when camera usage starts and stops
- Listen to permissions revocations and act on them
- Currently just kill camera connection when permissions lost
Stagefright:
- Pass on client name, UID to camera as needed
Bug: 8181262
Change-Id: I9e33c9d05e9daa77dbb2d795045d08eb887ec8f0
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: I64520a55f8c09fe6215382ea361c539a9940cba5
Applications are not resumed under the lock screen now.
This API is not needed anymore.
bug:5584464
Change-Id: I115daf6b647348617ec0fc05b626878c945b9b29
The purpose is to let face unlock always get the camera
successfully. What happened was the camera applications may
have opened the camera in onResume under the lock screen.
This API lets face unlock take the camera from the camera
application. A new permission will be added, so other
applicatoins won't be able to take the camera from the face
unlock.
bug:5584464
Change-Id: Ib3d9dcbc2161815b68db42327dc01148453704c6
The purpose of ICameraRecordingProxy and ICameraRecordingProxyListener is to
allow applications using the camera during recording.
Camera service allows only one client at a time. Since camcorder application
needs to own the camera to do things like zoom, the media recorder cannot
access the camera directly during recording. So ICameraRecordingProxy is a proxy
of ICamera, which allows the media recorder to start/stop the recording and
release recording frames. ICameraRecordingProxyListener is an interface that
allows the recorder to receive video frames during recording.
ICameraRecordingProxy
startRecording()
stopRecording()
releaseRecordingFrame()
ICameraRecordingProxyListener
dataCallbackTimestamp()
The camcorder app opens the camera and starts the preview. The app passes
ICamera and ICameraRecordingProxy to the media recorder by
MediaRecorder::setCamera(). The recorder uses ICamera to setup the camera in
MediaRecorder::start(). After setup, the recorder disconnects from camera
service. The recorder calls ICameraRecordingProxy::startRecording() and
passes a ICameraRecordingProxyListener to the app. The app connects back to
camera service and starts the recording. The app owns the camera and can do
things like zoom. The media recorder receives the video frames from the
listener and releases them by ICameraRecordingProxy::releaseRecordingFrame.
The recorder calls ICameraRecordingProxy::stopRecording() to stop the
recording.
The call sequences are as follows:
1. The app: Camera.unlock().
2. The app: MediaRecorder.setCamera().
3. Start recording
(1) The app: MediaRecorder.start().
(2) The recorder: ICamera.unlock() and ICamera.disconnect().
(3) The recorder: ICameraRecordingProxy.startRecording().
(4) The app: ICamera.reconnect().
(5) The app: ICamera.startRecording().
4. During recording
(1) The recorder: receive frames from ICameraRecordingProxyListener.dataCallbackTimestamp()
(2) The recorder: release frames by ICameraRecordingProxy.releaseRecordingFrame().
5. Stop recording
(1) The app: MediaRecorder.stop()
(2) The recorder: ICameraRecordingProxy.stopRecording().
(3) The app: ICamera.stopRecording().
bug:2644213
Change-Id: I15269397defc25cbbcae16abc071c8349c123122
Methods getNumberOfVideoBuffers() and getVideoBuffer() as well as struct
image_rect_struct are no longer used (instead, the necessary information is
passed through ANativeWindow.)
Change-Id: If4b11446fc9ccbde1f6b45bc70c0d0b8e54376eb
Signed-off-by: Iliyan Malchev <malchev@google.com>
This change enables the use of a SurfaceTexture in place of a Surface as
the destination of camera preview frames.
Change-Id: Ic70d404c8fe261e9d5da6f1de93d6babb5b191cb
When startRecording() is called before setListener(), recording frames
are sent right after startRecording(), but there is no listener to
release the recording frames. This causes the hang in media server.
bug - 3166356
Change-Id: I19366ca682ef9f6b847590c190c30a15ed32b8e4
This change makes the camera HAL interface take an ANativeWindow interface from
which all the camera preview buffers will be allocated. The framework code
running in application processes now passes a Surface object rather than an
ISurface to the camera server via Binder when setting the preview surface. The
camera server then forwards that Surface object (which implements the
ANativeWindow interface) to the camera HAL, which uses it to communicate with
SurfaceFlinger to allocate the camera preview buffers.
Change-Id: Ie438f721559cd7de5e4f848a26d96360dda07b5f
Yin-Chia Yeh
Chien-Yu Chen
Eino-Ville Talvala
Svetoslav Ganov
Marco Nelissen
Zhijun He
Ruben Brunk
Mathias Agopian
Igor Murashkin
Andy McFadden
Wu-cheng Li
Steve Block
Iliyan Malchev
James Dong
Jamie Gennis
Jean-Baptiste Queru
Chih-Chung Chang