--- /dev/null
+cc_library_static {
+ name: "android.hardware.camera.common-helper.samsung",
+ vendor_available: true,
+ defaults: [
+ "hidl_defaults",
+ "samsung_camera3_defaults",
+ ],
+ srcs: [
+ "CameraModule.cpp",
+ "CameraMetadata.cpp",
+ "CameraParameters.cpp",
+ "VendorTagDescriptor.cpp",
+ "HandleImporter.cpp",
+ "Exif.cpp",
+ "SimpleThread.cpp",
+ ],
+ cflags: [
+ "-Werror",
+ "-Wextra",
+ "-Wall",
+ ],
+ shared_libs: [
+ "liblog",
+ "libgralloctypes",
+ "libhardware",
+ "libcamera_metadata",
+ "libexif",
+ "libui",
+ ],
+ include_dirs: ["system/media/private/camera/include"],
+ header_libs: ["libhardware_headers.camera3_samsung"],
+ export_include_dirs: ["include"],
+ export_shared_lib_headers: ["libui"],
+}
+
+// NOTE: Deprecated module kept for compatibility reasons.
+// Depend on "android.hardware.camera.common-helper.samsung" instead
+cc_library_static {
+ name: "android.hardware.camera.common@1.0-helper.samsung",
+ vendor_available: true,
+ whole_static_libs: ["android.hardware.camera.common-helper.samsung"],
+}
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/CameraMetadata.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/CameraModule.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/CameraParameters.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/Exif.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/HandleImporter.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/SimpleThread.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/VendorTagDescriptor.cpp
\ No newline at end of file
--- /dev/null
+../../../../../hardware/interfaces/camera/common/default/include
\ No newline at end of file
cc_library_shared {
name: "camera.device-impl.samsung",
- defaults: ["android.hardware.graphics.common-ndk_shared"],
+ defaults: [
+ "android.hardware.graphics.common-ndk_shared",
+ "samsung_camera3_defaults",
+ ],
vendor: true,
srcs: [
"CameraDevice.cpp",
"libutils",
],
static_libs: [
- "android.hardware.camera.common-helper",
+ "android.hardware.camera.common-helper.samsung",
"libaidlcommonsupport",
],
+ header_libs: [
+ "libhardware_headers.camera3_samsung",
+ ],
export_include_dirs: ["."],
}
--- /dev/null
+soong_config_module_type {
+ name: "samsung_camera3",
+ module_type: "cc_defaults",
+ config_namespace: "samsungCameraVars",
+ bool_variables: [
+ "needs_sec_get_cam_pos_v1",
+ "needs_sec_get_cam_pos_v2",
+ "needs_sec_reserved_field",
+ "usage_64bit",
+ ],
+ properties: ["cflags"],
+}
+
+samsung_camera3 {
+ name: "samsung_camera3_defaults",
+ soong_config_variables: {
+ needs_sec_get_cam_pos_v1: {
+ cflags: ["-DCAMERA_NEEDS_SEC_GET_CAM_POS_V1"],
+ },
+ needs_sec_get_cam_pos_v2: {
+ cflags: ["-DCAMERA_NEEDS_SEC_GET_CAM_POS_V2"],
+ },
+ needs_sec_reserved_field: {
+ cflags: ["-DCAMERA_NEEDS_SEC_RESERVED_FIELD"],
+ },
+ usage_64bit: {
+ cflags: ["-DCAMERA_64BIT_USAGE"],
+ },
+ },
+}
+
+cc_library_headers {
+ name: "libhardware_headers.camera3_samsung",
+ export_include_dirs: ["include"],
+ vendor_available: true,
+}
--- /dev/null
+../../../../../../../hardware/libhardware/include/hardware/camera.h
\ No newline at end of file
--- /dev/null
+/*
+ * Copyright (C) 2013-2018 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef ANDROID_INCLUDE_CAMERA3_H
+#define ANDROID_INCLUDE_CAMERA3_H
+
+#include <system/camera_metadata.h>
+#include "camera_common.h"
+
+/**
+ * Camera device HAL 3.6[ CAMERA_DEVICE_API_VERSION_3_6 ]
+ *
+ * This is the current recommended version of the camera device HAL.
+ *
+ * Supports the android.hardware.Camera API, and as of v3.2, the
+ * android.hardware.camera2 API as LIMITED or above hardware level.
+ *
+ * Camera devices that support this version of the HAL must return
+ * CAMERA_DEVICE_API_VERSION_3_6 in camera_device_t.common.version and in
+ * camera_info_t.device_version (from camera_module_t.get_camera_info).
+ *
+ * CAMERA_DEVICE_API_VERSION_3_3 and above:
+ * Camera modules that may contain version 3.3 or above devices must
+ * implement at least version 2.2 of the camera module interface (as defined
+ * by camera_module_t.common.module_api_version).
+ *
+ * CAMERA_DEVICE_API_VERSION_3_2:
+ * Camera modules that may contain version 3.2 devices must implement at
+ * least version 2.2 of the camera module interface (as defined by
+ * camera_module_t.common.module_api_version).
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ * Camera modules that may contain version 3.1 (or 3.0) devices must
+ * implement at least version 2.0 of the camera module interface
+ * (as defined by camera_module_t.common.module_api_version).
+ *
+ * See camera_common.h for more versioning details.
+ *
+ * Documentation index:
+ * S1. Version history
+ * S2. Startup and operation sequencing
+ * S3. Operational modes
+ * S4. 3A modes and state machines
+ * S5. Cropping
+ * S6. Error management
+ * S7. Key Performance Indicator (KPI) glossary
+ * S8. Sample Use Cases
+ * S9. Notes on Controls and Metadata
+ * S10. Reprocessing flow and controls
+ */
+
+/**
+ * S1. Version history:
+ *
+ * 1.0: Initial Android camera HAL (Android 4.0) [camera.h]:
+ *
+ * - Converted from C++ CameraHardwareInterface abstraction layer.
+ *
+ * - Supports android.hardware.Camera API.
+ *
+ * 2.0: Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:
+ *
+ * - Sufficient for implementing existing android.hardware.Camera API.
+ *
+ * - Allows for ZSL queue in camera service layer
+ *
+ * - Not tested for any new features such manual capture control, Bayer RAW
+ * capture, reprocessing of RAW data.
+ *
+ * 3.0: First revision of expanded-capability HAL:
+ *
+ * - Major version change since the ABI is completely different. No change to
+ * the required hardware capabilities or operational model from 2.0.
+ *
+ * - Reworked input request and stream queue interfaces: Framework calls into
+ * HAL with next request and stream buffers already dequeued. Sync framework
+ * support is included, necessary for efficient implementations.
+ *
+ * - Moved triggers into requests, most notifications into results.
+ *
+ * - Consolidated all callbacks into framework into one structure, and all
+ * setup methods into a single initialize() call.
+ *
+ * - Made stream configuration into a single call to simplify stream
+ * management. Bidirectional streams replace STREAM_FROM_STREAM construct.
+ *
+ * - Limited mode semantics for older/limited hardware devices.
+ *
+ * 3.1: Minor revision of expanded-capability HAL:
+ *
+ * - configure_streams passes consumer usage flags to the HAL.
+ *
+ * - flush call to drop all in-flight requests/buffers as fast as possible.
+ *
+ * 3.2: Minor revision of expanded-capability HAL:
+ *
+ * - Deprecates get_metadata_vendor_tag_ops. Please use get_vendor_tag_ops
+ * in camera_common.h instead.
+ *
+ * - register_stream_buffers deprecated. All gralloc buffers provided
+ * by framework to HAL in process_capture_request may be new at any time.
+ *
+ * - add partial result support. process_capture_result may be called
+ * multiple times with a subset of the available result before the full
+ * result is available.
+ *
+ * - add manual template to camera3_request_template. The applications may
+ * use this template to control the capture settings directly.
+ *
+ * - Rework the bidirectional and input stream specifications.
+ *
+ * - change the input buffer return path. The buffer is returned in
+ * process_capture_result instead of process_capture_request.
+ *
+ * 3.3: Minor revision of expanded-capability HAL:
+ *
+ * - OPAQUE and YUV reprocessing API updates.
+ *
+ * - Basic support for depth output buffers.
+ *
+ * - Addition of data_space field to camera3_stream_t.
+ *
+ * - Addition of rotation field to camera3_stream_t.
+ *
+ * - Addition of camera3 stream configuration operation mode to camera3_stream_configuration_t
+ *
+ * 3.4: Minor additions to supported metadata and changes to data_space support
+ *
+ * - Add ANDROID_SENSOR_OPAQUE_RAW_SIZE static metadata as mandatory if
+ * RAW_OPAQUE format is supported.
+ *
+ * - Add ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata as
+ * mandatory if any RAW format is supported
+ *
+ * - Switch camera3_stream_t data_space field to a more flexible definition,
+ * using the version 0 definition of dataspace encoding.
+ *
+ * - General metadata additions which are available to use for HALv3.2 or
+ * newer:
+ * - ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
+ * - ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
+ * - ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
+ * - ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
+ * - ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
+ * - ANDROID_SENSOR_OPAQUE_RAW_SIZE
+ * - ANDROID_SENSOR_OPTICAL_BLACK_REGIONS
+ *
+ * 3.5: Minor revisions to support session parameters and logical multi camera:
+ *
+ * - Add ANDROID_REQUEST_AVAILABLE_SESSION_KEYS static metadata, which is
+ * optional for implementations that want to support session parameters. If support is
+ * needed, then Hal should populate the list with all available capture request keys
+ * that can cause severe processing delays when modified by client. Typical examples
+ * include parameters that require time-consuming HW re-configuration or internal camera
+ * pipeline update.
+ *
+ * - Add a session parameter field to camera3_stream_configuration which can be populated
+ * by clients with initial values for the keys found in ANDROID_REQUEST_AVAILABLE_SESSION_KEYS.
+ *
+ * - Metadata additions for logical multi camera capability:
+ * - ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
+ * - ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
+ * - ANDROID_LOGICAL_MULTI_CAMERA_SYNC_TYPE
+ *
+ * - Add physical camera id field in camera3_stream, so that for a logical
+ * multi camera, the application has the option to specify which physical camera
+ * a particular stream is configured on.
+ *
+ * - Add physical camera id and settings field in camera3_capture_request, so that
+ * for a logical multi camera, the application has the option to specify individual
+ * settings for a particular physical device.
+ *
+ * 3.6: Minor revisions to support HAL buffer management APIs:
+ *
+ * - Add ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION static metadata, which allows HAL to
+ * opt in to the new buffer management APIs described below.
+ *
+ * - Add request_stream_buffers() and return_stream_buffers() to camera3_callback_ops_t for HAL to
+ * request and return output buffers from camera service.
+ *
+ * - Add signal_stream_flush() to camera3_device_ops_t for camera service to notify HAL an
+ * upcoming configure_streams() call requires HAL to return buffers of certain streams.
+ *
+ * - Add CAMERA3_JPEG_APP_SEGMENTS_BLOB_ID to support BLOB with only JPEG apps
+ * segments and thumbnail (without main image bitstream). Camera framework
+ * uses such stream togerther with a HAL YUV_420_888/IMPLEMENTATION_DEFINED
+ * stream to encode HEIC (ISO/IEC 23008-12) image.
+ *
+ * - Add is_reconfiguration_required() to camera3_device_ops_t to enable HAL to skip or
+ * trigger stream reconfiguration depending on new session parameter values.
+ *
+ */
+
+/**
+ * S2. Startup and general expected operation sequence:
+ *
+ * 1. Framework calls camera_module_t->common.open(), which returns a
+ * hardware_device_t structure.
+ *
+ * 2. Framework inspects the hardware_device_t->version field, and instantiates
+ * the appropriate handler for that version of the camera hardware device. In
+ * case the version is CAMERA_DEVICE_API_VERSION_3_0, the device is cast to
+ * a camera3_device_t.
+ *
+ * 3. Framework calls camera3_device_t->ops->initialize() with the framework
+ * callback function pointers. This will only be called this one time after
+ * open(), before any other functions in the ops structure are called.
+ *
+ * 4. The framework calls camera3_device_t->ops->configure_streams() with a list
+ * of input/output streams to the HAL device.
+ *
+ * 5. <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * The framework allocates gralloc buffers and calls
+ * camera3_device_t->ops->register_stream_buffers() for at least one of the
+ * output streams listed in configure_streams. The same stream is registered
+ * only once.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * camera3_device_t->ops->register_stream_buffers() is not called and must
+ * be NULL.
+ *
+ * 6. The framework requests default settings for some number of use cases with
+ * calls to camera3_device_t->ops->construct_default_request_settings(). This
+ * may occur any time after step 3.
+ *
+ * 7. The framework constructs and sends the first capture request to the HAL,
+ * with settings based on one of the sets of default settings, and with at
+ * least one output stream, which has been registered earlier by the
+ * framework. This is sent to the HAL with
+ * camera3_device_t->ops->process_capture_request(). The HAL must block the
+ * return of this call until it is ready for the next request to be sent.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * The buffer_handle_t provided in the camera3_stream_buffer_t array
+ * in the camera3_capture_request_t may be new and never-before-seen
+ * by the HAL on any given new request.
+ *
+ * 8. The framework continues to submit requests, and call
+ * construct_default_request_settings to get default settings buffers for
+ * other use cases.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * The framework may call register_stream_buffers() at this time for
+ * not-yet-registered streams.
+ *
+ * 9. When the capture of a request begins (sensor starts exposing for the
+ * capture) or processing a reprocess request begins, the HAL
+ * calls camera3_callback_ops_t->notify() with the SHUTTER event, including
+ * the frame number and the timestamp for start of exposure. For a reprocess
+ * request, the timestamp must be the start of exposure of the input image
+ * which can be looked up with android.sensor.timestamp from
+ * camera3_capture_request_t.settings when process_capture_request() is
+ * called.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * This notify call must be made before the first call to
+ * process_capture_result() for that frame number.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * The camera3_callback_ops_t->notify() call with the SHUTTER event should
+ * be made as early as possible since the framework will be unable to
+ * deliver gralloc buffers to the application layer (for that frame) until
+ * it has a valid timestamp for the start of exposure (or the input image's
+ * start of exposure for a reprocess request).
+ *
+ * Both partial metadata results and the gralloc buffers may be sent to the
+ * framework at any time before or after the SHUTTER event.
+ *
+ * 10. After some pipeline delay, the HAL begins to return completed captures to
+ * the framework with camera3_callback_ops_t->process_capture_result(). These
+ * are returned in the same order as the requests were submitted. Multiple
+ * requests can be in flight at once, depending on the pipeline depth of the
+ * camera HAL device.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Once a buffer is returned by process_capture_result as part of the
+ * camera3_stream_buffer_t array, and the fence specified by release_fence
+ * has been signaled (this is a no-op for -1 fences), the ownership of that
+ * buffer is considered to be transferred back to the framework. After that,
+ * the HAL must no longer retain that particular buffer, and the
+ * framework may clean up the memory for it immediately.
+ *
+ * process_capture_result may be called multiple times for a single frame,
+ * each time with a new disjoint piece of metadata and/or set of gralloc
+ * buffers. The framework will accumulate these partial metadata results
+ * into one result.
+ *
+ * In particular, it is legal for a process_capture_result to be called
+ * simultaneously for both a frame N and a frame N+1 as long as the
+ * above rule holds for gralloc buffers (both input and output).
+ *
+ * 11. After some time, the framework may stop submitting new requests, wait for
+ * the existing captures to complete (all buffers filled, all results
+ * returned), and then call configure_streams() again. This resets the camera
+ * hardware and pipeline for a new set of input/output streams. Some streams
+ * may be reused from the previous configuration; if these streams' buffers
+ * had already been registered with the HAL, they will not be registered
+ * again. The framework then continues from step 7, if at least one
+ * registered output stream remains (otherwise, step 5 is required first).
+ *
+ * 12. Alternatively, the framework may call camera3_device_t->common->close()
+ * to end the camera session. This may be called at any time when no other
+ * calls from the framework are active, although the call may block until all
+ * in-flight captures have completed (all results returned, all buffers
+ * filled). After the close call returns, no more calls to the
+ * camera3_callback_ops_t functions are allowed from the HAL. Once the
+ * close() call is underway, the framework may not call any other HAL device
+ * functions.
+ *
+ * 13. In case of an error or other asynchronous event, the HAL must call
+ * camera3_callback_ops_t->notify() with the appropriate error/event
+ * message. After returning from a fatal device-wide error notification, the
+ * HAL should act as if close() had been called on it. However, the HAL must
+ * either cancel or complete all outstanding captures before calling
+ * notify(), so that once notify() is called with a fatal error, the
+ * framework will not receive further callbacks from the device. Methods
+ * besides close() should return -ENODEV or NULL after the notify() method
+ * returns from a fatal error message.
+ */
+
+/**
+ * S3. Operational modes:
+ *
+ * The camera 3 HAL device can implement one of two possible operational modes;
+ * limited and full. Full support is expected from new higher-end
+ * devices. Limited mode has hardware requirements roughly in line with those
+ * for a camera HAL device v1 implementation, and is expected from older or
+ * inexpensive devices. Full is a strict superset of limited, and they share the
+ * same essential operational flow, as documented above.
+ *
+ * The HAL must indicate its level of support with the
+ * android.info.supportedHardwareLevel static metadata entry, with 0 indicating
+ * limited mode, and 1 indicating full mode support.
+ *
+ * Roughly speaking, limited-mode devices do not allow for application control
+ * of capture settings (3A control only), high-rate capture of high-resolution
+ * images, raw sensor readout, or support for YUV output streams above maximum
+ * recording resolution (JPEG only for large images).
+ *
+ * ** Details of limited mode behavior:
+ *
+ * - Limited-mode devices do not need to implement accurate synchronization
+ * between capture request settings and the actual image data
+ * captured. Instead, changes to settings may take effect some time in the
+ * future, and possibly not for the same output frame for each settings
+ * entry. Rapid changes in settings may result in some settings never being
+ * used for a capture. However, captures that include high-resolution output
+ * buffers ( > 1080p ) have to use the settings as specified (but see below
+ * for processing rate).
+ *
+ * - Limited-mode devices do not need to support most of the
+ * settings/result/static info metadata. Specifically, only the following settings
+ * are expected to be consumed or produced by a limited-mode HAL device:
+ *
+ * android.control.aeAntibandingMode (controls and dynamic)
+ * android.control.aeExposureCompensation (controls and dynamic)
+ * android.control.aeLock (controls and dynamic)
+ * android.control.aeMode (controls and dynamic)
+ * android.control.aeRegions (controls and dynamic)
+ * android.control.aeTargetFpsRange (controls and dynamic)
+ * android.control.aePrecaptureTrigger (controls and dynamic)
+ * android.control.afMode (controls and dynamic)
+ * android.control.afRegions (controls and dynamic)
+ * android.control.awbLock (controls and dynamic)
+ * android.control.awbMode (controls and dynamic)
+ * android.control.awbRegions (controls and dynamic)
+ * android.control.captureIntent (controls and dynamic)
+ * android.control.effectMode (controls and dynamic)
+ * android.control.mode (controls and dynamic)
+ * android.control.sceneMode (controls and dynamic)
+ * android.control.videoStabilizationMode (controls and dynamic)
+ * android.control.aeAvailableAntibandingModes (static)
+ * android.control.aeAvailableModes (static)
+ * android.control.aeAvailableTargetFpsRanges (static)
+ * android.control.aeCompensationRange (static)
+ * android.control.aeCompensationStep (static)
+ * android.control.afAvailableModes (static)
+ * android.control.availableEffects (static)
+ * android.control.availableSceneModes (static)
+ * android.control.availableVideoStabilizationModes (static)
+ * android.control.awbAvailableModes (static)
+ * android.control.maxRegions (static)
+ * android.control.sceneModeOverrides (static)
+ * android.control.aeState (dynamic)
+ * android.control.afState (dynamic)
+ * android.control.awbState (dynamic)
+ *
+ * android.flash.mode (controls and dynamic)
+ * android.flash.info.available (static)
+ *
+ * android.info.supportedHardwareLevel (static)
+ *
+ * android.jpeg.gpsCoordinates (controls and dynamic)
+ * android.jpeg.gpsProcessingMethod (controls and dynamic)
+ * android.jpeg.gpsTimestamp (controls and dynamic)
+ * android.jpeg.orientation (controls and dynamic)
+ * android.jpeg.quality (controls and dynamic)
+ * android.jpeg.thumbnailQuality (controls and dynamic)
+ * android.jpeg.thumbnailSize (controls and dynamic)
+ * android.jpeg.availableThumbnailSizes (static)
+ * android.jpeg.maxSize (static)
+ *
+ * android.lens.info.minimumFocusDistance (static)
+ *
+ * android.request.id (controls and dynamic)
+ *
+ * android.scaler.cropRegion (controls and dynamic)
+ * android.scaler.availableStreamConfigurations (static)
+ * android.scaler.availableMinFrameDurations (static)
+ * android.scaler.availableStallDurations (static)
+ * android.scaler.availableMaxDigitalZoom (static)
+ * android.scaler.maxDigitalZoom (static)
+ * android.scaler.croppingType (static)
+ *
+ * android.sensor.orientation (static)
+ * android.sensor.timestamp (dynamic)
+ *
+ * android.statistics.faceDetectMode (controls and dynamic)
+ * android.statistics.info.availableFaceDetectModes (static)
+ * android.statistics.faceIds (dynamic)
+ * android.statistics.faceLandmarks (dynamic)
+ * android.statistics.faceRectangles (dynamic)
+ * android.statistics.faceScores (dynamic)
+ *
+ * android.sync.frameNumber (dynamic)
+ * android.sync.maxLatency (static)
+ *
+ * - Captures in limited mode that include high-resolution (> 1080p) output
+ * buffers may block in process_capture_request() until all the output buffers
+ * have been filled. A full-mode HAL device must process sequences of
+ * high-resolution requests at the rate indicated in the static metadata for
+ * that pixel format. The HAL must still call process_capture_result() to
+ * provide the output; the framework must simply be prepared for
+ * process_capture_request() to block until after process_capture_result() for
+ * that request completes for high-resolution captures for limited-mode
+ * devices.
+ *
+ * - Full-mode devices must support below additional capabilities:
+ * - 30fps at maximum resolution is preferred, more than 20fps is required.
+ * - Per frame control (android.sync.maxLatency == PER_FRAME_CONTROL).
+ * - Sensor manual control metadata. See MANUAL_SENSOR defined in
+ * android.request.availableCapabilities.
+ * - Post-processing manual control metadata. See MANUAL_POST_PROCESSING defined
+ * in android.request.availableCapabilities.
+ *
+ */
+
+/**
+ * S4. 3A modes and state machines:
+ *
+ * While the actual 3A algorithms are up to the HAL implementation, a high-level
+ * state machine description is defined by the HAL interface, to allow the HAL
+ * device and the framework to communicate about the current state of 3A, and to
+ * trigger 3A events.
+ *
+ * When the device is opened, all the individual 3A states must be
+ * STATE_INACTIVE. Stream configuration does not reset 3A. For example, locked
+ * focus must be maintained across the configure() call.
+ *
+ * Triggering a 3A action involves simply setting the relevant trigger entry in
+ * the settings for the next request to indicate start of trigger. For example,
+ * the trigger for starting an autofocus scan is setting the entry
+ * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTROL_AF_TRIGGER_START for one
+ * request, and cancelling an autofocus scan is triggered by setting
+ * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTRL_AF_TRIGGER_CANCEL. Otherwise,
+ * the entry will not exist, or be set to ANDROID_CONTROL_AF_TRIGGER_IDLE. Each
+ * request with a trigger entry set to a non-IDLE value will be treated as an
+ * independent triggering event.
+ *
+ * At the top level, 3A is controlled by the ANDROID_CONTROL_MODE setting, which
+ * selects between no 3A (ANDROID_CONTROL_MODE_OFF), normal AUTO mode
+ * (ANDROID_CONTROL_MODE_AUTO), and using the scene mode setting
+ * (ANDROID_CONTROL_USE_SCENE_MODE).
+ *
+ * - In OFF mode, each of the individual AE/AF/AWB modes are effectively OFF,
+ * and none of the capture controls may be overridden by the 3A routines.
+ *
+ * - In AUTO mode, Auto-focus, auto-exposure, and auto-whitebalance all run
+ * their own independent algorithms, and have their own mode, state, and
+ * trigger metadata entries, as listed in the next section.
+ *
+ * - In USE_SCENE_MODE, the value of the ANDROID_CONTROL_SCENE_MODE entry must
+ * be used to determine the behavior of 3A routines. In SCENE_MODEs other than
+ * FACE_PRIORITY, the HAL must override the values of
+ * ANDROId_CONTROL_AE/AWB/AF_MODE to be the mode it prefers for the selected
+ * SCENE_MODE. For example, the HAL may prefer SCENE_MODE_NIGHT to use
+ * CONTINUOUS_FOCUS AF mode. Any user selection of AE/AWB/AF_MODE when scene
+ * must be ignored for these scene modes.
+ *
+ * - For SCENE_MODE_FACE_PRIORITY, the AE/AWB/AF_MODE controls work as in
+ * ANDROID_CONTROL_MODE_AUTO, but the 3A routines must bias toward metering
+ * and focusing on any detected faces in the scene.
+ *
+ * S4.1. Auto-focus settings and result entries:
+ *
+ * Main metadata entries:
+ *
+ * ANDROID_CONTROL_AF_MODE: Control for selecting the current autofocus
+ * mode. Set by the framework in the request settings.
+ *
+ * AF_MODE_OFF: AF is disabled; the framework/app directly controls lens
+ * position.
+ *
+ * AF_MODE_AUTO: Single-sweep autofocus. No lens movement unless AF is
+ * triggered.
+ *
+ * AF_MODE_MACRO: Single-sweep up-close autofocus. No lens movement unless
+ * AF is triggered.
+ *
+ * AF_MODE_CONTINUOUS_VIDEO: Smooth continuous focusing, for recording
+ * video. Triggering immediately locks focus in current
+ * position. Canceling resumes cotinuous focusing.
+ *
+ * AF_MODE_CONTINUOUS_PICTURE: Fast continuous focusing, for
+ * zero-shutter-lag still capture. Triggering locks focus once currently
+ * active sweep concludes. Canceling resumes continuous focusing.
+ *
+ * AF_MODE_EDOF: Advanced extended depth of field focusing. There is no
+ * autofocus scan, so triggering one or canceling one has no effect.
+ * Images are focused automatically by the HAL.
+ *
+ * ANDROID_CONTROL_AF_STATE: Dynamic metadata describing the current AF
+ * algorithm state, reported by the HAL in the result metadata.
+ *
+ * AF_STATE_INACTIVE: No focusing has been done, or algorithm was
+ * reset. Lens is not moving. Always the state for MODE_OFF or MODE_EDOF.
+ * When the device is opened, it must start in this state.
+ *
+ * AF_STATE_PASSIVE_SCAN: A continuous focus algorithm is currently scanning
+ * for good focus. The lens is moving.
+ *
+ * AF_STATE_PASSIVE_FOCUSED: A continuous focus algorithm believes it is
+ * well focused. The lens is not moving. The HAL may spontaneously leave
+ * this state.
+ *
+ * AF_STATE_PASSIVE_UNFOCUSED: A continuous focus algorithm believes it is
+ * not well focused. The lens is not moving. The HAL may spontaneously
+ * leave this state.
+ *
+ * AF_STATE_ACTIVE_SCAN: A scan triggered by the user is underway.
+ *
+ * AF_STATE_FOCUSED_LOCKED: The AF algorithm believes it is focused. The
+ * lens is not moving.
+ *
+ * AF_STATE_NOT_FOCUSED_LOCKED: The AF algorithm has been unable to
+ * focus. The lens is not moving.
+ *
+ * ANDROID_CONTROL_AF_TRIGGER: Control for starting an autofocus scan, the
+ * meaning of which is mode- and state- dependent. Set by the framework in
+ * the request settings.
+ *
+ * AF_TRIGGER_IDLE: No current trigger.
+ *
+ * AF_TRIGGER_START: Trigger start of AF scan. Effect is mode and state
+ * dependent.
+ *
+ * AF_TRIGGER_CANCEL: Cancel current AF scan if any, and reset algorithm to
+ * default.
+ *
+ * Additional metadata entries:
+ *
+ * ANDROID_CONTROL_AF_REGIONS: Control for selecting the regions of the FOV
+ * that should be used to determine good focus. This applies to all AF
+ * modes that scan for focus. Set by the framework in the request
+ * settings.
+ *
+ * S4.2. Auto-exposure settings and result entries:
+ *
+ * Main metadata entries:
+ *
+ * ANDROID_CONTROL_AE_MODE: Control for selecting the current auto-exposure
+ * mode. Set by the framework in the request settings.
+ *
+ * AE_MODE_OFF: Autoexposure is disabled; the user controls exposure, gain,
+ * frame duration, and flash.
+ *
+ * AE_MODE_ON: Standard autoexposure, with flash control disabled. User may
+ * set flash to fire or to torch mode.
+ *
+ * AE_MODE_ON_AUTO_FLASH: Standard autoexposure, with flash on at HAL's
+ * discretion for precapture and still capture. User control of flash
+ * disabled.
+ *
+ * AE_MODE_ON_ALWAYS_FLASH: Standard autoexposure, with flash always fired
+ * for capture, and at HAL's discretion for precapture.. User control of
+ * flash disabled.
+ *
+ * AE_MODE_ON_AUTO_FLASH_REDEYE: Standard autoexposure, with flash on at
+ * HAL's discretion for precapture and still capture. Use a flash burst
+ * at end of precapture sequence to reduce redeye in the final
+ * picture. User control of flash disabled.
+ *
+ * ANDROID_CONTROL_AE_STATE: Dynamic metadata describing the current AE
+ * algorithm state, reported by the HAL in the result metadata.
+ *
+ * AE_STATE_INACTIVE: Initial AE state after mode switch. When the device is
+ * opened, it must start in this state.
+ *
+ * AE_STATE_SEARCHING: AE is not converged to a good value, and is adjusting
+ * exposure parameters.
+ *
+ * AE_STATE_CONVERGED: AE has found good exposure values for the current
+ * scene, and the exposure parameters are not changing. HAL may
+ * spontaneously leave this state to search for better solution.
+ *
+ * AE_STATE_LOCKED: AE has been locked with the AE_LOCK control. Exposure
+ * values are not changing.
+ *
+ * AE_STATE_FLASH_REQUIRED: The HAL has converged exposure, but believes
+ * flash is required for a sufficiently bright picture. Used for
+ * determining if a zero-shutter-lag frame can be used.
+ *
+ * AE_STATE_PRECAPTURE: The HAL is in the middle of a precapture
+ * sequence. Depending on AE mode, this mode may involve firing the
+ * flash for metering, or a burst of flash pulses for redeye reduction.
+ *
+ * ANDROID_CONTROL_AE_PRECAPTURE_TRIGGER: Control for starting a metering
+ * sequence before capturing a high-quality image. Set by the framework in
+ * the request settings.
+ *
+ * PRECAPTURE_TRIGGER_IDLE: No current trigger.
+ *
+ * PRECAPTURE_TRIGGER_START: Start a precapture sequence. The HAL should
+ * use the subsequent requests to measure good exposure/white balance
+ * for an upcoming high-resolution capture.
+ *
+ * Additional metadata entries:
+ *
+ * ANDROID_CONTROL_AE_LOCK: Control for locking AE controls to their current
+ * values
+ *
+ * ANDROID_CONTROL_AE_EXPOSURE_COMPENSATION: Control for adjusting AE
+ * algorithm target brightness point.
+ *
+ * ANDROID_CONTROL_AE_TARGET_FPS_RANGE: Control for selecting the target frame
+ * rate range for the AE algorithm. The AE routine cannot change the frame
+ * rate to be outside these bounds.
+ *
+ * ANDROID_CONTROL_AE_REGIONS: Control for selecting the regions of the FOV
+ * that should be used to determine good exposure levels. This applies to
+ * all AE modes besides OFF.
+ *
+ * S4.3. Auto-whitebalance settings and result entries:
+ *
+ * Main metadata entries:
+ *
+ * ANDROID_CONTROL_AWB_MODE: Control for selecting the current white-balance
+ * mode.
+ *
+ * AWB_MODE_OFF: Auto-whitebalance is disabled. User controls color matrix.
+ *
+ * AWB_MODE_AUTO: Automatic white balance is enabled; 3A controls color
+ * transform, possibly using more complex transforms than a simple
+ * matrix.
+ *
+ * AWB_MODE_INCANDESCENT: Fixed white balance settings good for indoor
+ * incandescent (tungsten) lighting, roughly 2700K.
+ *
+ * AWB_MODE_FLUORESCENT: Fixed white balance settings good for fluorescent
+ * lighting, roughly 5000K.
+ *
+ * AWB_MODE_WARM_FLUORESCENT: Fixed white balance settings good for
+ * fluorescent lighting, roughly 3000K.
+ *
+ * AWB_MODE_DAYLIGHT: Fixed white balance settings good for daylight,
+ * roughly 5500K.
+ *
+ * AWB_MODE_CLOUDY_DAYLIGHT: Fixed white balance settings good for clouded
+ * daylight, roughly 6500K.
+ *
+ * AWB_MODE_TWILIGHT: Fixed white balance settings good for
+ * near-sunset/sunrise, roughly 15000K.
+ *
+ * AWB_MODE_SHADE: Fixed white balance settings good for areas indirectly
+ * lit by the sun, roughly 7500K.
+ *
+ * ANDROID_CONTROL_AWB_STATE: Dynamic metadata describing the current AWB
+ * algorithm state, reported by the HAL in the result metadata.
+ *
+ * AWB_STATE_INACTIVE: Initial AWB state after mode switch. When the device
+ * is opened, it must start in this state.
+ *
+ * AWB_STATE_SEARCHING: AWB is not converged to a good value, and is
+ * changing color adjustment parameters.
+ *
+ * AWB_STATE_CONVERGED: AWB has found good color adjustment values for the
+ * current scene, and the parameters are not changing. HAL may
+ * spontaneously leave this state to search for better solution.
+ *
+ * AWB_STATE_LOCKED: AWB has been locked with the AWB_LOCK control. Color
+ * adjustment values are not changing.
+ *
+ * Additional metadata entries:
+ *
+ * ANDROID_CONTROL_AWB_LOCK: Control for locking AWB color adjustments to
+ * their current values.
+ *
+ * ANDROID_CONTROL_AWB_REGIONS: Control for selecting the regions of the FOV
+ * that should be used to determine good color balance. This applies only
+ * to auto-WB mode.
+ *
+ * S4.4. General state machine transition notes
+ *
+ * Switching between AF, AE, or AWB modes always resets the algorithm's state
+ * to INACTIVE. Similarly, switching between CONTROL_MODE or
+ * CONTROL_SCENE_MODE if CONTROL_MODE == USE_SCENE_MODE resets all the
+ * algorithm states to INACTIVE.
+ *
+ * The tables below are per-mode.
+ *
+ * S4.5. AF state machines
+ *
+ * when enabling AF or changing AF mode
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| Any | AF mode change| INACTIVE | |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * mode = AF_MODE_OFF or AF_MODE_EDOF
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | | INACTIVE | Never changes |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * mode = AF_MODE_AUTO or AF_MODE_MACRO
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | AF_TRIGGER | ACTIVE_SCAN | Start AF sweep |
+ *| | | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| ACTIVE_SCAN | AF sweep done | FOCUSED_LOCKED | If AF successful |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| ACTIVE_SCAN | AF sweep done | NOT_FOCUSED_LOCKED | If AF successful |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| ACTIVE_SCAN | AF_CANCEL | INACTIVE | Cancel/reset AF |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Cancel/reset AF |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FOCUSED_LOCKED | AF_TRIGGER | ACTIVE_SCAN | Start new sweep |
+ *| | | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Cancel/reset AF |
+ *+--------------------+---------------+--------------------+------------------+
+ *| NOT_FOCUSED_LOCKED | AF_TRIGGER | ACTIVE_SCAN | Start new sweep |
+ *| | | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| All states | mode change | INACTIVE | |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * mode = AF_MODE_CONTINUOUS_VIDEO
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | HAL initiates | PASSIVE_SCAN | Start AF scan |
+ *| | new scan | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | AF_TRIGGER | NOT_FOCUSED_LOCKED | AF state query |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | HAL completes | PASSIVE_FOCUSED | End AF scan |
+ *| | current scan | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | HAL fails | PASSIVE_UNFOCUSED | End AF scan |
+ *| | current scan | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
+ *| | | | if focus is good |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
+ *| | | | if focus is bad |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | AF_CANCEL | INACTIVE | Reset lens |
+ *| | | | position |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_FOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
+ *| | new scan | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_UNFOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
+ *| | new scan | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_FOCUSED | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_UNFOCUSED | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FOCUSED_LOCKED | AF_TRIGGER | FOCUSED_LOCKED | No effect |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
+ *+--------------------+---------------+--------------------+------------------+
+ *| NOT_FOCUSED_LOCKED | AF_TRIGGER | NOT_FOCUSED_LOCKED | No effect |
+ *+--------------------+---------------+--------------------+------------------+
+ *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * mode = AF_MODE_CONTINUOUS_PICTURE
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | HAL initiates | PASSIVE_SCAN | Start AF scan |
+ *| | new scan | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | AF_TRIGGER | NOT_FOCUSED_LOCKED | AF state query |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | HAL completes | PASSIVE_FOCUSED | End AF scan |
+ *| | current scan | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | HAL fails | PASSIVE_UNFOCUSED | End AF scan |
+ *| | current scan | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | AF_TRIGGER | FOCUSED_LOCKED | Eventual trans. |
+ *| | | | once focus good |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | AF_TRIGGER | NOT_FOCUSED_LOCKED | Eventual trans. |
+ *| | | | if cannot focus |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_SCAN | AF_CANCEL | INACTIVE | Reset lens |
+ *| | | | position |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_FOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
+ *| | new scan | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_UNFOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
+ *| | new scan | | Lens now moving |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_FOCUSED | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PASSIVE_UNFOCUSED | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
+ *| | | | Lens now locked |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FOCUSED_LOCKED | AF_TRIGGER | FOCUSED_LOCKED | No effect |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
+ *+--------------------+---------------+--------------------+------------------+
+ *| NOT_FOCUSED_LOCKED | AF_TRIGGER | NOT_FOCUSED_LOCKED | No effect |
+ *+--------------------+---------------+--------------------+------------------+
+ *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * S4.6. AE and AWB state machines
+ *
+ * The AE and AWB state machines are mostly identical. AE has additional
+ * FLASH_REQUIRED and PRECAPTURE states. So rows below that refer to those two
+ * states should be ignored for the AWB state machine.
+ *
+ * when enabling AE/AWB or changing AE/AWB mode
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| Any | mode change | INACTIVE | |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * mode = AE_MODE_OFF / AWB mode not AUTO
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | | INACTIVE | AE/AWB disabled |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ * mode = AE_MODE_ON_* / AWB_MODE_AUTO
+ *| state | trans. cause | new state | notes |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | HAL initiates | SEARCHING | |
+ *| | AE/AWB scan | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| INACTIVE | AE/AWB_LOCK | LOCKED | values locked |
+ *| | on | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| SEARCHING | HAL finishes | CONVERGED | good values, not |
+ *| | AE/AWB scan | | changing |
+ *+--------------------+---------------+--------------------+------------------+
+ *| SEARCHING | HAL finishes | FLASH_REQUIRED | converged but too|
+ *| | AE scan | | dark w/o flash |
+ *+--------------------+---------------+--------------------+------------------+
+ *| SEARCHING | AE/AWB_LOCK | LOCKED | values locked |
+ *| | on | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| CONVERGED | HAL initiates | SEARCHING | values locked |
+ *| | AE/AWB scan | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| CONVERGED | AE/AWB_LOCK | LOCKED | values locked |
+ *| | on | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FLASH_REQUIRED | HAL initiates | SEARCHING | values locked |
+ *| | AE/AWB scan | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| FLASH_REQUIRED | AE/AWB_LOCK | LOCKED | values locked |
+ *| | on | | |
+ *+--------------------+---------------+--------------------+------------------+
+ *| LOCKED | AE/AWB_LOCK | SEARCHING | values not good |
+ *| | off | | after unlock |
+ *+--------------------+---------------+--------------------+------------------+
+ *| LOCKED | AE/AWB_LOCK | CONVERGED | values good |
+ *| | off | | after unlock |
+ *+--------------------+---------------+--------------------+------------------+
+ *| LOCKED | AE_LOCK | FLASH_REQUIRED | exposure good, |
+ *| | off | | but too dark |
+ *+--------------------+---------------+--------------------+------------------+
+ *| All AE states | PRECAPTURE_ | PRECAPTURE | Start precapture |
+ *| | START | | sequence |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PRECAPTURE | Sequence done.| CONVERGED | Ready for high- |
+ *| | AE_LOCK off | | quality capture |
+ *+--------------------+---------------+--------------------+------------------+
+ *| PRECAPTURE | Sequence done.| LOCKED | Ready for high- |
+ *| | AE_LOCK on | | quality capture |
+ *+--------------------+---------------+--------------------+------------------+
+ *
+ */
+
+/**
+ * S5. Cropping:
+ *
+ * Cropping of the full pixel array (for digital zoom and other use cases where
+ * a smaller FOV is desirable) is communicated through the
+ * ANDROID_SCALER_CROP_REGION setting. This is a per-request setting, and can
+ * change on a per-request basis, which is critical for implementing smooth
+ * digital zoom.
+ *
+ * The region is defined as a rectangle (x, y, width, height), with (x, y)
+ * describing the top-left corner of the rectangle. The rectangle is defined on
+ * the coordinate system of the sensor active pixel array, with (0,0) being the
+ * top-left pixel of the active pixel array. Therefore, the width and height
+ * cannot be larger than the dimensions reported in the
+ * ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY static info field. The minimum allowed
+ * width and height are reported by the HAL through the
+ * ANDROID_SCALER_MAX_DIGITAL_ZOOM static info field, which describes the
+ * maximum supported zoom factor. Therefore, the minimum crop region width and
+ * height are:
+ *
+ * {width, height} =
+ * { floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[0] /
+ * ANDROID_SCALER_MAX_DIGITAL_ZOOM),
+ * floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[1] /
+ * ANDROID_SCALER_MAX_DIGITAL_ZOOM) }
+ *
+ * If the crop region needs to fulfill specific requirements (for example, it
+ * needs to start on even coordinates, and its width/height needs to be even),
+ * the HAL must do the necessary rounding and write out the final crop region
+ * used in the output result metadata. Similarly, if the HAL implements video
+ * stabilization, it must adjust the result crop region to describe the region
+ * actually included in the output after video stabilization is applied. In
+ * general, a camera-using application must be able to determine the field of
+ * view it is receiving based on the crop region, the dimensions of the image
+ * sensor, and the lens focal length.
+ *
+ * It is assumed that the cropping is applied after raw to other color space
+ * conversion. Raw streams (RAW16 and RAW_OPAQUE) don't have this conversion stage,
+ * and are not croppable. Therefore, the crop region must be ignored by the HAL
+ * for raw streams.
+ *
+ * Since the crop region applies to all non-raw streams, which may have different aspect
+ * ratios than the crop region, the exact sensor region used for each stream may
+ * be smaller than the crop region. Specifically, each stream should maintain
+ * square pixels and its aspect ratio by minimally further cropping the defined
+ * crop region. If the stream's aspect ratio is wider than the crop region, the
+ * stream should be further cropped vertically, and if the stream's aspect ratio
+ * is narrower than the crop region, the stream should be further cropped
+ * horizontally.
+ *
+ * In all cases, the stream crop must be centered within the full crop region,
+ * and each stream is only either cropped horizontally or vertical relative to
+ * the full crop region, never both.
+ *
+ * For example, if two streams are defined, a 640x480 stream (4:3 aspect), and a
+ * 1280x720 stream (16:9 aspect), below demonstrates the expected output regions
+ * for each stream for a few sample crop regions, on a hypothetical 3 MP (2000 x
+ * 1500 pixel array) sensor.
+ *
+ * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
+ *
+ * 640x480 stream crop: (500, 375, 1000, 750) (equal to crop region)
+ * 1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
+ *
+ * 0 1000 2000
+ * +---------+---------+---------+----------+
+ * | Active pixel array |
+ * | |
+ * | |
+ * + +-------------------+ + 375
+ * | | | |
+ * | O===================O |
+ * | I 1280x720 stream I |
+ * + I I + 750
+ * | I I |
+ * | O===================O |
+ * | | | |
+ * + +-------------------+ + 1125
+ * | Crop region, 640x480 stream |
+ * | |
+ * | |
+ * +---------+---------+---------+----------+ 1500
+ *
+ * Crop region: (500, 375, 1333, 750) (16:9 aspect ratio)
+ *
+ * 640x480 stream crop: (666, 375, 1000, 750) (marked with =)
+ * 1280x720 stream crop: (500, 375, 1333, 750) (equal to crop region)
+ *
+ * 0 1000 2000
+ * +---------+---------+---------+----------+
+ * | Active pixel array |
+ * | |
+ * | |
+ * + +---O==================O---+ + 375
+ * | | I 640x480 stream I | |
+ * | | I I | |
+ * | | I I | |
+ * + | I I | + 750
+ * | | I I | |
+ * | | I I | |
+ * | | I I | |
+ * + +---O==================O---+ + 1125
+ * | Crop region, 1280x720 stream |
+ * | |
+ * | |
+ * +---------+---------+---------+----------+ 1500
+ *
+ * Crop region: (500, 375, 750, 750) (1:1 aspect ratio)
+ *
+ * 640x480 stream crop: (500, 469, 750, 562) (marked with =)
+ * 1280x720 stream crop: (500, 543, 750, 414) (marged with #)
+ *
+ * 0 1000 2000
+ * +---------+---------+---------+----------+
+ * | Active pixel array |
+ * | |
+ * | |
+ * + +--------------+ + 375
+ * | O==============O |
+ * | ################ |
+ * | # # |
+ * + # # + 750
+ * | # # |
+ * | ################ 1280x720 |
+ * | O==============O 640x480 |
+ * + +--------------+ + 1125
+ * | Crop region |
+ * | |
+ * | |
+ * +---------+---------+---------+----------+ 1500
+ *
+ * And a final example, a 1024x1024 square aspect ratio stream instead of the
+ * 480p stream:
+ *
+ * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
+ *
+ * 1024x1024 stream crop: (625, 375, 750, 750) (marked with #)
+ * 1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
+ *
+ * 0 1000 2000
+ * +---------+---------+---------+----------+
+ * | Active pixel array |
+ * | |
+ * | 1024x1024 stream |
+ * + +--###############--+ + 375
+ * | | # # | |
+ * | O===================O |
+ * | I 1280x720 stream I |
+ * + I I + 750
+ * | I I |
+ * | O===================O |
+ * | | # # | |
+ * + +--###############--+ + 1125
+ * | Crop region |
+ * | |
+ * | |
+ * +---------+---------+---------+----------+ 1500
+ *
+ */
+
+/**
+ * S6. Error management:
+ *
+ * Camera HAL device ops functions that have a return value will all return
+ * -ENODEV / NULL in case of a serious error. This means the device cannot
+ * continue operation, and must be closed by the framework. Once this error is
+ * returned by some method, or if notify() is called with ERROR_DEVICE, only
+ * the close() method can be called successfully. All other methods will return
+ * -ENODEV / NULL.
+ *
+ * If a device op is called in the wrong sequence, for example if the framework
+ * calls configure_streams() is called before initialize(), the device must
+ * return -ENOSYS from the call, and do nothing.
+ *
+ * Transient errors in image capture must be reported through notify() as follows:
+ *
+ * - The failure of an entire capture to occur must be reported by the HAL by
+ * calling notify() with ERROR_REQUEST. Individual errors for the result
+ * metadata or the output buffers must not be reported in this case.
+ *
+ * - If the metadata for a capture cannot be produced, but some image buffers
+ * were filled, the HAL must call notify() with ERROR_RESULT.
+ *
+ * - If an output image buffer could not be filled, but either the metadata was
+ * produced or some other buffers were filled, the HAL must call notify() with
+ * ERROR_BUFFER for each failed buffer.
+ *
+ * In each of these transient failure cases, the HAL must still call
+ * process_capture_result, with valid output and input (if an input buffer was
+ * submitted) buffer_handle_t. If the result metadata could not be produced, it
+ * should be NULL. If some buffers could not be filled, they must be returned with
+ * process_capture_result in the error state, their release fences must be set to
+ * the acquire fences passed by the framework, or -1 if they have been waited on by
+ * the HAL already.
+ *
+ * Invalid input arguments result in -EINVAL from the appropriate methods. In
+ * that case, the framework must act as if that call had never been made.
+ *
+ */
+
+/**
+ * S7. Key Performance Indicator (KPI) glossary:
+ *
+ * This includes some critical definitions that are used by KPI metrics.
+ *
+ * Pipeline Latency:
+ * For a given capture request, the duration from the framework calling
+ * process_capture_request to the HAL sending capture result and all buffers
+ * back by process_capture_result call. To make the Pipeline Latency measure
+ * independent of frame rate, it is measured by frame count.
+ *
+ * For example, when frame rate is 30 (fps), the frame duration (time interval
+ * between adjacent frame capture time) is 33 (ms).
+ * If it takes 5 frames for framework to get the result and buffers back for
+ * a given request, then the Pipeline Latency is 5 (frames), instead of
+ * 5 x 33 = 165 (ms).
+ *
+ * The Pipeline Latency is determined by android.request.pipelineDepth and
+ * android.request.pipelineMaxDepth, see their definitions for more details.
+ *
+ */
+
+/**
+ * S8. Sample Use Cases:
+ *
+ * This includes some typical use case examples the camera HAL may support.
+ *
+ * S8.1 Zero Shutter Lag (ZSL) with CAMERA3_STREAM_BIDIRECTIONAL stream.
+ *
+ * For this use case, the bidirectional stream will be used by the framework as follows:
+ *
+ * 1. The framework includes a buffer from this stream as output buffer in a
+ * request as normal.
+ *
+ * 2. Once the HAL device returns a filled output buffer to the framework,
+ * the framework may do one of two things with the filled buffer:
+ *
+ * 2. a. The framework uses the filled data, and returns the now-used buffer
+ * to the stream queue for reuse. This behavior exactly matches the
+ * OUTPUT type of stream.
+ *
+ * 2. b. The framework wants to reprocess the filled data, and uses the
+ * buffer as an input buffer for a request. Once the HAL device has
+ * used the reprocessing buffer, it then returns it to the
+ * framework. The framework then returns the now-used buffer to the
+ * stream queue for reuse.
+ *
+ * 3. The HAL device will be given the buffer again as an output buffer for
+ * a request at some future point.
+ *
+ * For ZSL use case, the pixel format for bidirectional stream will be
+ * HAL_PIXEL_FORMAT_RAW_OPAQUE or HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED if it
+ * is listed in android.scaler.availableInputOutputFormatsMap. When
+ * HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, the gralloc
+ * usage flags for the consumer endpoint will be set to GRALLOC_USAGE_HW_CAMERA_ZSL.
+ * A configuration stream list that has BIDIRECTIONAL stream used as input, will
+ * usually also have a distinct OUTPUT stream to get the reprocessing data. For example,
+ * for the ZSL use case, the stream list might be configured with the following:
+ *
+ * - A HAL_PIXEL_FORMAT_RAW_OPAQUE bidirectional stream is used
+ * as input.
+ * - And a HAL_PIXEL_FORMAT_BLOB (JPEG) output stream.
+ *
+ * S8.2 ZSL (OPAQUE) reprocessing with CAMERA3_STREAM_INPUT stream.
+ *
+ * CAMERA_DEVICE_API_VERSION_3_3:
+ * When OPAQUE_REPROCESSING capability is supported by the camera device, the INPUT stream
+ * can be used for application/framework implemented use case like Zero Shutter Lag (ZSL).
+ * This kind of stream will be used by the framework as follows:
+ *
+ * 1. Application/framework configures an opaque (RAW or YUV based) format output stream that is
+ * used to produce the ZSL output buffers. The stream pixel format will be
+ * HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED.
+ *
+ * 2. Application/framework configures an opaque format input stream that is used to
+ * send the reprocessing ZSL buffers to the HAL. The stream pixel format will
+ * also be HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED.
+ *
+ * 3. Application/framework configures a YUV/JPEG output stream that is used to receive the
+ * reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
+ *
+ * 4. Application/framework picks a ZSL buffer from the ZSL output stream when a ZSL capture is
+ * issued by the application, and sends the data back as an input buffer in a
+ * reprocessing request, then sends to the HAL for reprocessing.
+ *
+ * 5. The HAL sends back the output YUV/JPEG result to framework.
+ *
+ * The HAL can select the actual opaque buffer format and configure the ISP pipeline
+ * appropriately based on the HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format and
+ * the gralloc usage flag GRALLOC_USAGE_HW_CAMERA_ZSL.
+
+ * S8.3 YUV reprocessing with CAMERA3_STREAM_INPUT stream.
+ *
+ * When YUV reprocessing is supported by the HAL, the INPUT stream
+ * can be used for the YUV reprocessing use cases like lucky-shot and image fusion.
+ * This kind of stream will be used by the framework as follows:
+ *
+ * 1. Application/framework configures an YCbCr_420 format output stream that is
+ * used to produce the output buffers.
+ *
+ * 2. Application/framework configures an YCbCr_420 format input stream that is used to
+ * send the reprocessing YUV buffers to the HAL.
+ *
+ * 3. Application/framework configures a YUV/JPEG output stream that is used to receive the
+ * reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
+ *
+ * 4. Application/framework processes the output buffers (could be as simple as picking
+ * an output buffer directly) from the output stream when a capture is issued, and sends
+ * the data back as an input buffer in a reprocessing request, then sends to the HAL
+ * for reprocessing.
+ *
+ * 5. The HAL sends back the output YUV/JPEG result to framework.
+ *
+ */
+
+/**
+ * S9. Notes on Controls and Metadata
+ *
+ * This section contains notes about the interpretation and usage of various metadata tags.
+ *
+ * S9.1 HIGH_QUALITY and FAST modes.
+ *
+ * Many camera post-processing blocks may be listed as having HIGH_QUALITY,
+ * FAST, and OFF operating modes. These blocks will typically also have an
+ * 'available modes' tag representing which of these operating modes are
+ * available on a given device. The general policy regarding implementing
+ * these modes is as follows:
+ *
+ * 1. Operating mode controls of hardware blocks that cannot be disabled
+ * must not list OFF in their corresponding 'available modes' tags.
+ *
+ * 2. OFF will always be included in their corresponding 'available modes'
+ * tag if it is possible to disable that hardware block.
+ *
+ * 3. FAST must always be included in the 'available modes' tags for all
+ * post-processing blocks supported on the device. If a post-processing
+ * block also has a slower and higher quality operating mode that does
+ * not meet the framerate requirements for FAST mode, HIGH_QUALITY should
+ * be included in the 'available modes' tag to represent this operating
+ * mode.
+ */
+
+/**
+ * S10. Reprocessing flow and controls
+ *
+ * This section describes the OPAQUE and YUV reprocessing flow and controls. OPAQUE reprocessing
+ * uses an opaque format that is not directly application-visible, and the application can
+ * only select some of the output buffers and send back to HAL for reprocessing, while YUV
+ * reprocessing gives the application opportunity to process the buffers before reprocessing.
+ *
+ * S8 gives the stream configurations for the typical reprocessing uses cases,
+ * this section specifies the buffer flow and controls in more details.
+ *
+ * S10.1 OPAQUE (typically for ZSL use case) reprocessing flow and controls
+ *
+ * For OPAQUE reprocessing (e.g. ZSL) use case, after the application creates the specific
+ * output and input streams, runtime buffer flow and controls are specified as below:
+ *
+ * 1. Application starts output streaming by sending repeating requests for output
+ * opaque buffers and preview. The buffers are held by an application
+ * maintained circular buffer. The requests are based on CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG
+ * capture template, which should have all necessary settings that guarantee output
+ * frame rate is not slowed down relative to sensor output frame rate.
+ *
+ * 2. When a capture is issued, the application selects one output buffer based
+ * on application buffer selection logic, e.g. good AE and AF statistics etc.
+ * Application then creates an reprocess request based on the capture result associated
+ * with this selected buffer. The selected output buffer is now added to this reprocess
+ * request as an input buffer, the output buffer of this reprocess request should be
+ * either JPEG output buffer or YUV output buffer, or both, depending on the application
+ * choice.
+ *
+ * 3. Application then alters the reprocess settings to get best image quality. The HAL must
+ * support and only support below controls if the HAL support OPAQUE_REPROCESSING capability:
+ * - android.jpeg.* (if JPEG buffer is included as one of the output)
+ * - android.noiseReduction.mode (change to HIGH_QUALITY if it is supported)
+ * - android.edge.mode (change to HIGH_QUALITY if it is supported)
+ * All other controls must be ignored by the HAL.
+ * 4. HAL processed the input buffer and return the output buffers in the capture results
+ * as normal.
+ *
+ * S10.2 YUV reprocessing flow and controls
+ *
+ * The YUV reprocessing buffer flow is similar as OPAQUE reprocessing, with below difference:
+ *
+ * 1. Application may want to have finer granularity control of the intermediate YUV images
+ * (before reprocessing). For example, application may choose
+ * - android.noiseReduction.mode == MINIMAL
+ * to make sure the no YUV domain noise reduction has applied to the output YUV buffers,
+ * then it can do its own advanced noise reduction on them. For OPAQUE reprocessing case, this
+ * doesn't matter, as long as the final reprocessed image has the best quality.
+ * 2. Application may modify the YUV output buffer data. For example, for image fusion use
+ * case, where multiple output images are merged together to improve the signal-to-noise
+ * ratio (SNR). The input buffer may be generated from multiple buffers by the application.
+ * To avoid excessive amount of noise reduction and insufficient amount of edge enhancement
+ * being applied to the input buffer, the application can hint the HAL how much effective
+ * exposure time improvement has been done by the application, then the HAL can adjust the
+ * noise reduction and edge enhancement parameters to get best reprocessed image quality.
+ * Below tag can be used for this purpose:
+ * - android.reprocess.effectiveExposureFactor
+ * The value would be exposure time increase factor applied to the original output image,
+ * for example, if there are N image merged, the exposure time increase factor would be up
+ * to sqrt(N). See this tag spec for more details.
+ *
+ * S10.3 Reprocessing pipeline characteristics
+ *
+ * Reprocessing pipeline has below different characteristics comparing with normal output
+ * pipeline:
+ *
+ * 1. The reprocessing result can be returned ahead of the pending normal output results. But
+ * the FIFO ordering must be maintained for all reprocessing results. For example, there are
+ * below requests (A stands for output requests, B stands for reprocessing requests)
+ * being processed by the HAL:
+ * A1, A2, A3, A4, B1, A5, B2, A6...
+ * result of B1 can be returned before A1-A4, but result of B2 must be returned after B1.
+ * 2. Single input rule: For a given reprocessing request, all output buffers must be from the
+ * input buffer, rather than sensor output. For example, if a reprocess request include both
+ * JPEG and preview buffers, all output buffers must be produced from the input buffer
+ * included by the reprocessing request, rather than sensor. The HAL must not output preview
+ * buffers from sensor, while output JPEG buffer from the input buffer.
+ * 3. Input buffer will be from camera output directly (ZSL case) or indirectly(image fusion
+ * case). For the case where buffer is modified, the size will remain same. The HAL can
+ * notify CAMERA3_MSG_ERROR_REQUEST if buffer from unknown source is sent.
+ * 4. Result as reprocessing request: The HAL can expect that a reprocessing request is a copy
+ * of one of the output results with minor allowed setting changes. The HAL can notify
+ * CAMERA3_MSG_ERROR_REQUEST if a request from unknown source is issued.
+ * 5. Output buffers may not be used as inputs across the configure stream boundary, This is
+ * because an opaque stream like the ZSL output stream may have different actual image size
+ * inside of the ZSL buffer to save power and bandwidth for smaller resolution JPEG capture.
+ * The HAL may notify CAMERA3_MSG_ERROR_REQUEST if this case occurs.
+ * 6. HAL Reprocess requests error reporting during flush should follow the same rule specified
+ * by flush() method.
+ *
+ */
+
+__BEGIN_DECLS
+
+struct camera3_device;
+
+/**********************************************************************
+ *
+ * Camera3 stream and stream buffer definitions.
+ *
+ * These structs and enums define the handles and contents of the input and
+ * output streams connecting the HAL to various framework and application buffer
+ * consumers. Each stream is backed by a gralloc buffer queue.
+ *
+ */
+
+/**
+ * camera3_stream_type_t:
+ *
+ * The type of the camera stream, which defines whether the camera HAL device is
+ * the producer or the consumer for that stream, and how the buffers of the
+ * stream relate to the other streams.
+ */
+typedef enum camera3_stream_type {
+ /**
+ * This stream is an output stream; the camera HAL device will be
+ * responsible for filling buffers from this stream with newly captured or
+ * reprocessed image data.
+ */
+ CAMERA3_STREAM_OUTPUT = 0,
+
+ /**
+ * This stream is an input stream; the camera HAL device will be responsible
+ * for reading buffers from this stream and sending them through the camera
+ * processing pipeline, as if the buffer was a newly captured image from the
+ * imager.
+ *
+ * The pixel format for input stream can be any format reported by
+ * android.scaler.availableInputOutputFormatsMap. The pixel format of the
+ * output stream that is used to produce the reprocessing data may be any
+ * format reported by android.scaler.availableStreamConfigurations. The
+ * supported input/output stream combinations depends the camera device
+ * capabilities, see android.scaler.availableInputOutputFormatsMap for
+ * stream map details.
+ *
+ * This kind of stream is generally used to reprocess data into higher
+ * quality images (that otherwise would cause a frame rate performance
+ * loss), or to do off-line reprocessing.
+ *
+ * CAMERA_DEVICE_API_VERSION_3_3:
+ * The typical use cases are OPAQUE (typically ZSL) and YUV reprocessing,
+ * see S8.2, S8.3 and S10 for more details.
+ */
+ CAMERA3_STREAM_INPUT = 1,
+
+ /**
+ * This stream can be used for input and output. Typically, the stream is
+ * used as an output stream, but occasionally one already-filled buffer may
+ * be sent back to the HAL device for reprocessing.
+ *
+ * This kind of stream is meant generally for Zero Shutter Lag (ZSL)
+ * features, where copying the captured image from the output buffer to the
+ * reprocessing input buffer would be expensive. See S8.1 for more details.
+ *
+ * Note that the HAL will always be reprocessing data it produced.
+ *
+ */
+ CAMERA3_STREAM_BIDIRECTIONAL = 2,
+
+ /**
+ * Total number of framework-defined stream types
+ */
+ CAMERA3_NUM_STREAM_TYPES
+
+} camera3_stream_type_t;
+
+/**
+ * camera3_stream_rotation_t:
+ *
+ * The required counterclockwise rotation of camera stream.
+ */
+typedef enum camera3_stream_rotation {
+ /* No rotation */
+ CAMERA3_STREAM_ROTATION_0 = 0,
+
+ /* Rotate by 90 degree counterclockwise */
+ CAMERA3_STREAM_ROTATION_90 = 1,
+
+ /* Rotate by 180 degree counterclockwise */
+ CAMERA3_STREAM_ROTATION_180 = 2,
+
+ /* Rotate by 270 degree counterclockwise */
+ CAMERA3_STREAM_ROTATION_270 = 3
+} camera3_stream_rotation_t;
+
+/**
+ * camera3_stream_configuration_mode_t:
+ *
+ * This defines the general operation mode for the HAL (for a given stream configuration), where
+ * modes besides NORMAL have different semantics, and usually limit the generality of the API in
+ * exchange for higher performance in some particular area.
+ */
+typedef enum camera3_stream_configuration_mode {
+ /**
+ * Normal stream configuration operation mode. This is the default camera operation mode,
+ * where all semantics of HAL APIs and metadata controls apply.
+ */
+ CAMERA3_STREAM_CONFIGURATION_NORMAL_MODE = 0,
+
+ /**
+ * Special constrained high speed operation mode for devices that can not support high
+ * speed output in NORMAL mode. All streams in this configuration are operating at high speed
+ * mode and have different characteristics and limitations to achieve high speed output.
+ * The NORMAL mode can still be used for high speed output if the HAL can support high speed
+ * output while satisfying all the semantics of HAL APIs and metadata controls. It is
+ * recommended for the HAL to support high speed output in NORMAL mode (by advertising the high
+ * speed FPS ranges in android.control.aeAvailableTargetFpsRanges) if possible.
+ *
+ * This mode has below limitations/requirements:
+ *
+ * 1. The HAL must support up to 2 streams with sizes reported by
+ * android.control.availableHighSpeedVideoConfigurations.
+ * 2. In this mode, the HAL is expected to output up to 120fps or higher. This mode must
+ * support the targeted FPS range and size configurations reported by
+ * android.control.availableHighSpeedVideoConfigurations.
+ * 3. The HAL must support HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED output stream format.
+ * 4. To achieve efficient high speed streaming, the HAL may have to aggregate
+ * multiple frames together and send to camera device for processing where the request
+ * controls are same for all the frames in this batch (batch mode). The HAL must support
+ * max batch size and the max batch size requirements defined by
+ * android.control.availableHighSpeedVideoConfigurations.
+ * 5. In this mode, the HAL must override aeMode, awbMode, and afMode to ON, ON, and
+ * CONTINUOUS_VIDEO, respectively. All post-processing block mode controls must be
+ * overridden to be FAST. Therefore, no manual control of capture and post-processing
+ * parameters is possible. All other controls operate the same as when
+ * android.control.mode == AUTO. This means that all other android.control.* fields
+ * must continue to work, such as
+ *
+ * android.control.aeTargetFpsRange
+ * android.control.aeExposureCompensation
+ * android.control.aeLock
+ * android.control.awbLock
+ * android.control.effectMode
+ * android.control.aeRegions
+ * android.control.afRegions
+ * android.control.awbRegions
+ * android.control.afTrigger
+ * android.control.aePrecaptureTrigger
+ *
+ * Outside of android.control.*, the following controls must work:
+ *
+ * android.flash.mode (TORCH mode only, automatic flash for still capture will not work
+ * since aeMode is ON)
+ * android.lens.opticalStabilizationMode (if it is supported)
+ * android.scaler.cropRegion
+ * android.statistics.faceDetectMode (if it is supported)
+ * 6. To reduce the amount of data passed across process boundaries at
+ * high frame rate, within one batch, camera framework only propagates
+ * the last shutter notify and the last capture results (including partial
+ * results and final result) to the app. The shutter notifies and capture
+ * results for the other requests in the batch are derived by
+ * the camera framework. As a result, the HAL can return empty metadata
+ * except for the last result in the batch.
+ *
+ * For more details about high speed stream requirements, see
+ * android.control.availableHighSpeedVideoConfigurations and CONSTRAINED_HIGH_SPEED_VIDEO
+ * capability defined in android.request.availableCapabilities.
+ *
+ * This mode only needs to be supported by HALs that include CONSTRAINED_HIGH_SPEED_VIDEO in
+ * the android.request.availableCapabilities static metadata.
+ */
+ CAMERA3_STREAM_CONFIGURATION_CONSTRAINED_HIGH_SPEED_MODE = 1,
+
+ /**
+ * First value for vendor-defined stream configuration modes.
+ */
+ CAMERA3_VENDOR_STREAM_CONFIGURATION_MODE_START = 0x8000
+} camera3_stream_configuration_mode_t;
+
+/**
+ * camera3_stream_t:
+ *
+ * A handle to a single camera input or output stream. A stream is defined by
+ * the framework by its buffer resolution and format, and additionally by the
+ * HAL with the gralloc usage flags and the maximum in-flight buffer count.
+ *
+ * The stream structures are owned by the framework, but pointers to a
+ * camera3_stream passed into the HAL by configure_streams() are valid until the
+ * end of the first subsequent configure_streams() call that _does not_ include
+ * that camera3_stream as an argument, or until the end of the close() call.
+ *
+ * All camera3_stream framework-controlled members are immutable once the
+ * camera3_stream is passed into configure_streams(). The HAL may only change
+ * the HAL-controlled parameters during a configure_streams() call, except for
+ * the contents of the private pointer.
+ *
+ * If a configure_streams() call returns a non-fatal error, all active streams
+ * remain valid as if configure_streams() had not been called.
+ *
+ * The endpoint of the stream is not visible to the camera HAL device.
+ * In DEVICE_API_VERSION_3_1, this was changed to share consumer usage flags
+ * on streams where the camera is a producer (OUTPUT and BIDIRECTIONAL stream
+ * types) see the usage field below.
+ */
+typedef struct camera3_stream {
+
+ /*****
+ * Set by framework before configure_streams()
+ */
+
+ /**
+ * The type of the stream, one of the camera3_stream_type_t values.
+ */
+ int stream_type;
+
+ /**
+ * The width in pixels of the buffers in this stream
+ */
+ uint32_t width;
+
+ /**
+ * The height in pixels of the buffers in this stream
+ */
+ uint32_t height;
+
+ /**
+ * The pixel format for the buffers in this stream. Format is a value from
+ * the HAL_PIXEL_FORMAT_* list in system/core/include/system/graphics.h, or
+ * from device-specific headers.
+ *
+ * If HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, then the platform
+ * gralloc module will select a format based on the usage flags provided by
+ * the camera device and the other endpoint of the stream.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * The camera HAL device must inspect the buffers handed to it in the
+ * subsequent register_stream_buffers() call to obtain the
+ * implementation-specific format details, if necessary.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * register_stream_buffers() won't be called by the framework, so the HAL
+ * should configure the ISP and sensor pipeline based purely on the sizes,
+ * usage flags, and formats for the configured streams.
+ */
+ int format;
+
+ /*****
+ * Set by HAL during configure_streams().
+ */
+
+ /**
+ * The gralloc usage flags for this stream, as needed by the HAL. The usage
+ * flags are defined in gralloc.h (GRALLOC_USAGE_*), or in device-specific
+ * headers.
+ *
+ * For output streams, these are the HAL's producer usage flags. For input
+ * streams, these are the HAL's consumer usage flags. The usage flags from
+ * the producer and the consumer will be combined together and then passed
+ * to the platform gralloc HAL module for allocating the gralloc buffers for
+ * each stream.
+ *
+ * Version information:
+ *
+ * == CAMERA_DEVICE_API_VERSION_3_0:
+ *
+ * No initial value guaranteed when passed via configure_streams().
+ * HAL may not use this field as input, and must write over this field
+ * with its usage flags.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * For stream_type OUTPUT and BIDIRECTIONAL, when passed via
+ * configure_streams(), the initial value of this is the consumer's
+ * usage flags. The HAL may use these consumer flags to decide stream
+ * configuration.
+ * For stream_type INPUT, when passed via configure_streams(), the initial
+ * value of this is 0.
+ * For all streams passed via configure_streams(), the HAL must write
+ * over this field with its usage flags.
+ *
+ * From Android O, the usage flag for an output stream may be bitwise
+ * combination of usage flags for multiple consumers, for the purpose of
+ * sharing one camera stream between those consumers. The HAL must fail
+ * configure_streams call with -EINVAL if the combined flags cannot be
+ * supported due to imcompatible buffer format, dataSpace, or other hardware
+ * limitations.
+ */
+#ifdef CAMERA_64BIT_USAGE
+ uint64_t usage;
+#else
+ uint32_t usage;
+#endif
+
+ /**
+ * The maximum number of buffers the HAL device may need to have dequeued at
+ * the same time. The HAL device may not have more buffers in-flight from
+ * this stream than this value.
+ */
+ uint32_t max_buffers;
+
+ /**
+ * A handle to HAL-private information for the stream. Will not be inspected
+ * by the framework code.
+ */
+ void *priv;
+
+ /**
+ * A field that describes the contents of the buffer. The format and buffer
+ * dimensions define the memory layout and structure of the stream buffers,
+ * while dataSpace defines the meaning of the data within the buffer.
+ *
+ * For most formats, dataSpace defines the color space of the image data.
+ * In addition, for some formats, dataSpace indicates whether image- or
+ * depth-based data is requested. See system/core/include/system/graphics.h
+ * for details of formats and valid dataSpace values for each format.
+ *
+ * Version information:
+ *
+ * < CAMERA_DEVICE_API_VERSION_3_3:
+ *
+ * Not defined and should not be accessed. dataSpace should be assumed to
+ * be HAL_DATASPACE_UNKNOWN, and the appropriate color space, etc, should
+ * be determined from the usage flags and the format.
+ *
+ * = CAMERA_DEVICE_API_VERSION_3_3:
+ *
+ * Always set by the camera service. HAL must use this dataSpace to
+ * configure the stream to the correct colorspace, or to select between
+ * color and depth outputs if supported. The dataspace values are the
+ * legacy definitions in graphics.h
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_4:
+ *
+ * Always set by the camera service. HAL must use this dataSpace to
+ * configure the stream to the correct colorspace, or to select between
+ * color and depth outputs if supported. The dataspace values are set
+ * using the V0 dataspace definitions in graphics.h
+ */
+ android_dataspace_t data_space;
+
+ /**
+ * The required output rotation of the stream, one of
+ * the camera3_stream_rotation_t values. This must be inspected by HAL along
+ * with stream width and height. For example, if the rotation is 90 degree
+ * and the stream width and height is 720 and 1280 respectively, camera service
+ * will supply buffers of size 720x1280, and HAL should capture a 1280x720 image
+ * and rotate the image by 90 degree counterclockwise. The rotation field is
+ * no-op when the stream type is input. Camera HAL must ignore the rotation
+ * field for an input stream.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Not defined and must not be accessed. HAL must not apply any rotation
+ * on output images.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_3:
+ *
+ * Always set by camera service. HAL must inspect this field during stream
+ * configuration and returns -EINVAL if HAL cannot perform such rotation.
+ * HAL must always support CAMERA3_STREAM_ROTATION_0, so a
+ * configure_streams() call must not fail for unsupported rotation if
+ * rotation field of all streams is CAMERA3_STREAM_ROTATION_0.
+ *
+ */
+ int rotation;
+
+ /**
+ * The physical camera id this stream belongs to.
+ *
+ * <= CAMERA_DEVICE_API_VERISON_3_4:
+ *
+ * Not defined and must not be accessed.
+ *
+ * >= CAMERA_DEVICE_API_VERISON_3_5:
+ *
+ * Always set by camera service. If the camera device is not a logical
+ * multi camera, or if the camera is a logical multi camera but the stream
+ * is not a physical output stream, this field will point to a 0-length
+ * string.
+ *
+ * A logical multi camera is a camera device backed by multiple physical
+ * cameras that are also exposed to the application. And for a logical
+ * multi camera, a physical output stream is an output stream specifically
+ * requested on an underlying physical camera.
+ *
+ * For an input stream, this field is guaranteed to be a 0-length string.
+ */
+ const char* physical_camera_id;
+
+ /* reserved for future use */
+ void *reserved[6];
+
+#ifdef CAMERA_NEEDS_SEC_RESERVED_FIELD
+ char reserved_sec[0x28];
+#endif
+
+} camera3_stream_t;
+
+/**
+ * camera3_stream_configuration_t:
+ *
+ * A structure of stream definitions, used by configure_streams(). This
+ * structure defines all the output streams and the reprocessing input
+ * stream for the current camera use case.
+ */
+typedef struct camera3_stream_configuration {
+ /**
+ * The total number of streams requested by the framework. This includes
+ * both input and output streams. The number of streams will be at least 1,
+ * and there will be at least one output-capable stream.
+ */
+ uint32_t num_streams;
+
+ /**
+ * An array of camera stream pointers, defining the input/output
+ * configuration for the camera HAL device.
+ *
+ * At most one input-capable stream may be defined (INPUT or BIDIRECTIONAL)
+ * in a single configuration.
+ *
+ * At least one output-capable stream must be defined (OUTPUT or
+ * BIDIRECTIONAL).
+ */
+ camera3_stream_t **streams;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_3:
+ *
+ * The operation mode of streams in this configuration, one of the value
+ * defined in camera3_stream_configuration_mode_t. The HAL can use this
+ * mode as an indicator to set the stream property (e.g.,
+ * camera3_stream->max_buffers) appropriately. For example, if the
+ * configuration is
+ * CAMERA3_STREAM_CONFIGURATION_CONSTRAINED_HIGH_SPEED_MODE, the HAL may
+ * want to set aside more buffers for batch mode operation (see
+ * android.control.availableHighSpeedVideoConfigurations for batch mode
+ * definition).
+ *
+ */
+ uint32_t operation_mode;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ *
+ * The session metadata buffer contains the initial values of
+ * ANDROID_REQUEST_AVAILABLE_SESSION_KEYS. This field is optional
+ * and camera clients can choose to ignore it, in which case it will
+ * be set to NULL. If parameters are present, then Hal should examine
+ * the parameter values and configure its internal camera pipeline
+ * accordingly.
+ */
+ const camera_metadata_t *session_parameters;
+} camera3_stream_configuration_t;
+
+/**
+ * camera3_buffer_status_t:
+ *
+ * The current status of a single stream buffer.
+ */
+typedef enum camera3_buffer_status {
+ /**
+ * The buffer is in a normal state, and can be used after waiting on its
+ * sync fence.
+ */
+ CAMERA3_BUFFER_STATUS_OK = 0,
+
+ /**
+ * The buffer does not contain valid data, and the data in it should not be
+ * used. The sync fence must still be waited on before reusing the buffer.
+ */
+ CAMERA3_BUFFER_STATUS_ERROR = 1
+
+} camera3_buffer_status_t;
+
+/**
+ * camera3_stream_buffer_t:
+ *
+ * A single buffer from a camera3 stream. It includes a handle to its parent
+ * stream, the handle to the gralloc buffer itself, and sync fences
+ *
+ * The buffer does not specify whether it is to be used for input or output;
+ * that is determined by its parent stream type and how the buffer is passed to
+ * the HAL device.
+ */
+typedef struct camera3_stream_buffer {
+ /**
+ * The handle of the stream this buffer is associated with
+ */
+ camera3_stream_t *stream;
+
+ /**
+ * The native handle to the buffer
+ */
+ buffer_handle_t *buffer;
+
+ /**
+ * Current state of the buffer, one of the camera3_buffer_status_t
+ * values. The framework will not pass buffers to the HAL that are in an
+ * error state. In case a buffer could not be filled by the HAL, it must
+ * have its status set to CAMERA3_BUFFER_STATUS_ERROR when returned to the
+ * framework with process_capture_result().
+ */
+ int status;
+
+ /**
+ * The acquire sync fence for this buffer. The HAL must wait on this fence
+ * fd before attempting to read from or write to this buffer.
+ *
+ * The framework may be set to -1 to indicate that no waiting is necessary
+ * for this buffer.
+ *
+ * When the HAL returns an output buffer to the framework with
+ * process_capture_result(), the acquire_fence must be set to -1. If the HAL
+ * never waits on the acquire_fence due to an error in filling a buffer,
+ * when calling process_capture_result() the HAL must set the release_fence
+ * of the buffer to be the acquire_fence passed to it by the framework. This
+ * will allow the framework to wait on the fence before reusing the buffer.
+ *
+ * For input buffers, the HAL must not change the acquire_fence field during
+ * the process_capture_request() call.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * When the HAL returns an input buffer to the framework with
+ * process_capture_result(), the acquire_fence must be set to -1. If the HAL
+ * never waits on input buffer acquire fence due to an error, the sync
+ * fences should be handled similarly to the way they are handled for output
+ * buffers.
+ */
+ int acquire_fence;
+
+ /**
+ * The release sync fence for this buffer. The HAL must set this fence when
+ * returning buffers to the framework, or write -1 to indicate that no
+ * waiting is required for this buffer.
+ *
+ * For the output buffers, the fences must be set in the output_buffers
+ * array passed to process_capture_result().
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * For the input buffer, the release fence must be set by the
+ * process_capture_request() call.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * For the input buffer, the fences must be set in the input_buffer
+ * passed to process_capture_result().
+ *
+ * After signaling the release_fence for this buffer, the HAL
+ * should not make any further attempts to access this buffer as the
+ * ownership has been fully transferred back to the framework.
+ *
+ * If a fence of -1 was specified then the ownership of this buffer
+ * is transferred back immediately upon the call of process_capture_result.
+ */
+ int release_fence;
+
+} camera3_stream_buffer_t;
+
+/**
+ * camera3_stream_buffer_set_t:
+ *
+ * The complete set of gralloc buffers for a stream. This structure is given to
+ * register_stream_buffers() to allow the camera HAL device to register/map/etc
+ * newly allocated stream buffers.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Deprecated (and not used). In particular,
+ * register_stream_buffers is also deprecated and will never be invoked.
+ *
+ */
+typedef struct camera3_stream_buffer_set {
+ /**
+ * The stream handle for the stream these buffers belong to
+ */
+ camera3_stream_t *stream;
+
+ /**
+ * The number of buffers in this stream. It is guaranteed to be at least
+ * stream->max_buffers.
+ */
+ uint32_t num_buffers;
+
+ /**
+ * The array of gralloc buffer handles for this stream. If the stream format
+ * is set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, the camera HAL device
+ * should inspect the passed-in buffers to determine any platform-private
+ * pixel format information.
+ */
+ buffer_handle_t **buffers;
+
+} camera3_stream_buffer_set_t;
+
+/**
+ * camera3_jpeg_blob:
+ *
+ * Transport header for compressed JPEG or JPEG_APP_SEGMENTS buffers in output streams.
+ *
+ * To capture JPEG or JPEG_APP_SEGMENTS images, a stream is created using the pixel format
+ * HAL_PIXEL_FORMAT_BLOB. The buffer size for the stream is calculated by the
+ * framework, based on the static metadata field android.jpeg.maxSize for JPEG,
+ * and android.jpeg.maxAppsSegments for JPEG_APP_SEGMENTS.
+ *
+ * Since compressed JPEG/JPEG_APP_SEGMENTS images are of variable size, the HAL needs to
+ * include the final size of the image using this structure inside the output
+ * stream buffer. The JPEG blob ID field must be set to CAMERA3_JPEG_BLOB_ID for
+ * JPEG and CAMERA3_JPEG_APP_SEGMENTS_BLOB_ID for APP segments.
+ *
+ * Transport header should be at the end of the output stream buffer. That
+ * means the jpeg_blob_id must start at byte[buffer_size -
+ * sizeof(camera3_jpeg_blob)], where the buffer_size is the size of gralloc buffer.
+ * The blob data itself starts at the beginning of the buffer and should be
+ * jpeg_size bytes long. HAL using this transport header for JPEG must account for
+ * it in android.jpeg.maxSize. For JPEG APP segments, camera framework makes
+ * sure that the output stream buffer is large enough for the transport header.
+ */
+typedef struct camera3_jpeg_blob {
+ uint16_t jpeg_blob_id;
+ uint32_t jpeg_size;
+} camera3_jpeg_blob_t;
+
+enum {
+ CAMERA3_JPEG_BLOB_ID = 0x00FF,
+ CAMERA3_JPEG_APP_SEGMENTS_BLOB_ID = 0x0100,
+};
+
+/**********************************************************************
+ *
+ * Message definitions for the HAL notify() callback.
+ *
+ * These definitions are used for the HAL notify callback, to signal
+ * asynchronous events from the HAL device to the Android framework.
+ *
+ */
+
+/**
+ * camera3_msg_type:
+ *
+ * Indicates the type of message sent, which specifies which member of the
+ * message union is valid.
+ *
+ */
+typedef enum camera3_msg_type {
+ /**
+ * An error has occurred. camera3_notify_msg.message.error contains the
+ * error information.
+ */
+ CAMERA3_MSG_ERROR = 1,
+
+ /**
+ * The exposure of a given request or processing a reprocess request has
+ * begun. camera3_notify_msg.message.shutter contains the information
+ * the capture.
+ */
+ CAMERA3_MSG_SHUTTER = 2,
+
+ /**
+ * Number of framework message types
+ */
+ CAMERA3_NUM_MESSAGES
+
+} camera3_msg_type_t;
+
+/**
+ * Defined error codes for CAMERA_MSG_ERROR
+ */
+typedef enum camera3_error_msg_code {
+ /**
+ * A serious failure occured. No further frames or buffer streams will
+ * be produced by the device. Device should be treated as closed. The
+ * client must reopen the device to use it again. The frame_number field
+ * is unused.
+ */
+ CAMERA3_MSG_ERROR_DEVICE = 1,
+
+ /**
+ * An error has occurred in processing a request. No output (metadata or
+ * buffers) will be produced for this request. The frame_number field
+ * specifies which request has been dropped. Subsequent requests are
+ * unaffected, and the device remains operational.
+ */
+ CAMERA3_MSG_ERROR_REQUEST = 2,
+
+ /**
+ * An error has occurred in producing an output result metadata buffer
+ * for a request, but output stream buffers for it will still be
+ * available. Subsequent requests are unaffected, and the device remains
+ * operational. The frame_number field specifies the request for which
+ * result metadata won't be available.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_6:
+ *
+ * In case the result metadata is absent for a logical camera device, then the
+ * error_stream pointer must be set to NULL.
+ * If the result metadata cannot be produced for a physical camera device, then
+ * error_stream must contain a pointer to a respective stream associated with
+ * that physical device.
+ */
+ CAMERA3_MSG_ERROR_RESULT = 3,
+
+ /**
+ * An error has occurred in placing an output buffer into a stream for a
+ * request. The frame metadata and other buffers may still be
+ * available. Subsequent requests are unaffected, and the device remains
+ * operational. The frame_number field specifies the request for which the
+ * buffer was dropped, and error_stream contains a pointer to the stream
+ * that dropped the frame.
+ */
+ CAMERA3_MSG_ERROR_BUFFER = 4,
+
+ /**
+ * Number of error types
+ */
+ CAMERA3_MSG_NUM_ERRORS
+
+} camera3_error_msg_code_t;
+
+/**
+ * camera3_error_msg_t:
+ *
+ * Message contents for CAMERA3_MSG_ERROR
+ */
+typedef struct camera3_error_msg {
+ /**
+ * Frame number of the request the error applies to. 0 if the frame number
+ * isn't applicable to the error.
+ */
+ uint32_t frame_number;
+
+ /**
+ * Pointer to the stream that had a failure. NULL if the stream isn't
+ * applicable to the error.
+ */
+ camera3_stream_t *error_stream;
+
+ /**
+ * The code for this error; one of the CAMERA_MSG_ERROR enum values.
+ */
+ int error_code;
+
+} camera3_error_msg_t;
+
+/**
+ * camera3_shutter_msg_t:
+ *
+ * Message contents for CAMERA3_MSG_SHUTTER
+ */
+typedef struct camera3_shutter_msg {
+ /**
+ * Frame number of the request that has begun exposure or reprocessing.
+ */
+ uint32_t frame_number;
+
+ /**
+ * Timestamp for the start of capture. For a reprocess request, this must
+ * be input image's start of capture. This must match the capture result
+ * metadata's sensor exposure start timestamp.
+ */
+ uint64_t timestamp;
+
+} camera3_shutter_msg_t;
+
+/**
+ * camera3_notify_msg_t:
+ *
+ * The message structure sent to camera3_callback_ops_t.notify()
+ */
+typedef struct camera3_notify_msg {
+
+ /**
+ * The message type. One of camera3_notify_msg_type, or a private extension.
+ */
+ int type;
+
+ union {
+ /**
+ * Error message contents. Valid if type is CAMERA3_MSG_ERROR
+ */
+ camera3_error_msg_t error;
+
+ /**
+ * Shutter message contents. Valid if type is CAMERA3_MSG_SHUTTER
+ */
+ camera3_shutter_msg_t shutter;
+
+ /**
+ * Generic message contents. Used to ensure a minimum size for custom
+ * message types.
+ */
+ uint8_t generic[32];
+ } message;
+
+} camera3_notify_msg_t;
+
+
+/**********************************************************************
+ *
+ * Types definition for request_stream_buffers() callback.
+ *
+ */
+
+/**
+ * camera3_buffer_request_status_t:
+ *
+ * The overall buffer request status returned by request_stream_buffers()
+ */
+typedef enum camera3_buffer_request_status {
+ /**
+ * request_stream_buffers() call succeeded and all requested buffers are
+ * returned.
+ */
+ CAMERA3_BUF_REQ_OK = 0,
+
+ /**
+ * request_stream_buffers() call failed for some streams.
+ * Check per stream status for each returned camera3_stream_buffer_ret_t.
+ */
+ CAMERA3_BUF_REQ_FAILED_PARTIAL = 1,
+
+ /**
+ * request_stream_buffers() call failed for all streams and no buffers are
+ * returned at all. Camera service is about to or is performing
+ * configure_streams() call. HAL must wait until next configure_streams()
+ * call is finished before requesting buffers again.
+ */
+ CAMERA3_BUF_REQ_FAILED_CONFIGURING = 2,
+
+ /**
+ * request_stream_buffers() call failed for all streams and no buffers are
+ * returned at all. Failure due to bad camera3_buffer_request input, eg:
+ * unknown stream or repeated stream in the list of buffer requests.
+ */
+ CAMERA3_BUF_REQ_FAILED_ILLEGAL_ARGUMENTS = 3,
+
+ /**
+ * request_stream_buffers() call failed for all streams and no buffers are
+ * returned at all. This can happen for unknown reasons or a combination
+ * of different failure reasons per stream. For the latter case, caller can
+ * check per stream failure reason returned in camera3_stream_buffer_ret.
+ */
+ CAMERA3_BUF_REQ_FAILED_UNKNOWN = 4,
+
+ /**
+ * Number of buffer request status
+ */
+ CAMERA3_BUF_REQ_NUM_STATUS
+
+} camera3_buffer_request_status_t;
+
+/**
+ * camera3_stream_buffer_req_status_t:
+ *
+ * The per stream buffer request status returned by request_stream_buffers()
+ */
+typedef enum camera3_stream_buffer_req_status {
+ /**
+ * Get buffer succeeds and all requested buffers are returned.
+ */
+ CAMERA3_PS_BUF_REQ_OK = 0,
+
+ /**
+ * Get buffer failed due to timeout waiting for an available buffer. This is
+ * likely due to the client application holding too many buffers, or the
+ * system is under memory pressure.
+ * This is not a fatal error. HAL can try to request buffer for this stream
+ * later. If HAL cannot get a buffer for certain capture request in time
+ * due to this error, HAL can send an ERROR_REQUEST to camera service and
+ * drop processing that request.
+ */
+ CAMERA3_PS_BUF_REQ_NO_BUFFER_AVAILABLE = 1,
+
+ /**
+ * Get buffer failed due to HAL has reached its maxBuffer count. This is not
+ * a fatal error. HAL can try to request buffer for this stream again after
+ * it returns at least one buffer of that stream to camera service.
+ */
+ CAMERA3_PS_BUF_REQ_MAX_BUFFER_EXCEEDED = 2,
+
+ /**
+ * Get buffer failed due to the stream is disconnected by client
+ * application, has been removed, or not recognized by camera service.
+ * This means application is no longer interested in this stream.
+ * Requesting buffer for this stream will never succeed after this error is
+ * returned. HAL must safely return all buffers of this stream after
+ * getting this error. If HAL gets another capture request later targeting
+ * a disconnected stream, HAL must send an ERROR_REQUEST to camera service
+ * and drop processing that request.
+ */
+ CAMERA3_PS_BUF_REQ_STREAM_DISCONNECTED = 3,
+
+ /**
+ * Get buffer failed for unknown reason. This is a fatal error and HAL must
+ * send ERROR_DEVICE to camera service and be ready to be closed.
+ */
+ CAMERA3_PS_BUF_REQ_UNKNOWN_ERROR = 4,
+
+ /**
+ * Number of buffer request status
+ */
+ CAMERA3_PS_BUF_REQ_NUM_STATUS
+} camera3_stream_buffer_req_status_t;
+
+typedef struct camera3_buffer_request {
+ /**
+ * The stream HAL wants to request buffer from
+ */
+ camera3_stream_t *stream;
+
+ /**
+ * The number of buffers HAL requested
+ */
+ uint32_t num_buffers_requested;
+} camera3_buffer_request_t;
+
+typedef struct camera3_stream_buffer_ret {
+ /**
+ * The stream HAL wants to request buffer from
+ */
+ camera3_stream_t *stream;
+
+ /**
+ * The status of buffer request of this stream
+ */
+ camera3_stream_buffer_req_status_t status;
+
+ /**
+ * Number of output buffers returned. Must be 0 when above status is not
+ * CAMERA3_PS_BUF_REQ_OK; otherwise the value must be equal to
+ * num_buffers_requested in the corresponding camera3_buffer_request_t
+ */
+ uint32_t num_output_buffers;
+
+ /**
+ * The returned output buffers for the stream.
+ * Caller of request_stream_buffers() should supply this with enough memory
+ * (num_buffers_requested * sizeof(camera3_stream_buffer_t))
+ */
+ camera3_stream_buffer_t *output_buffers;
+} camera3_stream_buffer_ret_t;
+
+
+/**********************************************************************
+ *
+ * Capture request/result definitions for the HAL process_capture_request()
+ * method, and the process_capture_result() callback.
+ *
+ */
+
+/**
+ * camera3_request_template_t:
+ *
+ * Available template types for
+ * camera3_device_ops.construct_default_request_settings()
+ */
+typedef enum camera3_request_template {
+ /**
+ * Standard camera preview operation with 3A on auto.
+ */
+ CAMERA3_TEMPLATE_PREVIEW = 1,
+
+ /**
+ * Standard camera high-quality still capture with 3A and flash on auto.
+ */
+ CAMERA3_TEMPLATE_STILL_CAPTURE = 2,
+
+ /**
+ * Standard video recording plus preview with 3A on auto, torch off.
+ */
+ CAMERA3_TEMPLATE_VIDEO_RECORD = 3,
+
+ /**
+ * High-quality still capture while recording video. Application will
+ * include preview, video record, and full-resolution YUV or JPEG streams in
+ * request. Must not cause stuttering on video stream. 3A on auto.
+ */
+ CAMERA3_TEMPLATE_VIDEO_SNAPSHOT = 4,
+
+ /**
+ * Zero-shutter-lag mode. Application will request preview and
+ * full-resolution data for each frame, and reprocess it to JPEG when a
+ * still image is requested by user. Settings should provide highest-quality
+ * full-resolution images without compromising preview frame rate. 3A on
+ * auto.
+ */
+ CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG = 5,
+
+ /**
+ * A basic template for direct application control of capture
+ * parameters. All automatic control is disabled (auto-exposure, auto-white
+ * balance, auto-focus), and post-processing parameters are set to preview
+ * quality. The manual capture parameters (exposure, sensitivity, etc.)
+ * are set to reasonable defaults, but should be overridden by the
+ * application depending on the intended use case.
+ */
+ CAMERA3_TEMPLATE_MANUAL = 6,
+
+ /* Total number of templates */
+ CAMERA3_TEMPLATE_COUNT,
+
+ /**
+ * First value for vendor-defined request templates
+ */
+ CAMERA3_VENDOR_TEMPLATE_START = 0x40000000
+
+} camera3_request_template_t;
+
+/**
+ * camera3_capture_request_t:
+ *
+ * A single request for image capture/buffer reprocessing, sent to the Camera
+ * HAL device by the framework in process_capture_request().
+ *
+ * The request contains the settings to be used for this capture, and the set of
+ * output buffers to write the resulting image data in. It may optionally
+ * contain an input buffer, in which case the request is for reprocessing that
+ * input buffer instead of capturing a new image with the camera sensor. The
+ * capture is identified by the frame_number.
+ *
+ * In response, the camera HAL device must send a camera3_capture_result
+ * structure asynchronously to the framework, using the process_capture_result()
+ * callback.
+ */
+typedef struct camera3_capture_request {
+ /**
+ * The frame number is an incrementing integer set by the framework to
+ * uniquely identify this capture. It needs to be returned in the result
+ * call, and is also used to identify the request in asynchronous
+ * notifications sent to camera3_callback_ops_t.notify().
+ */
+ uint32_t frame_number;
+
+ /**
+ * The settings buffer contains the capture and processing parameters for
+ * the request. As a special case, a NULL settings buffer indicates that the
+ * settings are identical to the most-recently submitted capture request. A
+ * NULL buffer cannot be used as the first submitted request after a
+ * configure_streams() call.
+ */
+ const camera_metadata_t *settings;
+
+ /**
+ * The input stream buffer to use for this request, if any.
+ *
+ * If input_buffer is NULL, then the request is for a new capture from the
+ * imager. If input_buffer is valid, the request is for reprocessing the
+ * image contained in input_buffer.
+ *
+ * In the latter case, the HAL must set the release_fence of the
+ * input_buffer to a valid sync fence, or to -1 if the HAL does not support
+ * sync, before process_capture_request() returns.
+ *
+ * The HAL is required to wait on the acquire sync fence of the input buffer
+ * before accessing it.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * Any input buffer included here will have been registered with the HAL
+ * through register_stream_buffers() before its inclusion in a request.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * The buffers will not have been pre-registered with the HAL.
+ * Subsequent requests may reuse buffers, or provide entirely new buffers.
+ */
+ camera3_stream_buffer_t *input_buffer;
+
+ /**
+ * The number of output buffers for this capture request. Must be at least
+ * 1.
+ */
+ uint32_t num_output_buffers;
+
+ /**
+ * An array of num_output_buffers stream buffers, to be filled with image
+ * data from this capture/reprocess. The HAL must wait on the acquire fences
+ * of each stream buffer before writing to them.
+ *
+ * The HAL takes ownership of the actual buffer_handle_t entries in
+ * output_buffers; the framework does not access them until they are
+ * returned in a camera3_capture_result_t.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * All the buffers included here will have been registered with the HAL
+ * through register_stream_buffers() before their inclusion in a request.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Any or all of the buffers included here may be brand new in this
+ * request (having never before seen by the HAL).
+ */
+ const camera3_stream_buffer_t *output_buffers;
+
+ /**
+ * <= CAMERA_DEVICE_API_VERISON_3_4:
+ *
+ * Not defined and must not be accessed.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ * The number of physical camera settings to be applied. If 'num_physcam_settings'
+ * equals 0 or a physical device is not included, then Hal must decide the
+ * specific physical device settings based on the default 'settings'.
+ */
+ uint32_t num_physcam_settings;
+
+ /**
+ * <= CAMERA_DEVICE_API_VERISON_3_4:
+ *
+ * Not defined and must not be accessed.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ * The physical camera ids. The array will contain 'num_physcam_settings'
+ * camera id strings for all physical devices that have specific settings.
+ * In case some id is invalid, the process capture request must fail and return
+ * -EINVAL.
+ */
+ const char **physcam_id;
+
+ /**
+ * <= CAMERA_DEVICE_API_VERISON_3_4:
+ *
+ * Not defined and must not be accessed.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ * The capture settings for the physical cameras. The array will contain
+ * 'num_physcam_settings' settings for invididual physical devices. In
+ * case the settings at some particular index are empty, the process capture
+ * request must fail and return -EINVAL.
+ */
+ const camera_metadata_t **physcam_settings;
+
+} camera3_capture_request_t;
+
+/**
+ * camera3_capture_result_t:
+ *
+ * The result of a single capture/reprocess by the camera HAL device. This is
+ * sent to the framework asynchronously with process_capture_result(), in
+ * response to a single capture request sent to the HAL with
+ * process_capture_request(). Multiple process_capture_result() calls may be
+ * performed by the HAL for each request.
+ *
+ * Each call, all with the same frame
+ * number, may contain some subset of the output buffers, and/or the result
+ * metadata. The metadata may only be provided once for a given frame number;
+ * all other calls must set the result metadata to NULL.
+ *
+ * The result structure contains the output metadata from this capture, and the
+ * set of output buffers that have been/will be filled for this capture. Each
+ * output buffer may come with a release sync fence that the framework will wait
+ * on before reading, in case the buffer has not yet been filled by the HAL.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * The metadata may be provided multiple times for a single frame number. The
+ * framework will accumulate together the final result set by combining each
+ * partial result together into the total result set.
+ *
+ * If an input buffer is given in a request, the HAL must return it in one of
+ * the process_capture_result calls, and the call may be to just return the input
+ * buffer, without metadata and output buffers; the sync fences must be handled
+ * the same way they are done for output buffers.
+ *
+ *
+ * Performance considerations:
+ *
+ * Applications will also receive these partial results immediately, so sending
+ * partial results is a highly recommended performance optimization to avoid
+ * the total pipeline latency before sending the results for what is known very
+ * early on in the pipeline.
+ *
+ * A typical use case might be calculating the AF state halfway through the
+ * pipeline; by sending the state back to the framework immediately, we get a
+ * 50% performance increase and perceived responsiveness of the auto-focus.
+ *
+ */
+typedef struct camera3_capture_result {
+ /**
+ * The frame number is an incrementing integer set by the framework in the
+ * submitted request to uniquely identify this capture. It is also used to
+ * identify the request in asynchronous notifications sent to
+ * camera3_callback_ops_t.notify().
+ */
+ uint32_t frame_number;
+
+ /**
+ * The result metadata for this capture. This contains information about the
+ * final capture parameters, the state of the capture and post-processing
+ * hardware, the state of the 3A algorithms, if enabled, and the output of
+ * any enabled statistics units.
+ *
+ * Only one call to process_capture_result() with a given frame_number may
+ * include the result metadata. All other calls for the same frame_number
+ * must set this to NULL.
+ *
+ * If there was an error producing the result metadata, result must be an
+ * empty metadata buffer, and notify() must be called with ERROR_RESULT.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Multiple calls to process_capture_result() with a given frame_number
+ * may include the result metadata.
+ *
+ * Partial metadata submitted should not include any metadata key returned
+ * in a previous partial result for a given frame. Each new partial result
+ * for that frame must also set a distinct partial_result value.
+ *
+ * If notify has been called with ERROR_RESULT, all further partial
+ * results for that frame are ignored by the framework.
+ */
+ const camera_metadata_t *result;
+
+ /**
+ * The number of output buffers returned in this result structure. Must be
+ * less than or equal to the matching capture request's count. If this is
+ * less than the buffer count in the capture request, at least one more call
+ * to process_capture_result with the same frame_number must be made, to
+ * return the remaining output buffers to the framework. This may only be
+ * zero if the structure includes valid result metadata or an input buffer
+ * is returned in this result.
+ */
+ uint32_t num_output_buffers;
+
+ /**
+ * The handles for the output stream buffers for this capture. They may not
+ * yet be filled at the time the HAL calls process_capture_result(); the
+ * framework will wait on the release sync fences provided by the HAL before
+ * reading the buffers.
+ *
+ * The HAL must set the stream buffer's release sync fence to a valid sync
+ * fd, or to -1 if the buffer has already been filled.
+ *
+ * If the HAL encounters an error while processing the buffer, and the
+ * buffer is not filled, the buffer's status field must be set to
+ * CAMERA3_BUFFER_STATUS_ERROR. If the HAL did not wait on the acquire fence
+ * before encountering the error, the acquire fence should be copied into
+ * the release fence, to allow the framework to wait on the fence before
+ * reusing the buffer.
+ *
+ * The acquire fence must be set to -1 for all output buffers. If
+ * num_output_buffers is zero, this may be NULL. In that case, at least one
+ * more process_capture_result call must be made by the HAL to provide the
+ * output buffers.
+ *
+ * When process_capture_result is called with a new buffer for a frame,
+ * all previous frames' buffers for that corresponding stream must have been
+ * already delivered (the fences need not have yet been signaled).
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Gralloc buffers for a frame may be sent to framework before the
+ * corresponding SHUTTER-notify.
+ *
+ * Performance considerations:
+ *
+ * Buffers delivered to the framework will not be dispatched to the
+ * application layer until a start of exposure timestamp has been received
+ * via a SHUTTER notify() call. It is highly recommended to
+ * dispatch that call as early as possible.
+ */
+ const camera3_stream_buffer_t *output_buffers;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * The handle for the input stream buffer for this capture. It may not
+ * yet be consumed at the time the HAL calls process_capture_result(); the
+ * framework will wait on the release sync fences provided by the HAL before
+ * reusing the buffer.
+ *
+ * The HAL should handle the sync fences the same way they are done for
+ * output_buffers.
+ *
+ * Only one input buffer is allowed to be sent per request. Similarly to
+ * output buffers, the ordering of returned input buffers must be
+ * maintained by the HAL.
+ *
+ * Performance considerations:
+ *
+ * The input buffer should be returned as early as possible. If the HAL
+ * supports sync fences, it can call process_capture_result to hand it back
+ * with sync fences being set appropriately. If the sync fences are not
+ * supported, the buffer can only be returned when it is consumed, which
+ * may take long time; the HAL may choose to copy this input buffer to make
+ * the buffer return sooner.
+ */
+ const camera3_stream_buffer_t *input_buffer;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * In order to take advantage of partial results, the HAL must set the
+ * static metadata android.request.partialResultCount to the number of
+ * partial results it will send for each frame.
+ *
+ * Each new capture result with a partial result must set
+ * this field (partial_result) to a distinct inclusive value between
+ * 1 and android.request.partialResultCount.
+ *
+ * HALs not wishing to take advantage of this feature must not
+ * set an android.request.partialResultCount or partial_result to a value
+ * other than 1.
+ *
+ * This value must be set to 0 when a capture result contains buffers only
+ * and no metadata.
+ */
+ uint32_t partial_result;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ *
+ * Specifies the number of physical camera metadata this capture result
+ * contains. It must be equal to the number of physical cameras being
+ * requested from.
+ *
+ * If the current camera device is not a logical multi-camera, or the
+ * corresponding capture_request doesn't request on any physical camera,
+ * this field must be 0.
+ */
+ uint32_t num_physcam_metadata;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ *
+ * An array of strings containing the physical camera ids for the returned
+ * physical camera metadata. The length of the array is
+ * num_physcam_metadata.
+ */
+ const char **physcam_ids;
+
+ /**
+ * >= CAMERA_DEVICE_API_VERSION_3_5:
+ *
+ * The array of physical camera metadata for the physical cameras being
+ * requested upon. This array should have a 1-to-1 mapping with the
+ * physcam_ids. The length of the array is num_physcam_metadata.
+ */
+ const camera_metadata_t **physcam_metadata;
+
+} camera3_capture_result_t;
+
+/**********************************************************************
+ *
+ * Callback methods for the HAL to call into the framework.
+ *
+ * These methods are used to return metadata and image buffers for a completed
+ * or failed captures, and to notify the framework of asynchronous events such
+ * as errors.
+ *
+ * The framework will not call back into the HAL from within these callbacks,
+ * and these calls will not block for extended periods.
+ *
+ */
+typedef struct camera3_callback_ops {
+
+ /**
+ * process_capture_result:
+ *
+ * Send results from a completed capture to the framework.
+ * process_capture_result() may be invoked multiple times by the HAL in
+ * response to a single capture request. This allows, for example, the
+ * metadata and low-resolution buffers to be returned in one call, and
+ * post-processed JPEG buffers in a later call, once it is available. Each
+ * call must include the frame number of the request it is returning
+ * metadata or buffers for.
+ *
+ * A component (buffer or metadata) of the complete result may only be
+ * included in one process_capture_result call. A buffer for each stream,
+ * and the result metadata, must be returned by the HAL for each request in
+ * one of the process_capture_result calls, even in case of errors producing
+ * some of the output. A call to process_capture_result() with neither
+ * output buffers or result metadata is not allowed.
+ *
+ * The order of returning metadata and buffers for a single result does not
+ * matter, but buffers for a given stream must be returned in FIFO order. So
+ * the buffer for request 5 for stream A must always be returned before the
+ * buffer for request 6 for stream A. This also applies to the result
+ * metadata; the metadata for request 5 must be returned before the metadata
+ * for request 6.
+ *
+ * However, different streams are independent of each other, so it is
+ * acceptable and expected that the buffer for request 5 for stream A may be
+ * returned after the buffer for request 6 for stream B is. And it is
+ * acceptable that the result metadata for request 6 for stream B is
+ * returned before the buffer for request 5 for stream A is.
+ *
+ * The HAL retains ownership of result structure, which only needs to be
+ * valid to access during this call. The framework will copy whatever it
+ * needs before this call returns.
+ *
+ * The output buffers do not need to be filled yet; the framework will wait
+ * on the stream buffer release sync fence before reading the buffer
+ * data. Therefore, this method should be called by the HAL as soon as
+ * possible, even if some or all of the output buffers are still in
+ * being filled. The HAL must include valid release sync fences into each
+ * output_buffers stream buffer entry, or -1 if that stream buffer is
+ * already filled.
+ *
+ * If the result buffer cannot be constructed for a request, the HAL should
+ * return an empty metadata buffer, but still provide the output buffers and
+ * their sync fences. In addition, notify() must be called with an
+ * ERROR_RESULT message.
+ *
+ * If an output buffer cannot be filled, its status field must be set to
+ * STATUS_ERROR. In addition, notify() must be called with a ERROR_BUFFER
+ * message.
+ *
+ * If the entire capture has failed, then this method still needs to be
+ * called to return the output buffers to the framework. All the buffer
+ * statuses should be STATUS_ERROR, and the result metadata should be an
+ * empty buffer. In addition, notify() must be called with a ERROR_REQUEST
+ * message. In this case, individual ERROR_RESULT/ERROR_BUFFER messages
+ * should not be sent.
+ *
+ * Performance requirements:
+ *
+ * This is a non-blocking call. The framework will return this call in 5ms.
+ *
+ * The pipeline latency (see S7 for definition) should be less than or equal to
+ * 4 frame intervals, and must be less than or equal to 8 frame intervals.
+ *
+ */
+ void (*process_capture_result)(const struct camera3_callback_ops *,
+ const camera3_capture_result_t *result);
+
+ /**
+ * notify:
+ *
+ * Asynchronous notification callback from the HAL, fired for various
+ * reasons. Only for information independent of frame capture, or that
+ * require specific timing. The ownership of the message structure remains
+ * with the HAL, and the msg only needs to be valid for the duration of this
+ * call.
+ *
+ * Multiple threads may call notify() simultaneously.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * The notification for the start of exposure for a given request must be
+ * sent by the HAL before the first call to process_capture_result() for
+ * that request is made.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Buffers delivered to the framework will not be dispatched to the
+ * application layer until a start of exposure timestamp (or input image's
+ * start of exposure timestamp for a reprocess request) has been received
+ * via a SHUTTER notify() call. It is highly recommended to dispatch this
+ * call as early as possible.
+ *
+ * ------------------------------------------------------------------------
+ * Performance requirements:
+ *
+ * This is a non-blocking call. The framework will return this call in 5ms.
+ */
+ void (*notify)(const struct camera3_callback_ops *,
+ const camera3_notify_msg_t *msg);
+
+ /**
+ * request_stream_buffers:
+ *
+ * <= CAMERA_DEVICE_API_VERISON_3_5:
+ *
+ * DO NOT USE: not defined and must be NULL.
+ *
+ * >= CAMERA_DEVICE_API_VERISON_3_6:
+ *
+ * Synchronous callback for HAL to ask for output buffer from camera service.
+ *
+ * This call may be serialized in camera service so it is strongly
+ * recommended to only call this method from one thread.
+ *
+ * When camera device advertises
+ * (android.info.supportedBufferManagementVersion ==
+ * ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION_HIDL_DEVICE_3_5), HAL
+ * can use this method to request buffers from camera service.
+ *
+ * Caller is responsible for allocating enough memory for returned_buf_reqs
+ * argument (num_buffer_reqs * sizeof(camera3_stream_buffer_ret_t)) bytes
+ * and also the memory for the output_buffers field in each
+ * camera3_stream_buffer_ret_t
+ * (num_buffers_requested * sizeof(camera3_stream_buffer_t)) bytes
+ *
+ * Performance requirements:
+ * This is a blocking call that takes more time with more buffers requested.
+ * HAL should not request large amount of buffers on a latency critical code
+ * path. It is highly recommended to use a dedicated thread to perform
+ * all requestStreamBuffer calls, and adjust the thread priority and/or
+ * timing of making the call in order for buffers to arrive before HAL is
+ * ready to fill the buffer.
+ */
+ camera3_buffer_request_status_t (*request_stream_buffers)(
+ const struct camera3_callback_ops *,
+ uint32_t num_buffer_reqs,
+ const camera3_buffer_request_t *buffer_reqs,
+ /*out*/uint32_t *num_returned_buf_reqs,
+ /*out*/camera3_stream_buffer_ret_t *returned_buf_reqs);
+
+ /**
+ * return_stream_buffers:
+ *
+ * <= CAMERA_DEVICE_API_VERISON_3_5:
+ *
+ * DO NOT USE: not defined and must be NULL.
+ *
+ * >= CAMERA_DEVICE_API_VERISON_3_6:
+ *
+ * Synchronous callback for HAL to return output buffers to camera service.
+ *
+ * If this method is called during a configure_streams() call, it will be
+ * blocked until camera service finishes the ongoing configure_streams() call.
+ */
+ void (*return_stream_buffers)(
+ const struct camera3_callback_ops *,
+ uint32_t num_buffers,
+ const camera3_stream_buffer_t* const* buffers);
+
+} camera3_callback_ops_t;
+
+/**********************************************************************
+ *
+ * Camera device operations
+ *
+ */
+typedef struct camera3_device_ops {
+
+ /**
+ * initialize:
+ *
+ * One-time initialization to pass framework callback function pointers to
+ * the HAL. Will be called once after a successful open() call, before any
+ * other functions are called on the camera3_device_ops structure.
+ *
+ * Performance requirements:
+ *
+ * This should be a non-blocking call. The HAL should return from this call
+ * in 5ms, and must return from this call in 10ms.
+ *
+ * Return values:
+ *
+ * 0: On successful initialization
+ *
+ * -ENODEV: If initialization fails. Only close() can be called successfully
+ * by the framework after this.
+ */
+ int (*initialize)(const struct camera3_device *,
+ const camera3_callback_ops_t *callback_ops);
+
+ /**********************************************************************
+ * Stream management
+ */
+
+ /**
+ * configure_streams:
+ *
+ * CAMERA_DEVICE_API_VERSION_3_0 only:
+ *
+ * Reset the HAL camera device processing pipeline and set up new input and
+ * output streams. This call replaces any existing stream configuration with
+ * the streams defined in the stream_list. This method will be called at
+ * least once after initialize() before a request is submitted with
+ * process_capture_request().
+ *
+ * The stream_list must contain at least one output-capable stream, and may
+ * not contain more than one input-capable stream.
+ *
+ * The stream_list may contain streams that are also in the currently-active
+ * set of streams (from the previous call to configure_stream()). These
+ * streams will already have valid values for usage, max_buffers, and the
+ * private pointer.
+ *
+ * If such a stream has already had its buffers registered,
+ * register_stream_buffers() will not be called again for the stream, and
+ * buffers from the stream can be immediately included in input requests.
+ *
+ * If the HAL needs to change the stream configuration for an existing
+ * stream due to the new configuration, it may rewrite the values of usage
+ * and/or max_buffers during the configure call.
+ *
+ * The framework will detect such a change, and will then reallocate the
+ * stream buffers, and call register_stream_buffers() again before using
+ * buffers from that stream in a request.
+ *
+ * If a currently-active stream is not included in stream_list, the HAL may
+ * safely remove any references to that stream. It will not be reused in a
+ * later configure() call by the framework, and all the gralloc buffers for
+ * it will be freed after the configure_streams() call returns.
+ *
+ * The stream_list structure is owned by the framework, and may not be
+ * accessed once this call completes. The address of an individual
+ * camera3_stream_t structure will remain valid for access by the HAL until
+ * the end of the first configure_stream() call which no longer includes
+ * that camera3_stream_t in the stream_list argument. The HAL may not change
+ * values in the stream structure outside of the private pointer, except for
+ * the usage and max_buffers members during the configure_streams() call
+ * itself.
+ *
+ * If the stream is new, the usage, max_buffer, and private pointer fields
+ * of the stream structure will all be set to 0. The HAL device must set
+ * these fields before the configure_streams() call returns. These fields
+ * are then used by the framework and the platform gralloc module to
+ * allocate the gralloc buffers for each stream.
+ *
+ * Before such a new stream can have its buffers included in a capture
+ * request, the framework will call register_stream_buffers() with that
+ * stream. However, the framework is not required to register buffers for
+ * _all_ streams before submitting a request. This allows for quick startup
+ * of (for example) a preview stream, with allocation for other streams
+ * happening later or concurrently.
+ *
+ * ------------------------------------------------------------------------
+ * CAMERA_DEVICE_API_VERSION_3_1 only:
+ *
+ * Reset the HAL camera device processing pipeline and set up new input and
+ * output streams. This call replaces any existing stream configuration with
+ * the streams defined in the stream_list. This method will be called at
+ * least once after initialize() before a request is submitted with
+ * process_capture_request().
+ *
+ * The stream_list must contain at least one output-capable stream, and may
+ * not contain more than one input-capable stream.
+ *
+ * The stream_list may contain streams that are also in the currently-active
+ * set of streams (from the previous call to configure_stream()). These
+ * streams will already have valid values for usage, max_buffers, and the
+ * private pointer.
+ *
+ * If such a stream has already had its buffers registered,
+ * register_stream_buffers() will not be called again for the stream, and
+ * buffers from the stream can be immediately included in input requests.
+ *
+ * If the HAL needs to change the stream configuration for an existing
+ * stream due to the new configuration, it may rewrite the values of usage
+ * and/or max_buffers during the configure call.
+ *
+ * The framework will detect such a change, and will then reallocate the
+ * stream buffers, and call register_stream_buffers() again before using
+ * buffers from that stream in a request.
+ *
+ * If a currently-active stream is not included in stream_list, the HAL may
+ * safely remove any references to that stream. It will not be reused in a
+ * later configure() call by the framework, and all the gralloc buffers for
+ * it will be freed after the configure_streams() call returns.
+ *
+ * The stream_list structure is owned by the framework, and may not be
+ * accessed once this call completes. The address of an individual
+ * camera3_stream_t structure will remain valid for access by the HAL until
+ * the end of the first configure_stream() call which no longer includes
+ * that camera3_stream_t in the stream_list argument. The HAL may not change
+ * values in the stream structure outside of the private pointer, except for
+ * the usage and max_buffers members during the configure_streams() call
+ * itself.
+ *
+ * If the stream is new, max_buffer, and private pointer fields of the
+ * stream structure will all be set to 0. The usage will be set to the
+ * consumer usage flags. The HAL device must set these fields before the
+ * configure_streams() call returns. These fields are then used by the
+ * framework and the platform gralloc module to allocate the gralloc
+ * buffers for each stream.
+ *
+ * Before such a new stream can have its buffers included in a capture
+ * request, the framework will call register_stream_buffers() with that
+ * stream. However, the framework is not required to register buffers for
+ * _all_ streams before submitting a request. This allows for quick startup
+ * of (for example) a preview stream, with allocation for other streams
+ * happening later or concurrently.
+ *
+ * ------------------------------------------------------------------------
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * Reset the HAL camera device processing pipeline and set up new input and
+ * output streams. This call replaces any existing stream configuration with
+ * the streams defined in the stream_list. This method will be called at
+ * least once after initialize() before a request is submitted with
+ * process_capture_request().
+ *
+ * The stream_list must contain at least one output-capable stream, and may
+ * not contain more than one input-capable stream.
+ *
+ * The stream_list may contain streams that are also in the currently-active
+ * set of streams (from the previous call to configure_stream()). These
+ * streams will already have valid values for usage, max_buffers, and the
+ * private pointer.
+ *
+ * If the HAL needs to change the stream configuration for an existing
+ * stream due to the new configuration, it may rewrite the values of usage
+ * and/or max_buffers during the configure call.
+ *
+ * The framework will detect such a change, and may then reallocate the
+ * stream buffers before using buffers from that stream in a request.
+ *
+ * If a currently-active stream is not included in stream_list, the HAL may
+ * safely remove any references to that stream. It will not be reused in a
+ * later configure() call by the framework, and all the gralloc buffers for
+ * it will be freed after the configure_streams() call returns.
+ *
+ * The stream_list structure is owned by the framework, and may not be
+ * accessed once this call completes. The address of an individual
+ * camera3_stream_t structure will remain valid for access by the HAL until
+ * the end of the first configure_stream() call which no longer includes
+ * that camera3_stream_t in the stream_list argument. The HAL may not change
+ * values in the stream structure outside of the private pointer, except for
+ * the usage and max_buffers members during the configure_streams() call
+ * itself.
+ *
+ * If the stream is new, max_buffer, and private pointer fields of the
+ * stream structure will all be set to 0. The usage will be set to the
+ * consumer usage flags. The HAL device must set these fields before the
+ * configure_streams() call returns. These fields are then used by the
+ * framework and the platform gralloc module to allocate the gralloc
+ * buffers for each stream.
+ *
+ * Newly allocated buffers may be included in a capture request at any time
+ * by the framework. Once a gralloc buffer is returned to the framework
+ * with process_capture_result (and its respective release_fence has been
+ * signaled) the framework may free or reuse it at any time.
+ *
+ * ------------------------------------------------------------------------
+ *
+ * Preconditions:
+ *
+ * The framework will only call this method when no captures are being
+ * processed. That is, all results have been returned to the framework, and
+ * all in-flight input and output buffers have been returned and their
+ * release sync fences have been signaled by the HAL. The framework will not
+ * submit new requests for capture while the configure_streams() call is
+ * underway.
+ *
+ * Postconditions:
+ *
+ * The HAL device must configure itself to provide maximum possible output
+ * frame rate given the sizes and formats of the output streams, as
+ * documented in the camera device's static metadata.
+ *
+ * Performance requirements:
+ *
+ * This call is expected to be heavyweight and possibly take several hundred
+ * milliseconds to complete, since it may require resetting and
+ * reconfiguring the image sensor and the camera processing pipeline.
+ * Nevertheless, the HAL device should attempt to minimize the
+ * reconfiguration delay to minimize the user-visible pauses during
+ * application operational mode changes (such as switching from still
+ * capture to video recording).
+ *
+ * The HAL should return from this call in 500ms, and must return from this
+ * call in 1000ms.
+ *
+ * Return values:
+ *
+ * 0: On successful stream configuration
+ *
+ * -EINVAL: If the requested stream configuration is invalid. Some examples
+ * of invalid stream configurations include:
+ *
+ * - Including more than 1 input-capable stream (INPUT or
+ * BIDIRECTIONAL)
+ *
+ * - Not including any output-capable streams (OUTPUT or
+ * BIDIRECTIONAL)
+ *
+ * - Including streams with unsupported formats, or an unsupported
+ * size for that format.
+ *
+ * - Including too many output streams of a certain format.
+ *
+ * - Unsupported rotation configuration (only applies to
+ * devices with version >= CAMERA_DEVICE_API_VERSION_3_3)
+ *
+ * - Stream sizes/formats don't satisfy the
+ * camera3_stream_configuration_t->operation_mode requirements for non-NORMAL mode,
+ * or the requested operation_mode is not supported by the HAL.
+ * (only applies to devices with version >= CAMERA_DEVICE_API_VERSION_3_3)
+ *
+ * Note that the framework submitting an invalid stream
+ * configuration is not normal operation, since stream
+ * configurations are checked before configure. An invalid
+ * configuration means that a bug exists in the framework code, or
+ * there is a mismatch between the HAL's static metadata and the
+ * requirements on streams.
+ *
+ * -ENODEV: If there has been a fatal error and the device is no longer
+ * operational. Only close() can be called successfully by the
+ * framework after this error is returned.
+ */
+ int (*configure_streams)(const struct camera3_device *,
+ camera3_stream_configuration_t *stream_list);
+
+ /**
+ * register_stream_buffers:
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * DEPRECATED. This will not be called and must be set to NULL.
+ *
+ * <= CAMERA_DEVICE_API_VERSION_3_1:
+ *
+ * Register buffers for a given stream with the HAL device. This method is
+ * called by the framework after a new stream is defined by
+ * configure_streams, and before buffers from that stream are included in a
+ * capture request. If the same stream is listed in a subsequent
+ * configure_streams() call, register_stream_buffers will _not_ be called
+ * again for that stream.
+ *
+ * The framework does not need to register buffers for all configured
+ * streams before it submits the first capture request. This allows quick
+ * startup for preview (or similar use cases) while other streams are still
+ * being allocated.
+ *
+ * This method is intended to allow the HAL device to map or otherwise
+ * prepare the buffers for later use. The buffers passed in will already be
+ * locked for use. At the end of the call, all the buffers must be ready to
+ * be returned to the stream. The buffer_set argument is only valid for the
+ * duration of this call.
+ *
+ * If the stream format was set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,
+ * the camera HAL should inspect the passed-in buffers here to determine any
+ * platform-private pixel format information.
+ *
+ * Performance requirements:
+ *
+ * This should be a non-blocking call. The HAL should return from this call
+ * in 1ms, and must return from this call in 5ms.
+ *
+ * Return values:
+ *
+ * 0: On successful registration of the new stream buffers
+ *
+ * -EINVAL: If the stream_buffer_set does not refer to a valid active
+ * stream, or if the buffers array is invalid.
+ *
+ * -ENOMEM: If there was a failure in registering the buffers. The framework
+ * must consider all the stream buffers to be unregistered, and can
+ * try to register again later.
+ *
+ * -ENODEV: If there is a fatal error, and the device is no longer
+ * operational. Only close() can be called successfully by the
+ * framework after this error is returned.
+ */
+ int (*register_stream_buffers)(const struct camera3_device *,
+ const camera3_stream_buffer_set_t *buffer_set);
+
+ /**********************************************************************
+ * Request creation and submission
+ */
+
+ /**
+ * construct_default_request_settings:
+ *
+ * Create capture settings for standard camera use cases.
+ *
+ * The device must return a settings buffer that is configured to meet the
+ * requested use case, which must be one of the CAMERA3_TEMPLATE_*
+ * enums. All request control fields must be included.
+ *
+ * The HAL retains ownership of this structure, but the pointer to the
+ * structure must be valid until the device is closed. The framework and the
+ * HAL may not modify the buffer once it is returned by this call. The same
+ * buffer may be returned for subsequent calls for the same template, or for
+ * other templates.
+ *
+ * Performance requirements:
+ *
+ * This should be a non-blocking call. The HAL should return from this call
+ * in 1ms, and must return from this call in 5ms.
+ *
+ * Return values:
+ *
+ * Valid metadata: On successful creation of a default settings
+ * buffer.
+ *
+ * NULL: In case of a fatal error. After this is returned, only
+ * the close() method can be called successfully by the
+ * framework.
+ */
+ const camera_metadata_t* (*construct_default_request_settings)(
+ const struct camera3_device *,
+ int type);
+
+ /**
+ * process_capture_request:
+ *
+ * Send a new capture request to the HAL. The HAL should not return from
+ * this call until it is ready to accept the next request to process. Only
+ * one call to process_capture_request() will be made at a time by the
+ * framework, and the calls will all be from the same thread. The next call
+ * to process_capture_request() will be made as soon as a new request and
+ * its associated buffers are available. In a normal preview scenario, this
+ * means the function will be called again by the framework almost
+ * instantly.
+ *
+ * The actual request processing is asynchronous, with the results of
+ * capture being returned by the HAL through the process_capture_result()
+ * call. This call requires the result metadata to be available, but output
+ * buffers may simply provide sync fences to wait on. Multiple requests are
+ * expected to be in flight at once, to maintain full output frame rate.
+ *
+ * The framework retains ownership of the request structure. It is only
+ * guaranteed to be valid during this call. The HAL device must make copies
+ * of the information it needs to retain for the capture processing. The HAL
+ * is responsible for waiting on and closing the buffers' fences and
+ * returning the buffer handles to the framework.
+ *
+ * The HAL must write the file descriptor for the input buffer's release
+ * sync fence into input_buffer->release_fence, if input_buffer is not
+ * NULL. If the HAL returns -1 for the input buffer release sync fence, the
+ * framework is free to immediately reuse the input buffer. Otherwise, the
+ * framework will wait on the sync fence before refilling and reusing the
+ * input buffer.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ *
+ * The input/output buffers provided by the framework in each request
+ * may be brand new (having never before seen by the HAL).
+ *
+ * ------------------------------------------------------------------------
+ * Performance considerations:
+ *
+ * Handling a new buffer should be extremely lightweight and there should be
+ * no frame rate degradation or frame jitter introduced.
+ *
+ * This call must return fast enough to ensure that the requested frame
+ * rate can be sustained, especially for streaming cases (post-processing
+ * quality settings set to FAST). The HAL should return this call in 1
+ * frame interval, and must return from this call in 4 frame intervals.
+ *
+ * Return values:
+ *
+ * 0: On a successful start to processing the capture request
+ *
+ * -EINVAL: If the input is malformed (the settings are NULL when not
+ * allowed, invalid physical camera settings,
+ * there are 0 output buffers, etc) and capture processing
+ * cannot start. Failures during request processing should be
+ * handled by calling camera3_callback_ops_t.notify(). In case of
+ * this error, the framework will retain responsibility for the
+ * stream buffers' fences and the buffer handles; the HAL should
+ * not close the fences or return these buffers with
+ * process_capture_result.
+ *
+ * -ENODEV: If the camera device has encountered a serious error. After this
+ * error is returned, only the close() method can be successfully
+ * called by the framework.
+ *
+ */
+ int (*process_capture_request)(const struct camera3_device *,
+ camera3_capture_request_t *request);
+
+ /**********************************************************************
+ * Miscellaneous methods
+ */
+
+ /**
+ * get_metadata_vendor_tag_ops:
+ *
+ * Get methods to query for vendor extension metadata tag information. The
+ * HAL should fill in all the vendor tag operation methods, or leave ops
+ * unchanged if no vendor tags are defined.
+ *
+ * The definition of vendor_tag_query_ops_t can be found in
+ * system/media/camera/include/system/camera_metadata.h.
+ *
+ * >= CAMERA_DEVICE_API_VERSION_3_2:
+ * DEPRECATED. This function has been deprecated and should be set to
+ * NULL by the HAL. Please implement get_vendor_tag_ops in camera_common.h
+ * instead.
+ */
+ void (*get_metadata_vendor_tag_ops)(const struct camera3_device*,
+ vendor_tag_query_ops_t* ops);
+
+ /**
+ * dump:
+ *
+ * Print out debugging state for the camera device. This will be called by
+ * the framework when the camera service is asked for a debug dump, which
+ * happens when using the dumpsys tool, or when capturing a bugreport.
+ *
+ * The passed-in file descriptor can be used to write debugging text using
+ * dprintf() or write(). The text should be in ASCII encoding only.
+ *
+ * Performance requirements:
+ *
+ * This must be a non-blocking call. The HAL should return from this call
+ * in 1ms, must return from this call in 10ms. This call must avoid
+ * deadlocks, as it may be called at any point during camera operation.
+ * Any synchronization primitives used (such as mutex locks or semaphores)
+ * should be acquired with a timeout.
+ */
+ void (*dump)(const struct camera3_device *, int fd);
+
+ /**
+ * flush:
+ *
+ * Flush all currently in-process captures and all buffers in the pipeline
+ * on the given device. The framework will use this to dump all state as
+ * quickly as possible in order to prepare for a configure_streams() call.
+ *
+ * No buffers are required to be successfully returned, so every buffer
+ * held at the time of flush() (whether successfully filled or not) may be
+ * returned with CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed
+ * to return valid (CAMERA3_BUFFER_STATUS_OK) buffers during this call,
+ * provided they are successfully filled.
+ *
+ * All requests currently in the HAL are expected to be returned as soon as
+ * possible. Not-in-process requests should return errors immediately. Any
+ * interruptible hardware blocks should be stopped, and any uninterruptible
+ * blocks should be waited on.
+ *
+ * flush() may be called concurrently to process_capture_request(), with the expectation that
+ * process_capture_request will return quickly and the request submitted in that
+ * process_capture_request call is treated like all other in-flight requests. Due to
+ * concurrency issues, it is possible that from the HAL's point of view, a
+ * process_capture_request() call may be started after flush has been invoked but has not
+ * returned yet. If such a call happens before flush() returns, the HAL should treat the new
+ * capture request like other in-flight pending requests (see #4 below).
+ *
+ * More specifically, the HAL must follow below requirements for various cases:
+ *
+ * 1. For captures that are too late for the HAL to cancel/stop, and will be
+ * completed normally by the HAL; i.e. the HAL can send shutter/notify and
+ * process_capture_result and buffers as normal.
+ *
+ * 2. For pending requests that have not done any processing, the HAL must call notify
+ * CAMERA3_MSG_ERROR_REQUEST, and return all the output buffers with
+ * process_capture_result in the error state (CAMERA3_BUFFER_STATUS_ERROR).
+ * The HAL must not place the release fence into an error state, instead,
+ * the release fences must be set to the acquire fences passed by the framework,
+ * or -1 if they have been waited on by the HAL already. This is also the path
+ * to follow for any captures for which the HAL already called notify() with
+ * CAMERA3_MSG_SHUTTER but won't be producing any metadata/valid buffers for.
+ * After CAMERA3_MSG_ERROR_REQUEST, for a given frame, only process_capture_results with
+ * buffers in CAMERA3_BUFFER_STATUS_ERROR are allowed. No further notifys or
+ * process_capture_result with non-null metadata is allowed.
+ *
+ * 3. For partially completed pending requests that will not have all the output
+ * buffers or perhaps missing metadata, the HAL should follow below:
+ *
+ * 3.1. Call notify with CAMERA3_MSG_ERROR_RESULT if some of the expected result
+ * metadata (i.e. one or more partial metadata) won't be available for the capture.
+ *
+ * 3.2. Call notify with CAMERA3_MSG_ERROR_BUFFER for every buffer that won't
+ * be produced for the capture.
+ *
+ * 3.3 Call notify with CAMERA3_MSG_SHUTTER with the capture timestamp before
+ * any buffers/metadata are returned with process_capture_result.
+ *
+ * 3.4 For captures that will produce some results, the HAL must not call
+ * CAMERA3_MSG_ERROR_REQUEST, since that indicates complete failure.
+ *
+ * 3.5. Valid buffers/metadata should be passed to the framework as normal.
+ *
+ * 3.6. Failed buffers should be returned to the framework as described for case 2.
+ * But failed buffers do not have to follow the strict ordering valid buffers do,
+ * and may be out-of-order with respect to valid buffers. For example, if buffers
+ * A, B, C, D, E are sent, D and E are failed, then A, E, B, D, C is an acceptable
+ * return order.
+ *
+ * 3.7. For fully-missing metadata, calling CAMERA3_MSG_ERROR_RESULT is sufficient, no
+ * need to call process_capture_result with NULL metadata or equivalent.
+ *
+ * 4. If a flush() is invoked while a process_capture_request() invocation is active, that
+ * process call should return as soon as possible. In addition, if a process_capture_request()
+ * call is made after flush() has been invoked but before flush() has returned, the
+ * capture request provided by the late process_capture_request call should be treated like
+ * a pending request in case #2 above.
+ *
+ * flush() should only return when there are no more outstanding buffers or
+ * requests left in the HAL. The framework may call configure_streams (as
+ * the HAL state is now quiesced) or may issue new requests.
+ *
+ * Note that it's sufficient to only support fully-succeeded and fully-failed result cases.
+ * However, it is highly desirable to support the partial failure cases as well, as it
+ * could help improve the flush call overall performance.
+ *
+ * Performance requirements:
+ *
+ * The HAL should return from this call in 100ms, and must return from this
+ * call in 1000ms. And this call must not be blocked longer than pipeline
+ * latency (see S7 for definition).
+ *
+ * Version information:
+ *
+ * only available if device version >= CAMERA_DEVICE_API_VERSION_3_1.
+ *
+ * Return values:
+ *
+ * 0: On a successful flush of the camera HAL.
+ *
+ * -EINVAL: If the input is malformed (the device is not valid).
+ *
+ * -ENODEV: If the camera device has encountered a serious error. After this
+ * error is returned, only the close() method can be successfully
+ * called by the framework.
+ */
+ int (*flush)(const struct camera3_device *);
+
+ /**
+ * signal_stream_flush:
+ *
+ * <= CAMERA_DEVICE_API_VERISON_3_5:
+ *
+ * Not defined and must be NULL
+ *
+ * >= CAMERA_DEVICE_API_VERISON_3_6:
+ *
+ * Signaling HAL camera service is about to perform configure_streams() call
+ * and HAL must return all buffers of designated streams. HAL must finish
+ * inflight requests normally and return all buffers belonging to the
+ * designated streams through process_capture_result() or
+ * return_stream_buffers() API in a timely manner, or camera service will run
+ * into a fatal error.
+ *
+ * Note that this call serves as an optional hint and camera service may
+ * skip calling this if all buffers are already returned.
+ *
+ */
+ void (*signal_stream_flush)(const struct camera3_device*,
+ uint32_t num_streams,
+ const camera3_stream_t* const* streams);
+
+ /**
+ * is_reconfiguration_required:
+ *
+ * <= CAMERA_DEVICE_API_VERISON_3_5:
+ *
+ * Not defined and must be NULL
+ *
+ * >= CAMERA_DEVICE_API_VERISON_3_6:
+ *
+ * Check whether complete stream reconfiguration is required for possible new session
+ * parameter values.
+ *
+ * This method must be called by the camera framework in case the client changes
+ * the value of any advertised session parameters. Depending on the specific values
+ * the HAL can decide whether a complete stream reconfiguration is required. In case
+ * the HAL returns -ENVAL, the camera framework must skip the internal reconfiguration.
+ * In case Hal returns 0, the framework must reconfigure the streams and pass the
+ * new session parameter values accordingly.
+ * This call may be done by the framework some time before the request with new parameters
+ * is submitted to the HAL, and the request may be cancelled before it ever gets submitted.
+ * Therefore, the HAL must not use this query as an indication to change its behavior in any
+ * way.
+ * ------------------------------------------------------------------------
+ *
+ * Preconditions:
+ *
+ * The framework can call this method at any time after active
+ * session configuration. There must be no impact on the performance of
+ * pending camera requests in any way. In particular there must not be
+ * any glitches or delays during normal camera streaming.
+ *
+ * Performance requirements:
+ * HW and SW camera settings must not be changed and there must not be
+ * a user-visible impact on camera performance.
+ *
+ * @param oldSessionParams The currently applied session parameters.
+ * @param newSessionParams The new session parameters set by client.
+ *
+ * @return Status Status code for the operation, one of:
+ * 0: In case the stream reconfiguration is required
+ *
+ * -EINVAL: In case the stream reconfiguration is not required.
+ *
+ * -ENOSYS: In case the camera device does not support the
+ * reconfiguration query.
+ */
+ int (*is_reconfiguration_required)(const struct camera3_device*,
+ const camera_metadata_t* old_session_params,
+ const camera_metadata_t* new_session_params);
+
+ /* reserved for future use */
+ void *reserved[6];
+} camera3_device_ops_t;
+
+/**********************************************************************
+ *
+ * Camera device definition
+ *
+ */
+typedef struct camera3_device {
+ /**
+ * common.version must equal CAMERA_DEVICE_API_VERSION_3_0 to identify this
+ * device as implementing version 3.0 of the camera device HAL.
+ *
+ * Performance requirements:
+ *
+ * Camera open (common.module->common.methods->open) should return in 200ms, and must return
+ * in 500ms.
+ * Camera close (common.close) should return in 200ms, and must return in 500ms.
+ *
+ */
+ hw_device_t common;
+ camera3_device_ops_t *ops;
+ void *priv;
+} camera3_device_t;
+
+__END_DECLS
+
+#endif /* #ifdef ANDROID_INCLUDE_CAMERA3_H */
--- /dev/null
+/*
+ * Copyright (C) 2012 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+// FIXME: add well-defined names for cameras
+
+#ifndef ANDROID_INCLUDE_CAMERA_COMMON_H
+#define ANDROID_INCLUDE_CAMERA_COMMON_H
+
+#include <stdint.h>
+#include <stdbool.h>
+#include <sys/cdefs.h>
+#include <sys/types.h>
+#include <cutils/native_handle.h>
+#include <system/camera.h>
+#include <system/camera_vendor_tags.h>
+#include <hardware/hardware.h>
+#include <hardware/gralloc.h>
+
+__BEGIN_DECLS
+
+/**
+ * The id of this module
+ */
+#define CAMERA_HARDWARE_MODULE_ID "camera"
+
+/**
+ * Module versioning information for the Camera hardware module, based on
+ * camera_module_t.common.module_api_version. The two most significant hex
+ * digits represent the major version, and the two least significant represent
+ * the minor version.
+ *
+ *******************************************************************************
+ * Versions: 0.X - 1.X [CAMERA_MODULE_API_VERSION_1_0]
+ *
+ * Camera modules that report these version numbers implement the initial
+ * camera module HAL interface. All camera devices openable through this
+ * module support only version 1 of the camera device HAL. The device_version
+ * and static_camera_characteristics fields of camera_info are not valid. Only
+ * the android.hardware.Camera API can be supported by this module and its
+ * devices.
+ *
+ *******************************************************************************
+ * Version: 2.0 [CAMERA_MODULE_API_VERSION_2_0]
+ *
+ * Camera modules that report this version number implement the second version
+ * of the camera module HAL interface. Camera devices openable through this
+ * module may support either version 1.0 or version 2.0 of the camera device
+ * HAL interface. The device_version field of camera_info is always valid; the
+ * static_camera_characteristics field of camera_info is valid if the
+ * device_version field is 2.0 or higher.
+ *
+ *******************************************************************************
+ * Version: 2.1 [CAMERA_MODULE_API_VERSION_2_1]
+ *
+ * This camera module version adds support for asynchronous callbacks to the
+ * framework from the camera HAL module, which is used to notify the framework
+ * about changes to the camera module state. Modules that provide a valid
+ * set_callbacks() method must report at least this version number.
+ *
+ *******************************************************************************
+ * Version: 2.2 [CAMERA_MODULE_API_VERSION_2_2]
+ *
+ * This camera module version adds vendor tag support from the module, and
+ * deprecates the old vendor_tag_query_ops that were previously only
+ * accessible with a device open.
+ *
+ *******************************************************************************
+ * Version: 2.3 [CAMERA_MODULE_API_VERSION_2_3]
+ *
+ * This camera module version adds open legacy camera HAL device support.
+ * Framework can use it to open the camera device as lower device HAL version
+ * HAL device if the same device can support multiple device API versions.
+ * The standard hardware module open call (common.methods->open) continues
+ * to open the camera device with the latest supported version, which is
+ * also the version listed in camera_info_t.device_version.
+ *
+ *******************************************************************************
+ * Version: 2.4 [CAMERA_MODULE_API_VERSION_2_4]
+ *
+ * This camera module version adds below API changes:
+ *
+ * 1. Torch mode support. The framework can use it to turn on torch mode for
+ * any camera device that has a flash unit, without opening a camera device. The
+ * camera device has a higher priority accessing the flash unit than the camera
+ * module; opening a camera device will turn off the torch if it had been enabled
+ * through the module interface. When there are any resource conflicts, such as
+ * open() is called to open a camera device, the camera HAL module must notify the
+ * framework through the torch mode status callback that the torch mode has been
+ * turned off.
+ *
+ * 2. External camera (e.g. USB hot-plug camera) support. The API updates specify that
+ * the camera static info is only available when camera is connected and ready to
+ * use for external hot-plug cameras. Calls to get static info will be invalid
+ * calls when camera status is not CAMERA_DEVICE_STATUS_PRESENT. The frameworks
+ * will only count on device status change callbacks to manage the available external
+ * camera list.
+ *
+ * 3. Camera arbitration hints. This module version adds support for explicitly
+ * indicating the number of camera devices that can be simultaneously opened and used.
+ * To specify valid combinations of devices, the resource_cost and conflicting_devices
+ * fields should always be set in the camera_info structure returned by the
+ * get_camera_info call.
+ *
+ * 4. Module initialization method. This will be called by the camera service
+ * right after the HAL module is loaded, to allow for one-time initialization
+ * of the HAL. It is called before any other module methods are invoked.
+ *
+ *******************************************************************************
+ * Version: 2.5 [CAMERA_MODULE_API_VERSION_2_5]
+ *
+ * This camera module version adds below API changes:
+ *
+ * 1. Support to query characteristics of a non-standalone physical camera, which can
+ * only be accessed as part of a logical camera. It also adds camera stream combination
+ * query.
+ *
+ * 2. Ability to query whether a particular camera stream combination is
+ * supported by the camera device.
+ *
+ * 3. Device state change notification. This module version also supports
+ * notification about the overall device state change, such as
+ * folding/unfolding, or covering/uncovering of shutter.
+ */
+
+/**
+ * Predefined macros for currently-defined version numbers
+ */
+
+/**
+ * All module versions <= HARDWARE_MODULE_API_VERSION(1, 0xFF) must be treated
+ * as CAMERA_MODULE_API_VERSION_1_0
+ */
+#define CAMERA_MODULE_API_VERSION_1_0 HARDWARE_MODULE_API_VERSION(1, 0)
+#define CAMERA_MODULE_API_VERSION_2_0 HARDWARE_MODULE_API_VERSION(2, 0)
+#define CAMERA_MODULE_API_VERSION_2_1 HARDWARE_MODULE_API_VERSION(2, 1)
+#define CAMERA_MODULE_API_VERSION_2_2 HARDWARE_MODULE_API_VERSION(2, 2)
+#define CAMERA_MODULE_API_VERSION_2_3 HARDWARE_MODULE_API_VERSION(2, 3)
+#define CAMERA_MODULE_API_VERSION_2_4 HARDWARE_MODULE_API_VERSION(2, 4)
+#define CAMERA_MODULE_API_VERSION_2_5 HARDWARE_MODULE_API_VERSION(2, 5)
+
+#define CAMERA_MODULE_API_VERSION_CURRENT CAMERA_MODULE_API_VERSION_2_5
+
+/**
+ * All device versions <= HARDWARE_DEVICE_API_VERSION(1, 0xFF) must be treated
+ * as CAMERA_DEVICE_API_VERSION_1_0
+ */
+#define CAMERA_DEVICE_API_VERSION_1_0 HARDWARE_DEVICE_API_VERSION(1, 0) // DEPRECATED
+#define CAMERA_DEVICE_API_VERSION_2_0 HARDWARE_DEVICE_API_VERSION(2, 0) // NO LONGER SUPPORTED
+#define CAMERA_DEVICE_API_VERSION_2_1 HARDWARE_DEVICE_API_VERSION(2, 1) // NO LONGER SUPPORTED
+#define CAMERA_DEVICE_API_VERSION_3_0 HARDWARE_DEVICE_API_VERSION(3, 0) // NO LONGER SUPPORTED
+#define CAMERA_DEVICE_API_VERSION_3_1 HARDWARE_DEVICE_API_VERSION(3, 1) // NO LONGER SUPPORTED
+#define CAMERA_DEVICE_API_VERSION_3_2 HARDWARE_DEVICE_API_VERSION(3, 2)
+#define CAMERA_DEVICE_API_VERSION_3_3 HARDWARE_DEVICE_API_VERSION(3, 3)
+#define CAMERA_DEVICE_API_VERSION_3_4 HARDWARE_DEVICE_API_VERSION(3, 4)
+#define CAMERA_DEVICE_API_VERSION_3_5 HARDWARE_DEVICE_API_VERSION(3, 5)
+#define CAMERA_DEVICE_API_VERSION_3_6 HARDWARE_DEVICE_API_VERSION(3, 6)
+
+// Device version 3.5 is current, older HAL camera device versions are not
+// recommended for new devices.
+#define CAMERA_DEVICE_API_VERSION_CURRENT CAMERA_DEVICE_API_VERSION_3_5
+
+/**
+ * Defined in /system/media/camera/include/system/camera_metadata.h
+ */
+typedef struct camera_metadata camera_metadata_t;
+
+typedef struct camera_info {
+ /**
+ * The direction that the camera faces to. See system/core/include/system/camera.h
+ * for camera facing definitions.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * It should be CAMERA_FACING_BACK or CAMERA_FACING_FRONT.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * It should be CAMERA_FACING_BACK, CAMERA_FACING_FRONT or
+ * CAMERA_FACING_EXTERNAL.
+ */
+ int facing;
+
+ /**
+ * The orientation of the camera image. The value is the angle that the
+ * camera image needs to be rotated clockwise so it shows correctly on the
+ * display in its natural orientation. It should be 0, 90, 180, or 270.
+ *
+ * For example, suppose a device has a naturally tall screen. The
+ * back-facing camera sensor is mounted in landscape. You are looking at the
+ * screen. If the top side of the camera sensor is aligned with the right
+ * edge of the screen in natural orientation, the value should be 90. If the
+ * top side of a front-facing camera sensor is aligned with the right of the
+ * screen, the value should be 270.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * Valid in all camera_module versions.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * Valid if camera facing is CAMERA_FACING_BACK or CAMERA_FACING_FRONT,
+ * not valid if camera facing is CAMERA_FACING_EXTERNAL.
+ */
+ int orientation;
+
+ /**
+ * The value of camera_device_t.common.version.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_0:
+ *
+ * Not valid. Can be assumed to be CAMERA_DEVICE_API_VERSION_1_0. Do
+ * not read this field.
+ *
+ * CAMERA_MODULE_API_VERSION_2_0 or higher:
+ *
+ * Always valid
+ *
+ */
+ uint32_t device_version;
+
+ /**
+ * The camera's fixed characteristics, which include all static camera metadata
+ * specified in system/media/camera/docs/docs.html. This should be a sorted metadata
+ * buffer, and may not be modified or freed by the caller. The pointer should remain
+ * valid for the lifetime of the camera module, and values in it may not
+ * change after it is returned by get_camera_info().
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_0:
+ *
+ * Not valid. Extra characteristics are not available. Do not read this
+ * field.
+ *
+ * CAMERA_MODULE_API_VERSION_2_0 or higher:
+ *
+ * Valid if device_version >= CAMERA_DEVICE_API_VERSION_2_0. Do not read
+ * otherwise.
+ *
+ */
+ const camera_metadata_t *static_camera_characteristics;
+
+ /**
+ * The total resource "cost" of using this camera, represented as an integer
+ * value in the range [0, 100] where 100 represents total usage of the shared
+ * resource that is the limiting bottleneck of the camera subsystem. This may
+ * be a very rough estimate, and is used as a hint to the camera service to
+ * determine when to disallow multiple applications from simultaneously
+ * opening different cameras advertised by the camera service.
+ *
+ * The camera service must be able to simultaneously open and use any
+ * combination of camera devices exposed by the HAL where the sum of
+ * the resource costs of these cameras is <= 100. For determining cost,
+ * each camera device must be assumed to be configured and operating at
+ * the maximally resource-consuming framerate and stream size settings
+ * available in the configuration settings exposed for that device through
+ * the camera metadata.
+ *
+ * The camera service may still attempt to simultaneously open combinations
+ * of camera devices with a total resource cost > 100. This may succeed or
+ * fail. If this succeeds, combinations of configurations that are not
+ * supported due to resource constraints from having multiple open devices
+ * should fail during the configure calls. If the total resource cost is
+ * <= 100, open and configure should never fail for any stream configuration
+ * settings or other device capabilities that would normally succeed for a
+ * device when it is the only open camera device.
+ *
+ * This field will be used to determine whether background applications are
+ * allowed to use this camera device while other applications are using other
+ * camera devices. Note: multiple applications will never be allowed by the
+ * camera service to simultaneously open the same camera device.
+ *
+ * Example use cases:
+ *
+ * Ex. 1: Camera Device 0 = Back Camera
+ * Camera Device 1 = Front Camera
+ * - Using both camera devices causes a large framerate slowdown due to
+ * limited ISP bandwidth.
+ *
+ * Configuration:
+ *
+ * Camera Device 0 - resource_cost = 51
+ * conflicting_devices = null
+ * Camera Device 1 - resource_cost = 51
+ * conflicting_devices = null
+ *
+ * Result:
+ *
+ * Since the sum of the resource costs is > 100, if a higher-priority
+ * application has either device open, no lower-priority applications will be
+ * allowed by the camera service to open either device. If a lower-priority
+ * application is using a device that a higher-priority subsequently attempts
+ * to open, the lower-priority application will be forced to disconnect the
+ * the device.
+ *
+ * If the highest-priority application chooses, it may still attempt to open
+ * both devices (since these devices are not listed as conflicting in the
+ * conflicting_devices fields), but usage of these devices may fail in the
+ * open or configure calls.
+ *
+ * Ex. 2: Camera Device 0 = Left Back Camera
+ * Camera Device 1 = Right Back Camera
+ * Camera Device 2 = Combined stereo camera using both right and left
+ * back camera sensors used by devices 0, and 1
+ * Camera Device 3 = Front Camera
+ * - Due to do hardware constraints, up to two cameras may be open at once. The
+ * combined stereo camera may never be used at the same time as either of the
+ * two back camera devices (device 0, 1), and typically requires too much
+ * bandwidth to use at the same time as the front camera (device 3).
+ *
+ * Configuration:
+ *
+ * Camera Device 0 - resource_cost = 50
+ * conflicting_devices = { 2 }
+ * Camera Device 1 - resource_cost = 50
+ * conflicting_devices = { 2 }
+ * Camera Device 2 - resource_cost = 100
+ * conflicting_devices = { 0, 1 }
+ * Camera Device 3 - resource_cost = 50
+ * conflicting_devices = null
+ *
+ * Result:
+ *
+ * Based on the conflicting_devices fields, the camera service guarantees that
+ * the following sets of open devices will never be allowed: { 1, 2 }, { 0, 2 }.
+ *
+ * Based on the resource_cost fields, if a high-priority foreground application
+ * is using camera device 0, a background application would be allowed to open
+ * camera device 1 or 3 (but would be forced to disconnect it again if the
+ * foreground application opened another device).
+ *
+ * The highest priority application may still attempt to simultaneously open
+ * devices 0, 2, and 3, but the HAL may fail in open or configure calls for
+ * this combination.
+ *
+ * Ex. 3: Camera Device 0 = Back Camera
+ * Camera Device 1 = Front Camera
+ * Camera Device 2 = Low-power Front Camera that uses the same
+ * sensor as device 1, but only exposes image stream
+ * resolutions that can be used in low-power mode
+ * - Using both front cameras (device 1, 2) at the same time is impossible due
+ * a shared physical sensor. Using the back and "high-power" front camera
+ * (device 1) may be impossible for some stream configurations due to hardware
+ * limitations, but the "low-power" front camera option may always be used as
+ * it has special dedicated hardware.
+ *
+ * Configuration:
+ *
+ * Camera Device 0 - resource_cost = 100
+ * conflicting_devices = null
+ * Camera Device 1 - resource_cost = 100
+ * conflicting_devices = { 2 }
+ * Camera Device 2 - resource_cost = 0
+ * conflicting_devices = { 1 }
+ * Result:
+ *
+ * Based on the conflicting_devices fields, the camera service guarantees that
+ * the following sets of open devices will never be allowed: { 1, 2 }.
+ *
+ * Based on the resource_cost fields, only the highest priority application
+ * may attempt to open both device 0 and 1 at the same time. If a higher-priority
+ * application is not using device 1 or 2, a low-priority background application
+ * may open device 2 (but will be forced to disconnect it if a higher-priority
+ * application subsequently opens device 1 or 2).
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * Not valid. Can be assumed to be 100. Do not read this field.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * Always valid.
+ */
+ int resource_cost;
+
+ /**
+ * An array of camera device IDs represented as NULL-terminated strings
+ * indicating other devices that cannot be simultaneously opened while this
+ * camera device is in use.
+ *
+ * This field is intended to be used to indicate that this camera device
+ * is a composite of several other camera devices, or otherwise has
+ * hardware dependencies that prohibit simultaneous usage. If there are no
+ * dependencies, a NULL may be returned in this field to indicate this.
+ *
+ * The camera service will never simultaneously open any of the devices
+ * in this list while this camera device is open.
+ *
+ * The strings pointed to in this field will not be cleaned up by the camera
+ * service, and must remain while this device is plugged in.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * Not valid. Can be assumed to be NULL. Do not read this field.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * Always valid.
+ */
+ char** conflicting_devices;
+
+ /**
+ * The length of the array given in the conflicting_devices field.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * Not valid. Can be assumed to be 0. Do not read this field.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * Always valid.
+ */
+ size_t conflicting_devices_length;
+
+} camera_info_t;
+
+/**
+ * camera_device_status_t:
+ *
+ * The current status of the camera device, as provided by the HAL through the
+ * camera_module_callbacks.camera_device_status_change() call.
+ *
+ * At module load time, the framework will assume all camera devices are in the
+ * CAMERA_DEVICE_STATUS_PRESENT state. The HAL should invoke
+ * camera_module_callbacks::camera_device_status_change to inform the framework
+ * of any initially NOT_PRESENT devices.
+ *
+ * Allowed transitions:
+ * PRESENT -> NOT_PRESENT
+ * NOT_PRESENT -> ENUMERATING
+ * NOT_PRESENT -> PRESENT
+ * ENUMERATING -> PRESENT
+ * ENUMERATING -> NOT_PRESENT
+ */
+typedef enum camera_device_status {
+ /**
+ * The camera device is not currently connected, and opening it will return
+ * failure.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * Calls to get_camera_info must still succeed, and provide the same information
+ * it would if the camera were connected.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4:
+ *
+ * The camera device at this status must return -EINVAL for get_camera_info call,
+ * as the device is not connected.
+ */
+ CAMERA_DEVICE_STATUS_NOT_PRESENT = 0,
+
+ /**
+ * The camera device is connected, and opening it will succeed.
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * The information returned by get_camera_info cannot change due to this status
+ * change. By default, the framework will assume all devices are in this state.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4:
+ *
+ * The information returned by get_camera_info will become valid after a device's
+ * status changes to this. By default, the framework will assume all devices are in
+ * this state.
+ */
+ CAMERA_DEVICE_STATUS_PRESENT = 1,
+
+ /**
+ * The camera device is connected, but it is undergoing an enumeration and
+ * so opening the device will return -EBUSY.
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * Calls to get_camera_info must still succeed, as if the camera was in the
+ * PRESENT status.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4:
+ *
+ * The camera device at this status must return -EINVAL for get_camera_info for call,
+ * as the device is not ready.
+ */
+ CAMERA_DEVICE_STATUS_ENUMERATING = 2,
+
+} camera_device_status_t;
+
+/**
+ * torch_mode_status_t:
+ *
+ * The current status of the torch mode, as provided by the HAL through the
+ * camera_module_callbacks.torch_mode_status_change() call.
+ *
+ * The torch mode status of a camera device is applicable only when the camera
+ * device is present. The framework will not call set_torch_mode() to turn on
+ * torch mode of a camera device if the camera device is not present. At module
+ * load time, the framework will assume torch modes are in the
+ * TORCH_MODE_STATUS_AVAILABLE_OFF state if the camera device is present and
+ * android.flash.info.available is reported as true via get_camera_info() call.
+ *
+ * The behaviors of the camera HAL module that the framework expects in the
+ * following situations when a camera device's status changes:
+ * 1. A previously-disconnected camera device becomes connected.
+ * After camera_module_callbacks::camera_device_status_change() is invoked
+ * to inform the framework that the camera device is present, the framework
+ * will assume the camera device's torch mode is in
+ * TORCH_MODE_STATUS_AVAILABLE_OFF state. The camera HAL module does not need
+ * to invoke camera_module_callbacks::torch_mode_status_change() unless the
+ * flash unit is unavailable to use by set_torch_mode().
+ *
+ * 2. A previously-connected camera becomes disconnected.
+ * After camera_module_callbacks::camera_device_status_change() is invoked
+ * to inform the framework that the camera device is not present, the
+ * framework will not call set_torch_mode() for the disconnected camera
+ * device until its flash unit becomes available again. The camera HAL
+ * module does not need to invoke
+ * camera_module_callbacks::torch_mode_status_change() separately to inform
+ * that the flash unit has become unavailable.
+ *
+ * 3. open() is called to open a camera device.
+ * The camera HAL module must invoke
+ * camera_module_callbacks::torch_mode_status_change() for all flash units
+ * that have entered TORCH_MODE_STATUS_NOT_AVAILABLE state and can not be
+ * turned on by calling set_torch_mode() anymore due to this open() call.
+ * open() must not trigger TORCH_MODE_STATUS_AVAILABLE_OFF before
+ * TORCH_MODE_STATUS_NOT_AVAILABLE for all flash units that have become
+ * unavailable.
+ *
+ * 4. close() is called to close a camera device.
+ * The camera HAL module must invoke
+ * camera_module_callbacks::torch_mode_status_change() for all flash units
+ * that have entered TORCH_MODE_STATUS_AVAILABLE_OFF state and can be turned
+ * on by calling set_torch_mode() again because of enough resources freed
+ * up by this close() call.
+ *
+ * Note that the framework calling set_torch_mode() successfully must trigger
+ * TORCH_MODE_STATUS_AVAILABLE_OFF or TORCH_MODE_STATUS_AVAILABLE_ON callback
+ * for the given camera device. Additionally it must trigger
+ * TORCH_MODE_STATUS_AVAILABLE_OFF callbacks for other previously-on torch
+ * modes if HAL cannot keep multiple torch modes on simultaneously.
+ */
+typedef enum torch_mode_status {
+
+ /**
+ * The flash unit is no longer available and the torch mode can not be
+ * turned on by calling set_torch_mode(). If the torch mode is on, it
+ * will be turned off by HAL before HAL calls torch_mode_status_change().
+ */
+ TORCH_MODE_STATUS_NOT_AVAILABLE = 0,
+
+ /**
+ * A torch mode has become off and available to be turned on via
+ * set_torch_mode(). This may happen in the following
+ * cases:
+ * 1. After the resources to turn on the torch mode have become available.
+ * 2. After set_torch_mode() is called to turn off the torch mode.
+ * 3. After the framework turned on the torch mode of some other camera
+ * device and HAL had to turn off the torch modes of any camera devices
+ * that were previously on.
+ */
+ TORCH_MODE_STATUS_AVAILABLE_OFF = 1,
+
+ /**
+ * A torch mode has become on and available to be turned off via
+ * set_torch_mode(). This can happen only after set_torch_mode() is called
+ * to turn on the torch mode.
+ */
+ TORCH_MODE_STATUS_AVAILABLE_ON = 2,
+
+} torch_mode_status_t;
+
+/**
+ * Callback functions for the camera HAL module to use to inform the framework
+ * of changes to the camera subsystem.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * Each callback is called only by HAL modules implementing the indicated
+ * version or higher of the HAL module API interface.
+ *
+ * CAMERA_MODULE_API_VERSION_2_1:
+ * camera_device_status_change()
+ *
+ * CAMERA_MODULE_API_VERSION_2_4:
+ * torch_mode_status_change()
+
+ */
+typedef struct camera_module_callbacks {
+
+ /**
+ * camera_device_status_change:
+ *
+ * Callback to the framework to indicate that the state of a specific camera
+ * device has changed. At module load time, the framework will assume all
+ * camera devices are in the CAMERA_DEVICE_STATUS_PRESENT state. The HAL
+ * must call this method to inform the framework of any initially
+ * NOT_PRESENT devices.
+ *
+ * This callback is added for CAMERA_MODULE_API_VERSION_2_1.
+ *
+ * camera_module_callbacks: The instance of camera_module_callbacks_t passed
+ * to the module with set_callbacks.
+ *
+ * camera_id: The ID of the camera device that has a new status.
+ *
+ * new_status: The new status code, one of the camera_device_status_t enums,
+ * or a platform-specific status.
+ *
+ */
+ void (*camera_device_status_change)(const struct camera_module_callbacks*,
+ int camera_id,
+ int new_status);
+
+ /**
+ * torch_mode_status_change:
+ *
+ * Callback to the framework to indicate that the state of the torch mode
+ * of the flash unit associated with a specific camera device has changed.
+ * At module load time, the framework will assume the torch modes are in
+ * the TORCH_MODE_STATUS_AVAILABLE_OFF state if android.flash.info.available
+ * is reported as true via get_camera_info() call.
+ *
+ * This callback is added for CAMERA_MODULE_API_VERSION_2_4.
+ *
+ * camera_module_callbacks: The instance of camera_module_callbacks_t
+ * passed to the module with set_callbacks.
+ *
+ * camera_id: The ID of camera device whose flash unit has a new torch mode
+ * status.
+ *
+ * new_status: The new status code, one of the torch_mode_status_t enums.
+ */
+ void (*torch_mode_status_change)(const struct camera_module_callbacks*,
+ const char* camera_id,
+ int new_status);
+
+
+} camera_module_callbacks_t;
+
+/**
+ * camera_stream_t:
+ *
+ * A handle to a single camera input or output stream. A stream is defined by
+ * the framework by its buffer resolution and format and gralloc usage flags.
+ *
+ * The stream structures are owned by the framework and pointers to a
+ * camera_stream passed into the HAL by is_stream_combination_supported() are
+ * only valid within the scope of the call.
+ *
+ * All camera_stream members are immutable.
+ */
+typedef struct camera_stream {
+ /**
+ * The type of the stream, one of the camera3_stream_type_t values.
+ */
+ int stream_type;
+
+ /**
+ * The width in pixels of the buffers in this stream
+ */
+ uint32_t width;
+
+ /**
+ * The height in pixels of the buffers in this stream
+ */
+ uint32_t height;
+
+ /**
+ * The pixel format for the buffers in this stream. Format is a value from
+ * the HAL_PIXEL_FORMAT_* list in system/core/include/system/graphics.h, or
+ * from device-specific headers.
+ *
+ * If HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, then the platform
+ * gralloc module will select a format based on the usage flags provided by
+ * the camera device and the other endpoint of the stream.
+ *
+ */
+ int format;
+
+ /**
+ * The gralloc usage flags for this stream, as needed by the HAL. The usage
+ * flags are defined in gralloc.h (GRALLOC_USAGE_*), or in device-specific
+ * headers.
+ *
+ * For output streams, these are the HAL's producer usage flags. For input
+ * streams, these are the HAL's consumer usage flags. The usage flags from
+ * the producer and the consumer will be combined together and then passed
+ * to the platform gralloc HAL module for allocating the gralloc buffers for
+ * each stream.
+ *
+ * The usage flag for an output stream may be bitwise
+ * combination of usage flags for multiple consumers, for the purpose of
+ * sharing one camera stream between those consumers. The HAL must fail
+ * the stream combination query call with -EINVAL if the combined flags cannot be
+ * supported due to imcompatible buffer format, dataSpace, or other hardware
+ * limitations.
+ */
+ uint32_t usage;
+
+ /**
+ * A field that describes the contents of the buffer. The format and buffer
+ * dimensions define the memory layout and structure of the stream buffers,
+ * while dataSpace defines the meaning of the data within the buffer.
+ *
+ * For most formats, dataSpace defines the color space of the image data.
+ * In addition, for some formats, dataSpace indicates whether image- or
+ * depth-based data is requested. See system/core/include/system/graphics.h
+ * for details of formats and valid dataSpace values for each format.
+ *
+ * Always set by the camera service. The dataspace values are set
+ * using the V0 dataspace definitions in graphics.h
+ */
+ android_dataspace_t data_space;
+
+ /**
+ * The required output rotation of the stream, one of
+ * the camera3_stream_rotation_t values. This must be inspected by HAL along
+ * with stream width and height. For example, if the rotation is 90 degree
+ * and the stream width and height is 720 and 1280 respectively, camera service
+ * will supply buffers of size 720x1280, and HAL should capture a 1280x720 image
+ * and rotate the image by 90 degree counterclockwise. The rotation field is
+ * no-op when the stream type is input. Camera HAL must ignore the rotation
+ * field for an input stream.
+ *
+ * Always set by camera service. HAL must inspect this field during stream
+ * combination query and return -EINVAL if it cannot perform such rotation.
+ * HAL must always support CAMERA3_STREAM_ROTATION_0, so a
+ * is_stream_combination_supported() call must not fail for unsupported rotation if
+ * rotation field of all streams is CAMERA3_STREAM_ROTATION_0.
+ *
+ */
+ int rotation;
+
+ /**
+ * The physical camera id this stream belongs to.
+ * Always set by camera service. If the camera device is not a logical
+ * multi camera, or if the camera is a logical multi camera but the stream
+ * is not a physical output stream, this field will point to a 0-length
+ * string.
+ *
+ * A logical multi camera is a camera device backed by multiple physical
+ * cameras that are also exposed to the application. And for a logical
+ * multi camera, a physical output stream is an output stream specifically
+ * requested on an underlying physical camera.
+ *
+ * For an input stream, this field is guaranteed to be a 0-length string.
+ */
+ const char* physical_camera_id;
+
+} camera_stream_t;
+
+/**
+ * camera_stream_combination_t:
+ *
+ * A structure of stream definitions, used by is_stream_combination_supported(). This
+ * structure defines all the input & output streams for specific camera use case.
+ */
+typedef struct camera_stream_combination {
+ /**
+ * The total number of streams by the framework. This includes
+ * both input and output streams. The number of streams will be at least 1,
+ * and there will be at least one output-capable stream.
+ */
+ uint32_t num_streams;
+
+ /**
+ * An array of camera streams, defining the input/output
+ * stream combination for the camera HAL device.
+ *
+ * At most one input-capable stream may be defined.
+ *
+ * At least one output-capable stream must be defined.
+ */
+ camera_stream_t *streams;
+
+ /**
+ * The operation mode of streams in this stream combination, one of the value
+ * defined in camera3_stream_configuration_mode_t.
+ *
+ */
+ uint32_t operation_mode;
+
+} camera_stream_combination_t;
+
+/**
+ * device_state_t:
+ *
+ * Possible physical states of the overall device, for use with
+ * notify_device_state_change.
+ */
+typedef enum device_state {
+ /**
+ * The device is in its normal physical configuration. This is the default if the
+ * device does not support multiple different states.
+ */
+ NORMAL = 0,
+
+ /**
+ * Camera device(s) facing backward are covered.
+ */
+ BACK_COVERED = 1 << 0,
+
+ /**
+ * Camera device(s) facing foward are covered.
+ */
+ FRONT_COVERED = 1 << 1,
+
+ /**
+ * The device is folded. If not set, the device is unfolded or does not
+ * support folding.
+ *
+ * The exact point when this status change happens during the folding
+ * operation is device-specific.
+ */
+ FOLDED = 1 << 2,
+
+ /**
+ * First vendor-specific device state. All bits above and including this one
+ * are for vendor state values. Values below this one must only be used
+ * for framework-defined states.
+ */
+ VENDOR_STATE_START = 1LL << 32
+
+} device_state_t;
+
+typedef struct camera_module {
+ /**
+ * Common methods of the camera module. This *must* be the first member of
+ * camera_module as users of this structure will cast a hw_module_t to
+ * camera_module pointer in contexts where it's known the hw_module_t
+ * references a camera_module.
+ *
+ * The return values for common.methods->open for camera_module are:
+ *
+ * 0: On a successful open of the camera device.
+ *
+ * -ENODEV: The camera device cannot be opened due to an internal
+ * error.
+ *
+ * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
+ * and/or the module is invalid.
+ *
+ * -EBUSY: The camera device was already opened for this camera id
+ * (by using this method or open_legacy),
+ * regardless of the device HAL version it was opened as.
+ *
+ * -EUSERS: The maximal number of camera devices that can be
+ * opened concurrently were opened already, either by
+ * this method or the open_legacy method.
+ *
+ * All other return values from common.methods->open will be treated as
+ * -ENODEV.
+ */
+ hw_module_t common;
+
+ /**
+ * get_number_of_cameras:
+ *
+ * Returns the number of camera devices accessible through the camera
+ * module. The camera devices are numbered 0 through N-1, where N is the
+ * value returned by this call. The name of the camera device for open() is
+ * simply the number converted to a string. That is, "0" for camera ID 0,
+ * "1" for camera ID 1.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_3 or lower:
+ *
+ * The value here must be static, and cannot change after the first call
+ * to this method.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * The value here must be static, and must count only built-in cameras,
+ * which have CAMERA_FACING_BACK or CAMERA_FACING_FRONT camera facing values
+ * (camera_info.facing). The HAL must not include the external cameras
+ * (camera_info.facing == CAMERA_FACING_EXTERNAL) into the return value
+ * of this call. Frameworks will use camera_device_status_change callback
+ * to manage number of external cameras.
+ */
+ int (*get_number_of_cameras)(void);
+
+#ifdef CAMERA_NEEDS_SEC_GET_CAM_POS_V1
+ /**
+ * get_cam_pos:
+ *
+ * Unknown. Needed by prebuilt camera module from the Samsung GTO device.
+ *
+ * Return values found so far:
+ *
+ * 0: On a successful operation
+ *
+ * -EINVAL: The input arguments are invalid
+ *
+ */
+ int (*get_cam_pos)(void);
+#endif
+
+ /**
+ * get_camera_info:
+ *
+ * Return the static camera information for a given camera device. This
+ * information may not change for a camera device.
+ *
+ * Return values:
+ *
+ * 0: On a successful operation
+ *
+ * -ENODEV: The information cannot be provided due to an internal
+ * error.
+ *
+ * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
+ * and/or the module is invalid.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_2_4 or higher:
+ *
+ * When a camera is disconnected, its camera id becomes invalid. Calling this
+ * this method with this invalid camera id will get -EINVAL and NULL camera
+ * static metadata (camera_info.static_camera_characteristics).
+ */
+ int (*get_camera_info)(int camera_id, struct camera_info *info);
+
+#ifdef CAMERA_NEEDS_SEC_GET_CAM_POS_V2
+ /**
+ * get_cam_pos:
+ *
+ * Unknown. Needed by prebuilt camera module from the Samsung GTA4L device.
+ *
+ * Return values found so far:
+ *
+ * 0: On a successful operation
+ *
+ * -EINVAL: The input arguments are invalid
+ *
+ */
+ int (*get_cam_pos)(void);
+#endif
+
+ /**
+ * set_callbacks:
+ *
+ * Provide callback function pointers to the HAL module to inform framework
+ * of asynchronous camera module events. The framework will call this
+ * function once after initial camera HAL module load, after the
+ * get_number_of_cameras() method is called for the first time, and before
+ * any other calls to the module.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_0, CAMERA_MODULE_API_VERSION_2_0:
+ *
+ * Not provided by HAL module. Framework may not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_1:
+ *
+ * Valid to be called by the framework.
+ *
+ * Return values:
+ *
+ * 0: On a successful operation
+ *
+ * -ENODEV: The operation cannot be completed due to an internal
+ * error.
+ *
+ * -EINVAL: The input arguments are invalid, i.e. the callbacks are
+ * null
+ */
+ int (*set_callbacks)(const camera_module_callbacks_t *callbacks);
+
+ /**
+ * get_vendor_tag_ops:
+ *
+ * Get methods to query for vendor extension metadata tag information. The
+ * HAL should fill in all the vendor tag operation methods, or leave ops
+ * unchanged if no vendor tags are defined.
+ *
+ * The vendor_tag_ops structure used here is defined in:
+ * system/media/camera/include/system/vendor_tags.h
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1:
+ * Not provided by HAL module. Framework may not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_2:
+ * Valid to be called by the framework.
+ */
+ void (*get_vendor_tag_ops)(vendor_tag_ops_t* ops);
+
+ /**
+ * open_legacy:
+ *
+ * Open a specific legacy camera HAL device if multiple device HAL API
+ * versions are supported by this camera HAL module. For example, if the
+ * camera module supports both CAMERA_DEVICE_API_VERSION_1_0 and
+ * CAMERA_DEVICE_API_VERSION_3_2 device API for the same camera id,
+ * framework can call this function to open the camera device as
+ * CAMERA_DEVICE_API_VERSION_1_0 device.
+ *
+ * This is an optional method. A Camera HAL module does not need to support
+ * more than one device HAL version per device, and such modules may return
+ * -ENOSYS for all calls to this method. For all older HAL device API
+ * versions that are not supported, it may return -EOPNOTSUPP. When above
+ * cases occur, The normal open() method (common.methods->open) will be
+ * used by the framework instead.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2:
+ * Not provided by HAL module. Framework will not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_3:
+ * Valid to be called by the framework.
+ *
+ * Return values:
+ *
+ * 0: On a successful open of the camera device.
+ *
+ * -ENOSYS This method is not supported.
+ *
+ * -EOPNOTSUPP: The requested HAL version is not supported by this method.
+ *
+ * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
+ * and/or the module is invalid.
+ *
+ * -EBUSY: The camera device was already opened for this camera id
+ * (by using this method or common.methods->open method),
+ * regardless of the device HAL version it was opened as.
+ *
+ * -EUSERS: The maximal number of camera devices that can be
+ * opened concurrently were opened already, either by
+ * this method or common.methods->open method.
+ */
+ int (*open_legacy)(const struct hw_module_t* module, const char* id,
+ uint32_t halVersion, struct hw_device_t** device);
+
+ /**
+ * set_torch_mode:
+ *
+ * Turn on or off the torch mode of the flash unit associated with a given
+ * camera ID. If the operation is successful, HAL must notify the framework
+ * torch state by invoking
+ * camera_module_callbacks.torch_mode_status_change() with the new state.
+ *
+ * The camera device has a higher priority accessing the flash unit. When
+ * there are any resource conflicts, such as open() is called to open a
+ * camera device, HAL module must notify the framework through
+ * camera_module_callbacks.torch_mode_status_change() that the
+ * torch mode has been turned off and the torch mode state has become
+ * TORCH_MODE_STATUS_NOT_AVAILABLE. When resources to turn on torch mode
+ * become available again, HAL module must notify the framework through
+ * camera_module_callbacks.torch_mode_status_change() that the torch mode
+ * state has become TORCH_MODE_STATUS_AVAILABLE_OFF for set_torch_mode() to
+ * be called.
+ *
+ * When the framework calls set_torch_mode() to turn on the torch mode of a
+ * flash unit, if HAL cannot keep multiple torch modes on simultaneously,
+ * HAL should turn off the torch mode that was turned on by
+ * a previous set_torch_mode() call and notify the framework that the torch
+ * mode state of that flash unit has become TORCH_MODE_STATUS_AVAILABLE_OFF.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3:
+ * Not provided by HAL module. Framework will not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4:
+ * Valid to be called by the framework.
+ *
+ * Return values:
+ *
+ * 0: On a successful operation.
+ *
+ * -ENOSYS: The camera device does not support this operation. It is
+ * returned if and only if android.flash.info.available is
+ * false.
+ *
+ * -EBUSY: The camera device is already in use.
+ *
+ * -EUSERS: The resources needed to turn on the torch mode are not
+ * available, typically because other camera devices are
+ * holding the resources to make using the flash unit not
+ * possible.
+ *
+ * -EINVAL: camera_id is invalid.
+ *
+ */
+ int (*set_torch_mode)(const char* camera_id, bool enabled);
+
+ /**
+ * init:
+ *
+ * This method is called by the camera service before any other methods
+ * are invoked, right after the camera HAL library has been successfully
+ * loaded. It may be left as NULL by the HAL module, if no initialization
+ * in needed.
+ *
+ * It can be used by HAL implementations to perform initialization and
+ * other one-time operations.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3:
+ * Not provided by HAL module. Framework will not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_4:
+ * If not NULL, will always be called by the framework once after the HAL
+ * module is loaded, before any other HAL module method is called.
+ *
+ * Return values:
+ *
+ * 0: On a successful operation.
+ *
+ * -ENODEV: Initialization cannot be completed due to an internal
+ * error. The HAL must be assumed to be in a nonfunctional
+ * state.
+ *
+ */
+ int (*init)();
+
+ /**
+ * get_physical_camera_info:
+ *
+ * Return the static metadata for a physical camera as a part of a logical
+ * camera device. This function is only called for those physical camera
+ * ID(s) that are not exposed independently. In other words, camera_id will
+ * be greater or equal to the return value of get_number_of_cameras().
+ *
+ * Return values:
+ *
+ * 0: On a successful operation
+ *
+ * -ENODEV: The information cannot be provided due to an internal
+ * error.
+ *
+ * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
+ * and/or the module is invalid.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3/2_4:
+ * Not provided by HAL module. Framework will not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_5 or higher:
+ * If any of the camera devices accessible through this camera module is
+ * a logical multi-camera, and at least one of the physical cameras isn't
+ * a stand-alone camera device, this function will be called by the camera
+ * framework. Calling this function with invalid physical_camera_id will
+ * get -EINVAL, and NULL static_metadata.
+ */
+ int (*get_physical_camera_info)(int physical_camera_id,
+ camera_metadata_t **static_metadata);
+
+ /**
+ * is_stream_combination_supported:
+ *
+ * Check for device support of specific camera stream combination.
+ *
+ * Return values:
+ *
+ * 0: In case the stream combination is supported.
+ *
+ * -EINVAL: In case the stream combination is not supported.
+ *
+ * -ENOSYS: In case stream combination query is not supported.
+ *
+ * Version information (based on camera_module_t.common.module_api_version):
+ *
+ * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3/2_4:
+ * Not provided by HAL module. Framework will not call this function.
+ *
+ * CAMERA_MODULE_API_VERSION_2_5 or higher:
+ * Valid to be called by the framework.
+ */
+ int (*is_stream_combination_supported)(int camera_id,
+ const camera_stream_combination_t *streams);
+
+ /**
+ * notify_device_state_change:
+ *
+ * Notify the camera module that the state of the overall device has
+ * changed in some way that the HAL may want to know about.
+ *
+ * For example, a physical shutter may have been uncovered or covered,
+ * or a camera may have been covered or uncovered by an add-on keyboard
+ * or other accessory.
+ *
+ * The state is a bitfield of potential states, and some physical configurations
+ * could plausibly correspond to multiple different combinations of state bits.
+ * The HAL must ignore any state bits it is not actively using to determine
+ * the appropriate camera configuration.
+ *
+ * For example, on some devices the FOLDED state could mean that
+ * backward-facing cameras are covered by the fold, so FOLDED by itself implies
+ * BACK_COVERED. But other devices may support folding but not cover any cameras
+ * when folded, so for those FOLDED would not imply any of the other flags.
+ * Since these relationships are very device-specific, it is difficult to specify
+ * a comprehensive policy. But as a recommendation, it is suggested that if a flag
+ * necessarily implies other flags are set as well, then those flags should be set.
+ * So even though FOLDED would be enough to infer BACK_COVERED on some devices, the
+ * BACK_COVERED flag should also be set for clarity.
+ *
+ * This method may be invoked by the HAL client at any time. It must not
+ * cause any active camera device sessions to be closed, but may dynamically
+ * change which physical camera a logical multi-camera is using for its
+ * active and future output.
+ *
+ * The method must be invoked by the HAL client at least once before the
+ * client calls ICameraDevice::open on any camera device interfaces listed
+ * by this provider, to establish the initial device state.
+ *
+ * Note that the deviceState is 64-bit bitmask, with system defined states in
+ * lower 32-bit and vendor defined states in upper 32-bit.
+ */
+ void (*notify_device_state_change)(uint64_t deviceState);
+
+ /* reserved for future use */
+ void* reserved[2];
+} camera_module_t;
+
+__END_DECLS
+
+#endif /* ANDROID_INCLUDE_CAMERA_COMMON_H */
cc_binary {
name: "android.hardware.camera.provider-service.samsung",
+ defaults: ["samsung_camera3_defaults"],
init_rc: ["android.hardware.camera.provider-service.samsung.rc"],
vintf_fragments: ["android.hardware.camera.provider-service.samsung.xml"],
vendor: true,
"libutils",
],
static_libs: [
- "android.hardware.camera.common-helper",
+ "android.hardware.camera.common-helper.samsung",
"libaidlcommonsupport",
],
+ header_libs: [
+ "libhardware_headers.camera3_samsung",
+ ],
}
+++ /dev/null
-cc_library_static {
- name: "android.hardware.camera.common-helper.samsung",
- vendor_available: true,
- defaults: [
- "hidl_defaults",
- "samsung_camera3_defaults",
- ],
- srcs: [
- "CameraModule.cpp",
- "CameraMetadata.cpp",
- "CameraParameters.cpp",
- "VendorTagDescriptor.cpp",
- "HandleImporter.cpp",
- "Exif.cpp",
- "SimpleThread.cpp",
- ],
- cflags: [
- "-Werror",
- "-Wextra",
- "-Wall",
- ],
- shared_libs: [
- "liblog",
- "libgralloctypes",
- "libhardware",
- "libcamera_metadata",
- "libexif",
- "libui",
- ],
- include_dirs: ["system/media/private/camera/include"],
- header_libs: ["libhardware_headers.camera3_samsung"],
- export_include_dirs: ["include"],
- export_shared_lib_headers: ["libui"],
-}
-
-// NOTE: Deprecated module kept for compatibility reasons.
-// Depend on "android.hardware.camera.common-helper.samsung" instead
-cc_library_static {
- name: "android.hardware.camera.common@1.0-helper.samsung",
- vendor_available: true,
- whole_static_libs: ["android.hardware.camera.common-helper.samsung"],
-}
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/CameraMetadata.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/CameraModule.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/CameraParameters.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/Exif.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/HandleImporter.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/SimpleThread.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/VendorTagDescriptor.cpp
\ No newline at end of file
+++ /dev/null
-../../../../../hardware/interfaces/camera/common/default/include/
\ No newline at end of file
+++ /dev/null
-soong_config_module_type {
- name: "samsung_camera3",
- module_type: "cc_defaults",
- config_namespace: "samsungCameraVars",
- bool_variables: [
- "needs_sec_get_cam_pos_v1",
- "needs_sec_get_cam_pos_v2",
- "needs_sec_reserved_field",
- "usage_64bit",
- ],
- properties: ["cflags"],
-}
-
-samsung_camera3 {
- name: "samsung_camera3_defaults",
- soong_config_variables: {
- needs_sec_get_cam_pos_v1: {
- cflags: ["-DCAMERA_NEEDS_SEC_GET_CAM_POS_V1"],
- },
- needs_sec_get_cam_pos_v2: {
- cflags: ["-DCAMERA_NEEDS_SEC_GET_CAM_POS_V2"],
- },
- needs_sec_reserved_field: {
- cflags: ["-DCAMERA_NEEDS_SEC_RESERVED_FIELD"],
- },
- usage_64bit: {
- cflags: ["-DCAMERA_64BIT_USAGE"],
- },
- },
-}
-
-cc_library_headers {
- name: "libhardware_headers.camera3_samsung",
- export_include_dirs: ["include"],
- vendor_available: true,
-}
+++ /dev/null
-../../../../../../../hardware/libhardware/include/hardware/camera.h
\ No newline at end of file
+++ /dev/null
-/*
- * Copyright (C) 2013-2018 The Android Open Source Project
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-#ifndef ANDROID_INCLUDE_CAMERA3_H
-#define ANDROID_INCLUDE_CAMERA3_H
-
-#include <system/camera_metadata.h>
-#include "camera_common.h"
-
-/**
- * Camera device HAL 3.6[ CAMERA_DEVICE_API_VERSION_3_6 ]
- *
- * This is the current recommended version of the camera device HAL.
- *
- * Supports the android.hardware.Camera API, and as of v3.2, the
- * android.hardware.camera2 API as LIMITED or above hardware level.
- *
- * Camera devices that support this version of the HAL must return
- * CAMERA_DEVICE_API_VERSION_3_6 in camera_device_t.common.version and in
- * camera_info_t.device_version (from camera_module_t.get_camera_info).
- *
- * CAMERA_DEVICE_API_VERSION_3_3 and above:
- * Camera modules that may contain version 3.3 or above devices must
- * implement at least version 2.2 of the camera module interface (as defined
- * by camera_module_t.common.module_api_version).
- *
- * CAMERA_DEVICE_API_VERSION_3_2:
- * Camera modules that may contain version 3.2 devices must implement at
- * least version 2.2 of the camera module interface (as defined by
- * camera_module_t.common.module_api_version).
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- * Camera modules that may contain version 3.1 (or 3.0) devices must
- * implement at least version 2.0 of the camera module interface
- * (as defined by camera_module_t.common.module_api_version).
- *
- * See camera_common.h for more versioning details.
- *
- * Documentation index:
- * S1. Version history
- * S2. Startup and operation sequencing
- * S3. Operational modes
- * S4. 3A modes and state machines
- * S5. Cropping
- * S6. Error management
- * S7. Key Performance Indicator (KPI) glossary
- * S8. Sample Use Cases
- * S9. Notes on Controls and Metadata
- * S10. Reprocessing flow and controls
- */
-
-/**
- * S1. Version history:
- *
- * 1.0: Initial Android camera HAL (Android 4.0) [camera.h]:
- *
- * - Converted from C++ CameraHardwareInterface abstraction layer.
- *
- * - Supports android.hardware.Camera API.
- *
- * 2.0: Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:
- *
- * - Sufficient for implementing existing android.hardware.Camera API.
- *
- * - Allows for ZSL queue in camera service layer
- *
- * - Not tested for any new features such manual capture control, Bayer RAW
- * capture, reprocessing of RAW data.
- *
- * 3.0: First revision of expanded-capability HAL:
- *
- * - Major version change since the ABI is completely different. No change to
- * the required hardware capabilities or operational model from 2.0.
- *
- * - Reworked input request and stream queue interfaces: Framework calls into
- * HAL with next request and stream buffers already dequeued. Sync framework
- * support is included, necessary for efficient implementations.
- *
- * - Moved triggers into requests, most notifications into results.
- *
- * - Consolidated all callbacks into framework into one structure, and all
- * setup methods into a single initialize() call.
- *
- * - Made stream configuration into a single call to simplify stream
- * management. Bidirectional streams replace STREAM_FROM_STREAM construct.
- *
- * - Limited mode semantics for older/limited hardware devices.
- *
- * 3.1: Minor revision of expanded-capability HAL:
- *
- * - configure_streams passes consumer usage flags to the HAL.
- *
- * - flush call to drop all in-flight requests/buffers as fast as possible.
- *
- * 3.2: Minor revision of expanded-capability HAL:
- *
- * - Deprecates get_metadata_vendor_tag_ops. Please use get_vendor_tag_ops
- * in camera_common.h instead.
- *
- * - register_stream_buffers deprecated. All gralloc buffers provided
- * by framework to HAL in process_capture_request may be new at any time.
- *
- * - add partial result support. process_capture_result may be called
- * multiple times with a subset of the available result before the full
- * result is available.
- *
- * - add manual template to camera3_request_template. The applications may
- * use this template to control the capture settings directly.
- *
- * - Rework the bidirectional and input stream specifications.
- *
- * - change the input buffer return path. The buffer is returned in
- * process_capture_result instead of process_capture_request.
- *
- * 3.3: Minor revision of expanded-capability HAL:
- *
- * - OPAQUE and YUV reprocessing API updates.
- *
- * - Basic support for depth output buffers.
- *
- * - Addition of data_space field to camera3_stream_t.
- *
- * - Addition of rotation field to camera3_stream_t.
- *
- * - Addition of camera3 stream configuration operation mode to camera3_stream_configuration_t
- *
- * 3.4: Minor additions to supported metadata and changes to data_space support
- *
- * - Add ANDROID_SENSOR_OPAQUE_RAW_SIZE static metadata as mandatory if
- * RAW_OPAQUE format is supported.
- *
- * - Add ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata as
- * mandatory if any RAW format is supported
- *
- * - Switch camera3_stream_t data_space field to a more flexible definition,
- * using the version 0 definition of dataspace encoding.
- *
- * - General metadata additions which are available to use for HALv3.2 or
- * newer:
- * - ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
- * - ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
- * - ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
- * - ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
- * - ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
- * - ANDROID_SENSOR_OPAQUE_RAW_SIZE
- * - ANDROID_SENSOR_OPTICAL_BLACK_REGIONS
- *
- * 3.5: Minor revisions to support session parameters and logical multi camera:
- *
- * - Add ANDROID_REQUEST_AVAILABLE_SESSION_KEYS static metadata, which is
- * optional for implementations that want to support session parameters. If support is
- * needed, then Hal should populate the list with all available capture request keys
- * that can cause severe processing delays when modified by client. Typical examples
- * include parameters that require time-consuming HW re-configuration or internal camera
- * pipeline update.
- *
- * - Add a session parameter field to camera3_stream_configuration which can be populated
- * by clients with initial values for the keys found in ANDROID_REQUEST_AVAILABLE_SESSION_KEYS.
- *
- * - Metadata additions for logical multi camera capability:
- * - ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
- * - ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
- * - ANDROID_LOGICAL_MULTI_CAMERA_SYNC_TYPE
- *
- * - Add physical camera id field in camera3_stream, so that for a logical
- * multi camera, the application has the option to specify which physical camera
- * a particular stream is configured on.
- *
- * - Add physical camera id and settings field in camera3_capture_request, so that
- * for a logical multi camera, the application has the option to specify individual
- * settings for a particular physical device.
- *
- * 3.6: Minor revisions to support HAL buffer management APIs:
- *
- * - Add ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION static metadata, which allows HAL to
- * opt in to the new buffer management APIs described below.
- *
- * - Add request_stream_buffers() and return_stream_buffers() to camera3_callback_ops_t for HAL to
- * request and return output buffers from camera service.
- *
- * - Add signal_stream_flush() to camera3_device_ops_t for camera service to notify HAL an
- * upcoming configure_streams() call requires HAL to return buffers of certain streams.
- *
- * - Add CAMERA3_JPEG_APP_SEGMENTS_BLOB_ID to support BLOB with only JPEG apps
- * segments and thumbnail (without main image bitstream). Camera framework
- * uses such stream togerther with a HAL YUV_420_888/IMPLEMENTATION_DEFINED
- * stream to encode HEIC (ISO/IEC 23008-12) image.
- *
- * - Add is_reconfiguration_required() to camera3_device_ops_t to enable HAL to skip or
- * trigger stream reconfiguration depending on new session parameter values.
- *
- */
-
-/**
- * S2. Startup and general expected operation sequence:
- *
- * 1. Framework calls camera_module_t->common.open(), which returns a
- * hardware_device_t structure.
- *
- * 2. Framework inspects the hardware_device_t->version field, and instantiates
- * the appropriate handler for that version of the camera hardware device. In
- * case the version is CAMERA_DEVICE_API_VERSION_3_0, the device is cast to
- * a camera3_device_t.
- *
- * 3. Framework calls camera3_device_t->ops->initialize() with the framework
- * callback function pointers. This will only be called this one time after
- * open(), before any other functions in the ops structure are called.
- *
- * 4. The framework calls camera3_device_t->ops->configure_streams() with a list
- * of input/output streams to the HAL device.
- *
- * 5. <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * The framework allocates gralloc buffers and calls
- * camera3_device_t->ops->register_stream_buffers() for at least one of the
- * output streams listed in configure_streams. The same stream is registered
- * only once.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * camera3_device_t->ops->register_stream_buffers() is not called and must
- * be NULL.
- *
- * 6. The framework requests default settings for some number of use cases with
- * calls to camera3_device_t->ops->construct_default_request_settings(). This
- * may occur any time after step 3.
- *
- * 7. The framework constructs and sends the first capture request to the HAL,
- * with settings based on one of the sets of default settings, and with at
- * least one output stream, which has been registered earlier by the
- * framework. This is sent to the HAL with
- * camera3_device_t->ops->process_capture_request(). The HAL must block the
- * return of this call until it is ready for the next request to be sent.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * The buffer_handle_t provided in the camera3_stream_buffer_t array
- * in the camera3_capture_request_t may be new and never-before-seen
- * by the HAL on any given new request.
- *
- * 8. The framework continues to submit requests, and call
- * construct_default_request_settings to get default settings buffers for
- * other use cases.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * The framework may call register_stream_buffers() at this time for
- * not-yet-registered streams.
- *
- * 9. When the capture of a request begins (sensor starts exposing for the
- * capture) or processing a reprocess request begins, the HAL
- * calls camera3_callback_ops_t->notify() with the SHUTTER event, including
- * the frame number and the timestamp for start of exposure. For a reprocess
- * request, the timestamp must be the start of exposure of the input image
- * which can be looked up with android.sensor.timestamp from
- * camera3_capture_request_t.settings when process_capture_request() is
- * called.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * This notify call must be made before the first call to
- * process_capture_result() for that frame number.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * The camera3_callback_ops_t->notify() call with the SHUTTER event should
- * be made as early as possible since the framework will be unable to
- * deliver gralloc buffers to the application layer (for that frame) until
- * it has a valid timestamp for the start of exposure (or the input image's
- * start of exposure for a reprocess request).
- *
- * Both partial metadata results and the gralloc buffers may be sent to the
- * framework at any time before or after the SHUTTER event.
- *
- * 10. After some pipeline delay, the HAL begins to return completed captures to
- * the framework with camera3_callback_ops_t->process_capture_result(). These
- * are returned in the same order as the requests were submitted. Multiple
- * requests can be in flight at once, depending on the pipeline depth of the
- * camera HAL device.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Once a buffer is returned by process_capture_result as part of the
- * camera3_stream_buffer_t array, and the fence specified by release_fence
- * has been signaled (this is a no-op for -1 fences), the ownership of that
- * buffer is considered to be transferred back to the framework. After that,
- * the HAL must no longer retain that particular buffer, and the
- * framework may clean up the memory for it immediately.
- *
- * process_capture_result may be called multiple times for a single frame,
- * each time with a new disjoint piece of metadata and/or set of gralloc
- * buffers. The framework will accumulate these partial metadata results
- * into one result.
- *
- * In particular, it is legal for a process_capture_result to be called
- * simultaneously for both a frame N and a frame N+1 as long as the
- * above rule holds for gralloc buffers (both input and output).
- *
- * 11. After some time, the framework may stop submitting new requests, wait for
- * the existing captures to complete (all buffers filled, all results
- * returned), and then call configure_streams() again. This resets the camera
- * hardware and pipeline for a new set of input/output streams. Some streams
- * may be reused from the previous configuration; if these streams' buffers
- * had already been registered with the HAL, they will not be registered
- * again. The framework then continues from step 7, if at least one
- * registered output stream remains (otherwise, step 5 is required first).
- *
- * 12. Alternatively, the framework may call camera3_device_t->common->close()
- * to end the camera session. This may be called at any time when no other
- * calls from the framework are active, although the call may block until all
- * in-flight captures have completed (all results returned, all buffers
- * filled). After the close call returns, no more calls to the
- * camera3_callback_ops_t functions are allowed from the HAL. Once the
- * close() call is underway, the framework may not call any other HAL device
- * functions.
- *
- * 13. In case of an error or other asynchronous event, the HAL must call
- * camera3_callback_ops_t->notify() with the appropriate error/event
- * message. After returning from a fatal device-wide error notification, the
- * HAL should act as if close() had been called on it. However, the HAL must
- * either cancel or complete all outstanding captures before calling
- * notify(), so that once notify() is called with a fatal error, the
- * framework will not receive further callbacks from the device. Methods
- * besides close() should return -ENODEV or NULL after the notify() method
- * returns from a fatal error message.
- */
-
-/**
- * S3. Operational modes:
- *
- * The camera 3 HAL device can implement one of two possible operational modes;
- * limited and full. Full support is expected from new higher-end
- * devices. Limited mode has hardware requirements roughly in line with those
- * for a camera HAL device v1 implementation, and is expected from older or
- * inexpensive devices. Full is a strict superset of limited, and they share the
- * same essential operational flow, as documented above.
- *
- * The HAL must indicate its level of support with the
- * android.info.supportedHardwareLevel static metadata entry, with 0 indicating
- * limited mode, and 1 indicating full mode support.
- *
- * Roughly speaking, limited-mode devices do not allow for application control
- * of capture settings (3A control only), high-rate capture of high-resolution
- * images, raw sensor readout, or support for YUV output streams above maximum
- * recording resolution (JPEG only for large images).
- *
- * ** Details of limited mode behavior:
- *
- * - Limited-mode devices do not need to implement accurate synchronization
- * between capture request settings and the actual image data
- * captured. Instead, changes to settings may take effect some time in the
- * future, and possibly not for the same output frame for each settings
- * entry. Rapid changes in settings may result in some settings never being
- * used for a capture. However, captures that include high-resolution output
- * buffers ( > 1080p ) have to use the settings as specified (but see below
- * for processing rate).
- *
- * - Limited-mode devices do not need to support most of the
- * settings/result/static info metadata. Specifically, only the following settings
- * are expected to be consumed or produced by a limited-mode HAL device:
- *
- * android.control.aeAntibandingMode (controls and dynamic)
- * android.control.aeExposureCompensation (controls and dynamic)
- * android.control.aeLock (controls and dynamic)
- * android.control.aeMode (controls and dynamic)
- * android.control.aeRegions (controls and dynamic)
- * android.control.aeTargetFpsRange (controls and dynamic)
- * android.control.aePrecaptureTrigger (controls and dynamic)
- * android.control.afMode (controls and dynamic)
- * android.control.afRegions (controls and dynamic)
- * android.control.awbLock (controls and dynamic)
- * android.control.awbMode (controls and dynamic)
- * android.control.awbRegions (controls and dynamic)
- * android.control.captureIntent (controls and dynamic)
- * android.control.effectMode (controls and dynamic)
- * android.control.mode (controls and dynamic)
- * android.control.sceneMode (controls and dynamic)
- * android.control.videoStabilizationMode (controls and dynamic)
- * android.control.aeAvailableAntibandingModes (static)
- * android.control.aeAvailableModes (static)
- * android.control.aeAvailableTargetFpsRanges (static)
- * android.control.aeCompensationRange (static)
- * android.control.aeCompensationStep (static)
- * android.control.afAvailableModes (static)
- * android.control.availableEffects (static)
- * android.control.availableSceneModes (static)
- * android.control.availableVideoStabilizationModes (static)
- * android.control.awbAvailableModes (static)
- * android.control.maxRegions (static)
- * android.control.sceneModeOverrides (static)
- * android.control.aeState (dynamic)
- * android.control.afState (dynamic)
- * android.control.awbState (dynamic)
- *
- * android.flash.mode (controls and dynamic)
- * android.flash.info.available (static)
- *
- * android.info.supportedHardwareLevel (static)
- *
- * android.jpeg.gpsCoordinates (controls and dynamic)
- * android.jpeg.gpsProcessingMethod (controls and dynamic)
- * android.jpeg.gpsTimestamp (controls and dynamic)
- * android.jpeg.orientation (controls and dynamic)
- * android.jpeg.quality (controls and dynamic)
- * android.jpeg.thumbnailQuality (controls and dynamic)
- * android.jpeg.thumbnailSize (controls and dynamic)
- * android.jpeg.availableThumbnailSizes (static)
- * android.jpeg.maxSize (static)
- *
- * android.lens.info.minimumFocusDistance (static)
- *
- * android.request.id (controls and dynamic)
- *
- * android.scaler.cropRegion (controls and dynamic)
- * android.scaler.availableStreamConfigurations (static)
- * android.scaler.availableMinFrameDurations (static)
- * android.scaler.availableStallDurations (static)
- * android.scaler.availableMaxDigitalZoom (static)
- * android.scaler.maxDigitalZoom (static)
- * android.scaler.croppingType (static)
- *
- * android.sensor.orientation (static)
- * android.sensor.timestamp (dynamic)
- *
- * android.statistics.faceDetectMode (controls and dynamic)
- * android.statistics.info.availableFaceDetectModes (static)
- * android.statistics.faceIds (dynamic)
- * android.statistics.faceLandmarks (dynamic)
- * android.statistics.faceRectangles (dynamic)
- * android.statistics.faceScores (dynamic)
- *
- * android.sync.frameNumber (dynamic)
- * android.sync.maxLatency (static)
- *
- * - Captures in limited mode that include high-resolution (> 1080p) output
- * buffers may block in process_capture_request() until all the output buffers
- * have been filled. A full-mode HAL device must process sequences of
- * high-resolution requests at the rate indicated in the static metadata for
- * that pixel format. The HAL must still call process_capture_result() to
- * provide the output; the framework must simply be prepared for
- * process_capture_request() to block until after process_capture_result() for
- * that request completes for high-resolution captures for limited-mode
- * devices.
- *
- * - Full-mode devices must support below additional capabilities:
- * - 30fps at maximum resolution is preferred, more than 20fps is required.
- * - Per frame control (android.sync.maxLatency == PER_FRAME_CONTROL).
- * - Sensor manual control metadata. See MANUAL_SENSOR defined in
- * android.request.availableCapabilities.
- * - Post-processing manual control metadata. See MANUAL_POST_PROCESSING defined
- * in android.request.availableCapabilities.
- *
- */
-
-/**
- * S4. 3A modes and state machines:
- *
- * While the actual 3A algorithms are up to the HAL implementation, a high-level
- * state machine description is defined by the HAL interface, to allow the HAL
- * device and the framework to communicate about the current state of 3A, and to
- * trigger 3A events.
- *
- * When the device is opened, all the individual 3A states must be
- * STATE_INACTIVE. Stream configuration does not reset 3A. For example, locked
- * focus must be maintained across the configure() call.
- *
- * Triggering a 3A action involves simply setting the relevant trigger entry in
- * the settings for the next request to indicate start of trigger. For example,
- * the trigger for starting an autofocus scan is setting the entry
- * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTROL_AF_TRIGGER_START for one
- * request, and cancelling an autofocus scan is triggered by setting
- * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTRL_AF_TRIGGER_CANCEL. Otherwise,
- * the entry will not exist, or be set to ANDROID_CONTROL_AF_TRIGGER_IDLE. Each
- * request with a trigger entry set to a non-IDLE value will be treated as an
- * independent triggering event.
- *
- * At the top level, 3A is controlled by the ANDROID_CONTROL_MODE setting, which
- * selects between no 3A (ANDROID_CONTROL_MODE_OFF), normal AUTO mode
- * (ANDROID_CONTROL_MODE_AUTO), and using the scene mode setting
- * (ANDROID_CONTROL_USE_SCENE_MODE).
- *
- * - In OFF mode, each of the individual AE/AF/AWB modes are effectively OFF,
- * and none of the capture controls may be overridden by the 3A routines.
- *
- * - In AUTO mode, Auto-focus, auto-exposure, and auto-whitebalance all run
- * their own independent algorithms, and have their own mode, state, and
- * trigger metadata entries, as listed in the next section.
- *
- * - In USE_SCENE_MODE, the value of the ANDROID_CONTROL_SCENE_MODE entry must
- * be used to determine the behavior of 3A routines. In SCENE_MODEs other than
- * FACE_PRIORITY, the HAL must override the values of
- * ANDROId_CONTROL_AE/AWB/AF_MODE to be the mode it prefers for the selected
- * SCENE_MODE. For example, the HAL may prefer SCENE_MODE_NIGHT to use
- * CONTINUOUS_FOCUS AF mode. Any user selection of AE/AWB/AF_MODE when scene
- * must be ignored for these scene modes.
- *
- * - For SCENE_MODE_FACE_PRIORITY, the AE/AWB/AF_MODE controls work as in
- * ANDROID_CONTROL_MODE_AUTO, but the 3A routines must bias toward metering
- * and focusing on any detected faces in the scene.
- *
- * S4.1. Auto-focus settings and result entries:
- *
- * Main metadata entries:
- *
- * ANDROID_CONTROL_AF_MODE: Control for selecting the current autofocus
- * mode. Set by the framework in the request settings.
- *
- * AF_MODE_OFF: AF is disabled; the framework/app directly controls lens
- * position.
- *
- * AF_MODE_AUTO: Single-sweep autofocus. No lens movement unless AF is
- * triggered.
- *
- * AF_MODE_MACRO: Single-sweep up-close autofocus. No lens movement unless
- * AF is triggered.
- *
- * AF_MODE_CONTINUOUS_VIDEO: Smooth continuous focusing, for recording
- * video. Triggering immediately locks focus in current
- * position. Canceling resumes cotinuous focusing.
- *
- * AF_MODE_CONTINUOUS_PICTURE: Fast continuous focusing, for
- * zero-shutter-lag still capture. Triggering locks focus once currently
- * active sweep concludes. Canceling resumes continuous focusing.
- *
- * AF_MODE_EDOF: Advanced extended depth of field focusing. There is no
- * autofocus scan, so triggering one or canceling one has no effect.
- * Images are focused automatically by the HAL.
- *
- * ANDROID_CONTROL_AF_STATE: Dynamic metadata describing the current AF
- * algorithm state, reported by the HAL in the result metadata.
- *
- * AF_STATE_INACTIVE: No focusing has been done, or algorithm was
- * reset. Lens is not moving. Always the state for MODE_OFF or MODE_EDOF.
- * When the device is opened, it must start in this state.
- *
- * AF_STATE_PASSIVE_SCAN: A continuous focus algorithm is currently scanning
- * for good focus. The lens is moving.
- *
- * AF_STATE_PASSIVE_FOCUSED: A continuous focus algorithm believes it is
- * well focused. The lens is not moving. The HAL may spontaneously leave
- * this state.
- *
- * AF_STATE_PASSIVE_UNFOCUSED: A continuous focus algorithm believes it is
- * not well focused. The lens is not moving. The HAL may spontaneously
- * leave this state.
- *
- * AF_STATE_ACTIVE_SCAN: A scan triggered by the user is underway.
- *
- * AF_STATE_FOCUSED_LOCKED: The AF algorithm believes it is focused. The
- * lens is not moving.
- *
- * AF_STATE_NOT_FOCUSED_LOCKED: The AF algorithm has been unable to
- * focus. The lens is not moving.
- *
- * ANDROID_CONTROL_AF_TRIGGER: Control for starting an autofocus scan, the
- * meaning of which is mode- and state- dependent. Set by the framework in
- * the request settings.
- *
- * AF_TRIGGER_IDLE: No current trigger.
- *
- * AF_TRIGGER_START: Trigger start of AF scan. Effect is mode and state
- * dependent.
- *
- * AF_TRIGGER_CANCEL: Cancel current AF scan if any, and reset algorithm to
- * default.
- *
- * Additional metadata entries:
- *
- * ANDROID_CONTROL_AF_REGIONS: Control for selecting the regions of the FOV
- * that should be used to determine good focus. This applies to all AF
- * modes that scan for focus. Set by the framework in the request
- * settings.
- *
- * S4.2. Auto-exposure settings and result entries:
- *
- * Main metadata entries:
- *
- * ANDROID_CONTROL_AE_MODE: Control for selecting the current auto-exposure
- * mode. Set by the framework in the request settings.
- *
- * AE_MODE_OFF: Autoexposure is disabled; the user controls exposure, gain,
- * frame duration, and flash.
- *
- * AE_MODE_ON: Standard autoexposure, with flash control disabled. User may
- * set flash to fire or to torch mode.
- *
- * AE_MODE_ON_AUTO_FLASH: Standard autoexposure, with flash on at HAL's
- * discretion for precapture and still capture. User control of flash
- * disabled.
- *
- * AE_MODE_ON_ALWAYS_FLASH: Standard autoexposure, with flash always fired
- * for capture, and at HAL's discretion for precapture.. User control of
- * flash disabled.
- *
- * AE_MODE_ON_AUTO_FLASH_REDEYE: Standard autoexposure, with flash on at
- * HAL's discretion for precapture and still capture. Use a flash burst
- * at end of precapture sequence to reduce redeye in the final
- * picture. User control of flash disabled.
- *
- * ANDROID_CONTROL_AE_STATE: Dynamic metadata describing the current AE
- * algorithm state, reported by the HAL in the result metadata.
- *
- * AE_STATE_INACTIVE: Initial AE state after mode switch. When the device is
- * opened, it must start in this state.
- *
- * AE_STATE_SEARCHING: AE is not converged to a good value, and is adjusting
- * exposure parameters.
- *
- * AE_STATE_CONVERGED: AE has found good exposure values for the current
- * scene, and the exposure parameters are not changing. HAL may
- * spontaneously leave this state to search for better solution.
- *
- * AE_STATE_LOCKED: AE has been locked with the AE_LOCK control. Exposure
- * values are not changing.
- *
- * AE_STATE_FLASH_REQUIRED: The HAL has converged exposure, but believes
- * flash is required for a sufficiently bright picture. Used for
- * determining if a zero-shutter-lag frame can be used.
- *
- * AE_STATE_PRECAPTURE: The HAL is in the middle of a precapture
- * sequence. Depending on AE mode, this mode may involve firing the
- * flash for metering, or a burst of flash pulses for redeye reduction.
- *
- * ANDROID_CONTROL_AE_PRECAPTURE_TRIGGER: Control for starting a metering
- * sequence before capturing a high-quality image. Set by the framework in
- * the request settings.
- *
- * PRECAPTURE_TRIGGER_IDLE: No current trigger.
- *
- * PRECAPTURE_TRIGGER_START: Start a precapture sequence. The HAL should
- * use the subsequent requests to measure good exposure/white balance
- * for an upcoming high-resolution capture.
- *
- * Additional metadata entries:
- *
- * ANDROID_CONTROL_AE_LOCK: Control for locking AE controls to their current
- * values
- *
- * ANDROID_CONTROL_AE_EXPOSURE_COMPENSATION: Control for adjusting AE
- * algorithm target brightness point.
- *
- * ANDROID_CONTROL_AE_TARGET_FPS_RANGE: Control for selecting the target frame
- * rate range for the AE algorithm. The AE routine cannot change the frame
- * rate to be outside these bounds.
- *
- * ANDROID_CONTROL_AE_REGIONS: Control for selecting the regions of the FOV
- * that should be used to determine good exposure levels. This applies to
- * all AE modes besides OFF.
- *
- * S4.3. Auto-whitebalance settings and result entries:
- *
- * Main metadata entries:
- *
- * ANDROID_CONTROL_AWB_MODE: Control for selecting the current white-balance
- * mode.
- *
- * AWB_MODE_OFF: Auto-whitebalance is disabled. User controls color matrix.
- *
- * AWB_MODE_AUTO: Automatic white balance is enabled; 3A controls color
- * transform, possibly using more complex transforms than a simple
- * matrix.
- *
- * AWB_MODE_INCANDESCENT: Fixed white balance settings good for indoor
- * incandescent (tungsten) lighting, roughly 2700K.
- *
- * AWB_MODE_FLUORESCENT: Fixed white balance settings good for fluorescent
- * lighting, roughly 5000K.
- *
- * AWB_MODE_WARM_FLUORESCENT: Fixed white balance settings good for
- * fluorescent lighting, roughly 3000K.
- *
- * AWB_MODE_DAYLIGHT: Fixed white balance settings good for daylight,
- * roughly 5500K.
- *
- * AWB_MODE_CLOUDY_DAYLIGHT: Fixed white balance settings good for clouded
- * daylight, roughly 6500K.
- *
- * AWB_MODE_TWILIGHT: Fixed white balance settings good for
- * near-sunset/sunrise, roughly 15000K.
- *
- * AWB_MODE_SHADE: Fixed white balance settings good for areas indirectly
- * lit by the sun, roughly 7500K.
- *
- * ANDROID_CONTROL_AWB_STATE: Dynamic metadata describing the current AWB
- * algorithm state, reported by the HAL in the result metadata.
- *
- * AWB_STATE_INACTIVE: Initial AWB state after mode switch. When the device
- * is opened, it must start in this state.
- *
- * AWB_STATE_SEARCHING: AWB is not converged to a good value, and is
- * changing color adjustment parameters.
- *
- * AWB_STATE_CONVERGED: AWB has found good color adjustment values for the
- * current scene, and the parameters are not changing. HAL may
- * spontaneously leave this state to search for better solution.
- *
- * AWB_STATE_LOCKED: AWB has been locked with the AWB_LOCK control. Color
- * adjustment values are not changing.
- *
- * Additional metadata entries:
- *
- * ANDROID_CONTROL_AWB_LOCK: Control for locking AWB color adjustments to
- * their current values.
- *
- * ANDROID_CONTROL_AWB_REGIONS: Control for selecting the regions of the FOV
- * that should be used to determine good color balance. This applies only
- * to auto-WB mode.
- *
- * S4.4. General state machine transition notes
- *
- * Switching between AF, AE, or AWB modes always resets the algorithm's state
- * to INACTIVE. Similarly, switching between CONTROL_MODE or
- * CONTROL_SCENE_MODE if CONTROL_MODE == USE_SCENE_MODE resets all the
- * algorithm states to INACTIVE.
- *
- * The tables below are per-mode.
- *
- * S4.5. AF state machines
- *
- * when enabling AF or changing AF mode
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| Any | AF mode change| INACTIVE | |
- *+--------------------+---------------+--------------------+------------------+
- *
- * mode = AF_MODE_OFF or AF_MODE_EDOF
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | | INACTIVE | Never changes |
- *+--------------------+---------------+--------------------+------------------+
- *
- * mode = AF_MODE_AUTO or AF_MODE_MACRO
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | AF_TRIGGER | ACTIVE_SCAN | Start AF sweep |
- *| | | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| ACTIVE_SCAN | AF sweep done | FOCUSED_LOCKED | If AF successful |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| ACTIVE_SCAN | AF sweep done | NOT_FOCUSED_LOCKED | If AF successful |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| ACTIVE_SCAN | AF_CANCEL | INACTIVE | Cancel/reset AF |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Cancel/reset AF |
- *+--------------------+---------------+--------------------+------------------+
- *| FOCUSED_LOCKED | AF_TRIGGER | ACTIVE_SCAN | Start new sweep |
- *| | | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Cancel/reset AF |
- *+--------------------+---------------+--------------------+------------------+
- *| NOT_FOCUSED_LOCKED | AF_TRIGGER | ACTIVE_SCAN | Start new sweep |
- *| | | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| All states | mode change | INACTIVE | |
- *+--------------------+---------------+--------------------+------------------+
- *
- * mode = AF_MODE_CONTINUOUS_VIDEO
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | HAL initiates | PASSIVE_SCAN | Start AF scan |
- *| | new scan | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | AF_TRIGGER | NOT_FOCUSED_LOCKED | AF state query |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | HAL completes | PASSIVE_FOCUSED | End AF scan |
- *| | current scan | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | HAL fails | PASSIVE_UNFOCUSED | End AF scan |
- *| | current scan | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
- *| | | | if focus is good |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
- *| | | | if focus is bad |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | AF_CANCEL | INACTIVE | Reset lens |
- *| | | | position |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_FOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
- *| | new scan | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_UNFOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
- *| | new scan | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_FOCUSED | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_UNFOCUSED | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| FOCUSED_LOCKED | AF_TRIGGER | FOCUSED_LOCKED | No effect |
- *+--------------------+---------------+--------------------+------------------+
- *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
- *+--------------------+---------------+--------------------+------------------+
- *| NOT_FOCUSED_LOCKED | AF_TRIGGER | NOT_FOCUSED_LOCKED | No effect |
- *+--------------------+---------------+--------------------+------------------+
- *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
- *+--------------------+---------------+--------------------+------------------+
- *
- * mode = AF_MODE_CONTINUOUS_PICTURE
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | HAL initiates | PASSIVE_SCAN | Start AF scan |
- *| | new scan | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | AF_TRIGGER | NOT_FOCUSED_LOCKED | AF state query |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | HAL completes | PASSIVE_FOCUSED | End AF scan |
- *| | current scan | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | HAL fails | PASSIVE_UNFOCUSED | End AF scan |
- *| | current scan | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | AF_TRIGGER | FOCUSED_LOCKED | Eventual trans. |
- *| | | | once focus good |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | AF_TRIGGER | NOT_FOCUSED_LOCKED | Eventual trans. |
- *| | | | if cannot focus |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_SCAN | AF_CANCEL | INACTIVE | Reset lens |
- *| | | | position |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_FOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
- *| | new scan | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_UNFOCUSED | HAL initiates | PASSIVE_SCAN | Start AF scan |
- *| | new scan | | Lens now moving |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_FOCUSED | AF_TRIGGER | FOCUSED_LOCKED | Immediate trans. |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| PASSIVE_UNFOCUSED | AF_TRIGGER | NOT_FOCUSED_LOCKED | Immediate trans. |
- *| | | | Lens now locked |
- *+--------------------+---------------+--------------------+------------------+
- *| FOCUSED_LOCKED | AF_TRIGGER | FOCUSED_LOCKED | No effect |
- *+--------------------+---------------+--------------------+------------------+
- *| FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
- *+--------------------+---------------+--------------------+------------------+
- *| NOT_FOCUSED_LOCKED | AF_TRIGGER | NOT_FOCUSED_LOCKED | No effect |
- *+--------------------+---------------+--------------------+------------------+
- *| NOT_FOCUSED_LOCKED | AF_CANCEL | INACTIVE | Restart AF scan |
- *+--------------------+---------------+--------------------+------------------+
- *
- * S4.6. AE and AWB state machines
- *
- * The AE and AWB state machines are mostly identical. AE has additional
- * FLASH_REQUIRED and PRECAPTURE states. So rows below that refer to those two
- * states should be ignored for the AWB state machine.
- *
- * when enabling AE/AWB or changing AE/AWB mode
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| Any | mode change | INACTIVE | |
- *+--------------------+---------------+--------------------+------------------+
- *
- * mode = AE_MODE_OFF / AWB mode not AUTO
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | | INACTIVE | AE/AWB disabled |
- *+--------------------+---------------+--------------------+------------------+
- *
- * mode = AE_MODE_ON_* / AWB_MODE_AUTO
- *| state | trans. cause | new state | notes |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | HAL initiates | SEARCHING | |
- *| | AE/AWB scan | | |
- *+--------------------+---------------+--------------------+------------------+
- *| INACTIVE | AE/AWB_LOCK | LOCKED | values locked |
- *| | on | | |
- *+--------------------+---------------+--------------------+------------------+
- *| SEARCHING | HAL finishes | CONVERGED | good values, not |
- *| | AE/AWB scan | | changing |
- *+--------------------+---------------+--------------------+------------------+
- *| SEARCHING | HAL finishes | FLASH_REQUIRED | converged but too|
- *| | AE scan | | dark w/o flash |
- *+--------------------+---------------+--------------------+------------------+
- *| SEARCHING | AE/AWB_LOCK | LOCKED | values locked |
- *| | on | | |
- *+--------------------+---------------+--------------------+------------------+
- *| CONVERGED | HAL initiates | SEARCHING | values locked |
- *| | AE/AWB scan | | |
- *+--------------------+---------------+--------------------+------------------+
- *| CONVERGED | AE/AWB_LOCK | LOCKED | values locked |
- *| | on | | |
- *+--------------------+---------------+--------------------+------------------+
- *| FLASH_REQUIRED | HAL initiates | SEARCHING | values locked |
- *| | AE/AWB scan | | |
- *+--------------------+---------------+--------------------+------------------+
- *| FLASH_REQUIRED | AE/AWB_LOCK | LOCKED | values locked |
- *| | on | | |
- *+--------------------+---------------+--------------------+------------------+
- *| LOCKED | AE/AWB_LOCK | SEARCHING | values not good |
- *| | off | | after unlock |
- *+--------------------+---------------+--------------------+------------------+
- *| LOCKED | AE/AWB_LOCK | CONVERGED | values good |
- *| | off | | after unlock |
- *+--------------------+---------------+--------------------+------------------+
- *| LOCKED | AE_LOCK | FLASH_REQUIRED | exposure good, |
- *| | off | | but too dark |
- *+--------------------+---------------+--------------------+------------------+
- *| All AE states | PRECAPTURE_ | PRECAPTURE | Start precapture |
- *| | START | | sequence |
- *+--------------------+---------------+--------------------+------------------+
- *| PRECAPTURE | Sequence done.| CONVERGED | Ready for high- |
- *| | AE_LOCK off | | quality capture |
- *+--------------------+---------------+--------------------+------------------+
- *| PRECAPTURE | Sequence done.| LOCKED | Ready for high- |
- *| | AE_LOCK on | | quality capture |
- *+--------------------+---------------+--------------------+------------------+
- *
- */
-
-/**
- * S5. Cropping:
- *
- * Cropping of the full pixel array (for digital zoom and other use cases where
- * a smaller FOV is desirable) is communicated through the
- * ANDROID_SCALER_CROP_REGION setting. This is a per-request setting, and can
- * change on a per-request basis, which is critical for implementing smooth
- * digital zoom.
- *
- * The region is defined as a rectangle (x, y, width, height), with (x, y)
- * describing the top-left corner of the rectangle. The rectangle is defined on
- * the coordinate system of the sensor active pixel array, with (0,0) being the
- * top-left pixel of the active pixel array. Therefore, the width and height
- * cannot be larger than the dimensions reported in the
- * ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY static info field. The minimum allowed
- * width and height are reported by the HAL through the
- * ANDROID_SCALER_MAX_DIGITAL_ZOOM static info field, which describes the
- * maximum supported zoom factor. Therefore, the minimum crop region width and
- * height are:
- *
- * {width, height} =
- * { floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[0] /
- * ANDROID_SCALER_MAX_DIGITAL_ZOOM),
- * floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[1] /
- * ANDROID_SCALER_MAX_DIGITAL_ZOOM) }
- *
- * If the crop region needs to fulfill specific requirements (for example, it
- * needs to start on even coordinates, and its width/height needs to be even),
- * the HAL must do the necessary rounding and write out the final crop region
- * used in the output result metadata. Similarly, if the HAL implements video
- * stabilization, it must adjust the result crop region to describe the region
- * actually included in the output after video stabilization is applied. In
- * general, a camera-using application must be able to determine the field of
- * view it is receiving based on the crop region, the dimensions of the image
- * sensor, and the lens focal length.
- *
- * It is assumed that the cropping is applied after raw to other color space
- * conversion. Raw streams (RAW16 and RAW_OPAQUE) don't have this conversion stage,
- * and are not croppable. Therefore, the crop region must be ignored by the HAL
- * for raw streams.
- *
- * Since the crop region applies to all non-raw streams, which may have different aspect
- * ratios than the crop region, the exact sensor region used for each stream may
- * be smaller than the crop region. Specifically, each stream should maintain
- * square pixels and its aspect ratio by minimally further cropping the defined
- * crop region. If the stream's aspect ratio is wider than the crop region, the
- * stream should be further cropped vertically, and if the stream's aspect ratio
- * is narrower than the crop region, the stream should be further cropped
- * horizontally.
- *
- * In all cases, the stream crop must be centered within the full crop region,
- * and each stream is only either cropped horizontally or vertical relative to
- * the full crop region, never both.
- *
- * For example, if two streams are defined, a 640x480 stream (4:3 aspect), and a
- * 1280x720 stream (16:9 aspect), below demonstrates the expected output regions
- * for each stream for a few sample crop regions, on a hypothetical 3 MP (2000 x
- * 1500 pixel array) sensor.
- *
- * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
- *
- * 640x480 stream crop: (500, 375, 1000, 750) (equal to crop region)
- * 1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
- *
- * 0 1000 2000
- * +---------+---------+---------+----------+
- * | Active pixel array |
- * | |
- * | |
- * + +-------------------+ + 375
- * | | | |
- * | O===================O |
- * | I 1280x720 stream I |
- * + I I + 750
- * | I I |
- * | O===================O |
- * | | | |
- * + +-------------------+ + 1125
- * | Crop region, 640x480 stream |
- * | |
- * | |
- * +---------+---------+---------+----------+ 1500
- *
- * Crop region: (500, 375, 1333, 750) (16:9 aspect ratio)
- *
- * 640x480 stream crop: (666, 375, 1000, 750) (marked with =)
- * 1280x720 stream crop: (500, 375, 1333, 750) (equal to crop region)
- *
- * 0 1000 2000
- * +---------+---------+---------+----------+
- * | Active pixel array |
- * | |
- * | |
- * + +---O==================O---+ + 375
- * | | I 640x480 stream I | |
- * | | I I | |
- * | | I I | |
- * + | I I | + 750
- * | | I I | |
- * | | I I | |
- * | | I I | |
- * + +---O==================O---+ + 1125
- * | Crop region, 1280x720 stream |
- * | |
- * | |
- * +---------+---------+---------+----------+ 1500
- *
- * Crop region: (500, 375, 750, 750) (1:1 aspect ratio)
- *
- * 640x480 stream crop: (500, 469, 750, 562) (marked with =)
- * 1280x720 stream crop: (500, 543, 750, 414) (marged with #)
- *
- * 0 1000 2000
- * +---------+---------+---------+----------+
- * | Active pixel array |
- * | |
- * | |
- * + +--------------+ + 375
- * | O==============O |
- * | ################ |
- * | # # |
- * + # # + 750
- * | # # |
- * | ################ 1280x720 |
- * | O==============O 640x480 |
- * + +--------------+ + 1125
- * | Crop region |
- * | |
- * | |
- * +---------+---------+---------+----------+ 1500
- *
- * And a final example, a 1024x1024 square aspect ratio stream instead of the
- * 480p stream:
- *
- * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
- *
- * 1024x1024 stream crop: (625, 375, 750, 750) (marked with #)
- * 1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
- *
- * 0 1000 2000
- * +---------+---------+---------+----------+
- * | Active pixel array |
- * | |
- * | 1024x1024 stream |
- * + +--###############--+ + 375
- * | | # # | |
- * | O===================O |
- * | I 1280x720 stream I |
- * + I I + 750
- * | I I |
- * | O===================O |
- * | | # # | |
- * + +--###############--+ + 1125
- * | Crop region |
- * | |
- * | |
- * +---------+---------+---------+----------+ 1500
- *
- */
-
-/**
- * S6. Error management:
- *
- * Camera HAL device ops functions that have a return value will all return
- * -ENODEV / NULL in case of a serious error. This means the device cannot
- * continue operation, and must be closed by the framework. Once this error is
- * returned by some method, or if notify() is called with ERROR_DEVICE, only
- * the close() method can be called successfully. All other methods will return
- * -ENODEV / NULL.
- *
- * If a device op is called in the wrong sequence, for example if the framework
- * calls configure_streams() is called before initialize(), the device must
- * return -ENOSYS from the call, and do nothing.
- *
- * Transient errors in image capture must be reported through notify() as follows:
- *
- * - The failure of an entire capture to occur must be reported by the HAL by
- * calling notify() with ERROR_REQUEST. Individual errors for the result
- * metadata or the output buffers must not be reported in this case.
- *
- * - If the metadata for a capture cannot be produced, but some image buffers
- * were filled, the HAL must call notify() with ERROR_RESULT.
- *
- * - If an output image buffer could not be filled, but either the metadata was
- * produced or some other buffers were filled, the HAL must call notify() with
- * ERROR_BUFFER for each failed buffer.
- *
- * In each of these transient failure cases, the HAL must still call
- * process_capture_result, with valid output and input (if an input buffer was
- * submitted) buffer_handle_t. If the result metadata could not be produced, it
- * should be NULL. If some buffers could not be filled, they must be returned with
- * process_capture_result in the error state, their release fences must be set to
- * the acquire fences passed by the framework, or -1 if they have been waited on by
- * the HAL already.
- *
- * Invalid input arguments result in -EINVAL from the appropriate methods. In
- * that case, the framework must act as if that call had never been made.
- *
- */
-
-/**
- * S7. Key Performance Indicator (KPI) glossary:
- *
- * This includes some critical definitions that are used by KPI metrics.
- *
- * Pipeline Latency:
- * For a given capture request, the duration from the framework calling
- * process_capture_request to the HAL sending capture result and all buffers
- * back by process_capture_result call. To make the Pipeline Latency measure
- * independent of frame rate, it is measured by frame count.
- *
- * For example, when frame rate is 30 (fps), the frame duration (time interval
- * between adjacent frame capture time) is 33 (ms).
- * If it takes 5 frames for framework to get the result and buffers back for
- * a given request, then the Pipeline Latency is 5 (frames), instead of
- * 5 x 33 = 165 (ms).
- *
- * The Pipeline Latency is determined by android.request.pipelineDepth and
- * android.request.pipelineMaxDepth, see their definitions for more details.
- *
- */
-
-/**
- * S8. Sample Use Cases:
- *
- * This includes some typical use case examples the camera HAL may support.
- *
- * S8.1 Zero Shutter Lag (ZSL) with CAMERA3_STREAM_BIDIRECTIONAL stream.
- *
- * For this use case, the bidirectional stream will be used by the framework as follows:
- *
- * 1. The framework includes a buffer from this stream as output buffer in a
- * request as normal.
- *
- * 2. Once the HAL device returns a filled output buffer to the framework,
- * the framework may do one of two things with the filled buffer:
- *
- * 2. a. The framework uses the filled data, and returns the now-used buffer
- * to the stream queue for reuse. This behavior exactly matches the
- * OUTPUT type of stream.
- *
- * 2. b. The framework wants to reprocess the filled data, and uses the
- * buffer as an input buffer for a request. Once the HAL device has
- * used the reprocessing buffer, it then returns it to the
- * framework. The framework then returns the now-used buffer to the
- * stream queue for reuse.
- *
- * 3. The HAL device will be given the buffer again as an output buffer for
- * a request at some future point.
- *
- * For ZSL use case, the pixel format for bidirectional stream will be
- * HAL_PIXEL_FORMAT_RAW_OPAQUE or HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED if it
- * is listed in android.scaler.availableInputOutputFormatsMap. When
- * HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, the gralloc
- * usage flags for the consumer endpoint will be set to GRALLOC_USAGE_HW_CAMERA_ZSL.
- * A configuration stream list that has BIDIRECTIONAL stream used as input, will
- * usually also have a distinct OUTPUT stream to get the reprocessing data. For example,
- * for the ZSL use case, the stream list might be configured with the following:
- *
- * - A HAL_PIXEL_FORMAT_RAW_OPAQUE bidirectional stream is used
- * as input.
- * - And a HAL_PIXEL_FORMAT_BLOB (JPEG) output stream.
- *
- * S8.2 ZSL (OPAQUE) reprocessing with CAMERA3_STREAM_INPUT stream.
- *
- * CAMERA_DEVICE_API_VERSION_3_3:
- * When OPAQUE_REPROCESSING capability is supported by the camera device, the INPUT stream
- * can be used for application/framework implemented use case like Zero Shutter Lag (ZSL).
- * This kind of stream will be used by the framework as follows:
- *
- * 1. Application/framework configures an opaque (RAW or YUV based) format output stream that is
- * used to produce the ZSL output buffers. The stream pixel format will be
- * HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED.
- *
- * 2. Application/framework configures an opaque format input stream that is used to
- * send the reprocessing ZSL buffers to the HAL. The stream pixel format will
- * also be HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED.
- *
- * 3. Application/framework configures a YUV/JPEG output stream that is used to receive the
- * reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
- *
- * 4. Application/framework picks a ZSL buffer from the ZSL output stream when a ZSL capture is
- * issued by the application, and sends the data back as an input buffer in a
- * reprocessing request, then sends to the HAL for reprocessing.
- *
- * 5. The HAL sends back the output YUV/JPEG result to framework.
- *
- * The HAL can select the actual opaque buffer format and configure the ISP pipeline
- * appropriately based on the HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format and
- * the gralloc usage flag GRALLOC_USAGE_HW_CAMERA_ZSL.
-
- * S8.3 YUV reprocessing with CAMERA3_STREAM_INPUT stream.
- *
- * When YUV reprocessing is supported by the HAL, the INPUT stream
- * can be used for the YUV reprocessing use cases like lucky-shot and image fusion.
- * This kind of stream will be used by the framework as follows:
- *
- * 1. Application/framework configures an YCbCr_420 format output stream that is
- * used to produce the output buffers.
- *
- * 2. Application/framework configures an YCbCr_420 format input stream that is used to
- * send the reprocessing YUV buffers to the HAL.
- *
- * 3. Application/framework configures a YUV/JPEG output stream that is used to receive the
- * reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
- *
- * 4. Application/framework processes the output buffers (could be as simple as picking
- * an output buffer directly) from the output stream when a capture is issued, and sends
- * the data back as an input buffer in a reprocessing request, then sends to the HAL
- * for reprocessing.
- *
- * 5. The HAL sends back the output YUV/JPEG result to framework.
- *
- */
-
-/**
- * S9. Notes on Controls and Metadata
- *
- * This section contains notes about the interpretation and usage of various metadata tags.
- *
- * S9.1 HIGH_QUALITY and FAST modes.
- *
- * Many camera post-processing blocks may be listed as having HIGH_QUALITY,
- * FAST, and OFF operating modes. These blocks will typically also have an
- * 'available modes' tag representing which of these operating modes are
- * available on a given device. The general policy regarding implementing
- * these modes is as follows:
- *
- * 1. Operating mode controls of hardware blocks that cannot be disabled
- * must not list OFF in their corresponding 'available modes' tags.
- *
- * 2. OFF will always be included in their corresponding 'available modes'
- * tag if it is possible to disable that hardware block.
- *
- * 3. FAST must always be included in the 'available modes' tags for all
- * post-processing blocks supported on the device. If a post-processing
- * block also has a slower and higher quality operating mode that does
- * not meet the framerate requirements for FAST mode, HIGH_QUALITY should
- * be included in the 'available modes' tag to represent this operating
- * mode.
- */
-
-/**
- * S10. Reprocessing flow and controls
- *
- * This section describes the OPAQUE and YUV reprocessing flow and controls. OPAQUE reprocessing
- * uses an opaque format that is not directly application-visible, and the application can
- * only select some of the output buffers and send back to HAL for reprocessing, while YUV
- * reprocessing gives the application opportunity to process the buffers before reprocessing.
- *
- * S8 gives the stream configurations for the typical reprocessing uses cases,
- * this section specifies the buffer flow and controls in more details.
- *
- * S10.1 OPAQUE (typically for ZSL use case) reprocessing flow and controls
- *
- * For OPAQUE reprocessing (e.g. ZSL) use case, after the application creates the specific
- * output and input streams, runtime buffer flow and controls are specified as below:
- *
- * 1. Application starts output streaming by sending repeating requests for output
- * opaque buffers and preview. The buffers are held by an application
- * maintained circular buffer. The requests are based on CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG
- * capture template, which should have all necessary settings that guarantee output
- * frame rate is not slowed down relative to sensor output frame rate.
- *
- * 2. When a capture is issued, the application selects one output buffer based
- * on application buffer selection logic, e.g. good AE and AF statistics etc.
- * Application then creates an reprocess request based on the capture result associated
- * with this selected buffer. The selected output buffer is now added to this reprocess
- * request as an input buffer, the output buffer of this reprocess request should be
- * either JPEG output buffer or YUV output buffer, or both, depending on the application
- * choice.
- *
- * 3. Application then alters the reprocess settings to get best image quality. The HAL must
- * support and only support below controls if the HAL support OPAQUE_REPROCESSING capability:
- * - android.jpeg.* (if JPEG buffer is included as one of the output)
- * - android.noiseReduction.mode (change to HIGH_QUALITY if it is supported)
- * - android.edge.mode (change to HIGH_QUALITY if it is supported)
- * All other controls must be ignored by the HAL.
- * 4. HAL processed the input buffer and return the output buffers in the capture results
- * as normal.
- *
- * S10.2 YUV reprocessing flow and controls
- *
- * The YUV reprocessing buffer flow is similar as OPAQUE reprocessing, with below difference:
- *
- * 1. Application may want to have finer granularity control of the intermediate YUV images
- * (before reprocessing). For example, application may choose
- * - android.noiseReduction.mode == MINIMAL
- * to make sure the no YUV domain noise reduction has applied to the output YUV buffers,
- * then it can do its own advanced noise reduction on them. For OPAQUE reprocessing case, this
- * doesn't matter, as long as the final reprocessed image has the best quality.
- * 2. Application may modify the YUV output buffer data. For example, for image fusion use
- * case, where multiple output images are merged together to improve the signal-to-noise
- * ratio (SNR). The input buffer may be generated from multiple buffers by the application.
- * To avoid excessive amount of noise reduction and insufficient amount of edge enhancement
- * being applied to the input buffer, the application can hint the HAL how much effective
- * exposure time improvement has been done by the application, then the HAL can adjust the
- * noise reduction and edge enhancement parameters to get best reprocessed image quality.
- * Below tag can be used for this purpose:
- * - android.reprocess.effectiveExposureFactor
- * The value would be exposure time increase factor applied to the original output image,
- * for example, if there are N image merged, the exposure time increase factor would be up
- * to sqrt(N). See this tag spec for more details.
- *
- * S10.3 Reprocessing pipeline characteristics
- *
- * Reprocessing pipeline has below different characteristics comparing with normal output
- * pipeline:
- *
- * 1. The reprocessing result can be returned ahead of the pending normal output results. But
- * the FIFO ordering must be maintained for all reprocessing results. For example, there are
- * below requests (A stands for output requests, B stands for reprocessing requests)
- * being processed by the HAL:
- * A1, A2, A3, A4, B1, A5, B2, A6...
- * result of B1 can be returned before A1-A4, but result of B2 must be returned after B1.
- * 2. Single input rule: For a given reprocessing request, all output buffers must be from the
- * input buffer, rather than sensor output. For example, if a reprocess request include both
- * JPEG and preview buffers, all output buffers must be produced from the input buffer
- * included by the reprocessing request, rather than sensor. The HAL must not output preview
- * buffers from sensor, while output JPEG buffer from the input buffer.
- * 3. Input buffer will be from camera output directly (ZSL case) or indirectly(image fusion
- * case). For the case where buffer is modified, the size will remain same. The HAL can
- * notify CAMERA3_MSG_ERROR_REQUEST if buffer from unknown source is sent.
- * 4. Result as reprocessing request: The HAL can expect that a reprocessing request is a copy
- * of one of the output results with minor allowed setting changes. The HAL can notify
- * CAMERA3_MSG_ERROR_REQUEST if a request from unknown source is issued.
- * 5. Output buffers may not be used as inputs across the configure stream boundary, This is
- * because an opaque stream like the ZSL output stream may have different actual image size
- * inside of the ZSL buffer to save power and bandwidth for smaller resolution JPEG capture.
- * The HAL may notify CAMERA3_MSG_ERROR_REQUEST if this case occurs.
- * 6. HAL Reprocess requests error reporting during flush should follow the same rule specified
- * by flush() method.
- *
- */
-
-__BEGIN_DECLS
-
-struct camera3_device;
-
-/**********************************************************************
- *
- * Camera3 stream and stream buffer definitions.
- *
- * These structs and enums define the handles and contents of the input and
- * output streams connecting the HAL to various framework and application buffer
- * consumers. Each stream is backed by a gralloc buffer queue.
- *
- */
-
-/**
- * camera3_stream_type_t:
- *
- * The type of the camera stream, which defines whether the camera HAL device is
- * the producer or the consumer for that stream, and how the buffers of the
- * stream relate to the other streams.
- */
-typedef enum camera3_stream_type {
- /**
- * This stream is an output stream; the camera HAL device will be
- * responsible for filling buffers from this stream with newly captured or
- * reprocessed image data.
- */
- CAMERA3_STREAM_OUTPUT = 0,
-
- /**
- * This stream is an input stream; the camera HAL device will be responsible
- * for reading buffers from this stream and sending them through the camera
- * processing pipeline, as if the buffer was a newly captured image from the
- * imager.
- *
- * The pixel format for input stream can be any format reported by
- * android.scaler.availableInputOutputFormatsMap. The pixel format of the
- * output stream that is used to produce the reprocessing data may be any
- * format reported by android.scaler.availableStreamConfigurations. The
- * supported input/output stream combinations depends the camera device
- * capabilities, see android.scaler.availableInputOutputFormatsMap for
- * stream map details.
- *
- * This kind of stream is generally used to reprocess data into higher
- * quality images (that otherwise would cause a frame rate performance
- * loss), or to do off-line reprocessing.
- *
- * CAMERA_DEVICE_API_VERSION_3_3:
- * The typical use cases are OPAQUE (typically ZSL) and YUV reprocessing,
- * see S8.2, S8.3 and S10 for more details.
- */
- CAMERA3_STREAM_INPUT = 1,
-
- /**
- * This stream can be used for input and output. Typically, the stream is
- * used as an output stream, but occasionally one already-filled buffer may
- * be sent back to the HAL device for reprocessing.
- *
- * This kind of stream is meant generally for Zero Shutter Lag (ZSL)
- * features, where copying the captured image from the output buffer to the
- * reprocessing input buffer would be expensive. See S8.1 for more details.
- *
- * Note that the HAL will always be reprocessing data it produced.
- *
- */
- CAMERA3_STREAM_BIDIRECTIONAL = 2,
-
- /**
- * Total number of framework-defined stream types
- */
- CAMERA3_NUM_STREAM_TYPES
-
-} camera3_stream_type_t;
-
-/**
- * camera3_stream_rotation_t:
- *
- * The required counterclockwise rotation of camera stream.
- */
-typedef enum camera3_stream_rotation {
- /* No rotation */
- CAMERA3_STREAM_ROTATION_0 = 0,
-
- /* Rotate by 90 degree counterclockwise */
- CAMERA3_STREAM_ROTATION_90 = 1,
-
- /* Rotate by 180 degree counterclockwise */
- CAMERA3_STREAM_ROTATION_180 = 2,
-
- /* Rotate by 270 degree counterclockwise */
- CAMERA3_STREAM_ROTATION_270 = 3
-} camera3_stream_rotation_t;
-
-/**
- * camera3_stream_configuration_mode_t:
- *
- * This defines the general operation mode for the HAL (for a given stream configuration), where
- * modes besides NORMAL have different semantics, and usually limit the generality of the API in
- * exchange for higher performance in some particular area.
- */
-typedef enum camera3_stream_configuration_mode {
- /**
- * Normal stream configuration operation mode. This is the default camera operation mode,
- * where all semantics of HAL APIs and metadata controls apply.
- */
- CAMERA3_STREAM_CONFIGURATION_NORMAL_MODE = 0,
-
- /**
- * Special constrained high speed operation mode for devices that can not support high
- * speed output in NORMAL mode. All streams in this configuration are operating at high speed
- * mode and have different characteristics and limitations to achieve high speed output.
- * The NORMAL mode can still be used for high speed output if the HAL can support high speed
- * output while satisfying all the semantics of HAL APIs and metadata controls. It is
- * recommended for the HAL to support high speed output in NORMAL mode (by advertising the high
- * speed FPS ranges in android.control.aeAvailableTargetFpsRanges) if possible.
- *
- * This mode has below limitations/requirements:
- *
- * 1. The HAL must support up to 2 streams with sizes reported by
- * android.control.availableHighSpeedVideoConfigurations.
- * 2. In this mode, the HAL is expected to output up to 120fps or higher. This mode must
- * support the targeted FPS range and size configurations reported by
- * android.control.availableHighSpeedVideoConfigurations.
- * 3. The HAL must support HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED output stream format.
- * 4. To achieve efficient high speed streaming, the HAL may have to aggregate
- * multiple frames together and send to camera device for processing where the request
- * controls are same for all the frames in this batch (batch mode). The HAL must support
- * max batch size and the max batch size requirements defined by
- * android.control.availableHighSpeedVideoConfigurations.
- * 5. In this mode, the HAL must override aeMode, awbMode, and afMode to ON, ON, and
- * CONTINUOUS_VIDEO, respectively. All post-processing block mode controls must be
- * overridden to be FAST. Therefore, no manual control of capture and post-processing
- * parameters is possible. All other controls operate the same as when
- * android.control.mode == AUTO. This means that all other android.control.* fields
- * must continue to work, such as
- *
- * android.control.aeTargetFpsRange
- * android.control.aeExposureCompensation
- * android.control.aeLock
- * android.control.awbLock
- * android.control.effectMode
- * android.control.aeRegions
- * android.control.afRegions
- * android.control.awbRegions
- * android.control.afTrigger
- * android.control.aePrecaptureTrigger
- *
- * Outside of android.control.*, the following controls must work:
- *
- * android.flash.mode (TORCH mode only, automatic flash for still capture will not work
- * since aeMode is ON)
- * android.lens.opticalStabilizationMode (if it is supported)
- * android.scaler.cropRegion
- * android.statistics.faceDetectMode (if it is supported)
- * 6. To reduce the amount of data passed across process boundaries at
- * high frame rate, within one batch, camera framework only propagates
- * the last shutter notify and the last capture results (including partial
- * results and final result) to the app. The shutter notifies and capture
- * results for the other requests in the batch are derived by
- * the camera framework. As a result, the HAL can return empty metadata
- * except for the last result in the batch.
- *
- * For more details about high speed stream requirements, see
- * android.control.availableHighSpeedVideoConfigurations and CONSTRAINED_HIGH_SPEED_VIDEO
- * capability defined in android.request.availableCapabilities.
- *
- * This mode only needs to be supported by HALs that include CONSTRAINED_HIGH_SPEED_VIDEO in
- * the android.request.availableCapabilities static metadata.
- */
- CAMERA3_STREAM_CONFIGURATION_CONSTRAINED_HIGH_SPEED_MODE = 1,
-
- /**
- * First value for vendor-defined stream configuration modes.
- */
- CAMERA3_VENDOR_STREAM_CONFIGURATION_MODE_START = 0x8000
-} camera3_stream_configuration_mode_t;
-
-/**
- * camera3_stream_t:
- *
- * A handle to a single camera input or output stream. A stream is defined by
- * the framework by its buffer resolution and format, and additionally by the
- * HAL with the gralloc usage flags and the maximum in-flight buffer count.
- *
- * The stream structures are owned by the framework, but pointers to a
- * camera3_stream passed into the HAL by configure_streams() are valid until the
- * end of the first subsequent configure_streams() call that _does not_ include
- * that camera3_stream as an argument, or until the end of the close() call.
- *
- * All camera3_stream framework-controlled members are immutable once the
- * camera3_stream is passed into configure_streams(). The HAL may only change
- * the HAL-controlled parameters during a configure_streams() call, except for
- * the contents of the private pointer.
- *
- * If a configure_streams() call returns a non-fatal error, all active streams
- * remain valid as if configure_streams() had not been called.
- *
- * The endpoint of the stream is not visible to the camera HAL device.
- * In DEVICE_API_VERSION_3_1, this was changed to share consumer usage flags
- * on streams where the camera is a producer (OUTPUT and BIDIRECTIONAL stream
- * types) see the usage field below.
- */
-typedef struct camera3_stream {
-
- /*****
- * Set by framework before configure_streams()
- */
-
- /**
- * The type of the stream, one of the camera3_stream_type_t values.
- */
- int stream_type;
-
- /**
- * The width in pixels of the buffers in this stream
- */
- uint32_t width;
-
- /**
- * The height in pixels of the buffers in this stream
- */
- uint32_t height;
-
- /**
- * The pixel format for the buffers in this stream. Format is a value from
- * the HAL_PIXEL_FORMAT_* list in system/core/include/system/graphics.h, or
- * from device-specific headers.
- *
- * If HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, then the platform
- * gralloc module will select a format based on the usage flags provided by
- * the camera device and the other endpoint of the stream.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * The camera HAL device must inspect the buffers handed to it in the
- * subsequent register_stream_buffers() call to obtain the
- * implementation-specific format details, if necessary.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * register_stream_buffers() won't be called by the framework, so the HAL
- * should configure the ISP and sensor pipeline based purely on the sizes,
- * usage flags, and formats for the configured streams.
- */
- int format;
-
- /*****
- * Set by HAL during configure_streams().
- */
-
- /**
- * The gralloc usage flags for this stream, as needed by the HAL. The usage
- * flags are defined in gralloc.h (GRALLOC_USAGE_*), or in device-specific
- * headers.
- *
- * For output streams, these are the HAL's producer usage flags. For input
- * streams, these are the HAL's consumer usage flags. The usage flags from
- * the producer and the consumer will be combined together and then passed
- * to the platform gralloc HAL module for allocating the gralloc buffers for
- * each stream.
- *
- * Version information:
- *
- * == CAMERA_DEVICE_API_VERSION_3_0:
- *
- * No initial value guaranteed when passed via configure_streams().
- * HAL may not use this field as input, and must write over this field
- * with its usage flags.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * For stream_type OUTPUT and BIDIRECTIONAL, when passed via
- * configure_streams(), the initial value of this is the consumer's
- * usage flags. The HAL may use these consumer flags to decide stream
- * configuration.
- * For stream_type INPUT, when passed via configure_streams(), the initial
- * value of this is 0.
- * For all streams passed via configure_streams(), the HAL must write
- * over this field with its usage flags.
- *
- * From Android O, the usage flag for an output stream may be bitwise
- * combination of usage flags for multiple consumers, for the purpose of
- * sharing one camera stream between those consumers. The HAL must fail
- * configure_streams call with -EINVAL if the combined flags cannot be
- * supported due to imcompatible buffer format, dataSpace, or other hardware
- * limitations.
- */
-#ifdef CAMERA_64BIT_USAGE
- uint64_t usage;
-#else
- uint32_t usage;
-#endif
-
- /**
- * The maximum number of buffers the HAL device may need to have dequeued at
- * the same time. The HAL device may not have more buffers in-flight from
- * this stream than this value.
- */
- uint32_t max_buffers;
-
- /**
- * A handle to HAL-private information for the stream. Will not be inspected
- * by the framework code.
- */
- void *priv;
-
- /**
- * A field that describes the contents of the buffer. The format and buffer
- * dimensions define the memory layout and structure of the stream buffers,
- * while dataSpace defines the meaning of the data within the buffer.
- *
- * For most formats, dataSpace defines the color space of the image data.
- * In addition, for some formats, dataSpace indicates whether image- or
- * depth-based data is requested. See system/core/include/system/graphics.h
- * for details of formats and valid dataSpace values for each format.
- *
- * Version information:
- *
- * < CAMERA_DEVICE_API_VERSION_3_3:
- *
- * Not defined and should not be accessed. dataSpace should be assumed to
- * be HAL_DATASPACE_UNKNOWN, and the appropriate color space, etc, should
- * be determined from the usage flags and the format.
- *
- * = CAMERA_DEVICE_API_VERSION_3_3:
- *
- * Always set by the camera service. HAL must use this dataSpace to
- * configure the stream to the correct colorspace, or to select between
- * color and depth outputs if supported. The dataspace values are the
- * legacy definitions in graphics.h
- *
- * >= CAMERA_DEVICE_API_VERSION_3_4:
- *
- * Always set by the camera service. HAL must use this dataSpace to
- * configure the stream to the correct colorspace, or to select between
- * color and depth outputs if supported. The dataspace values are set
- * using the V0 dataspace definitions in graphics.h
- */
- android_dataspace_t data_space;
-
- /**
- * The required output rotation of the stream, one of
- * the camera3_stream_rotation_t values. This must be inspected by HAL along
- * with stream width and height. For example, if the rotation is 90 degree
- * and the stream width and height is 720 and 1280 respectively, camera service
- * will supply buffers of size 720x1280, and HAL should capture a 1280x720 image
- * and rotate the image by 90 degree counterclockwise. The rotation field is
- * no-op when the stream type is input. Camera HAL must ignore the rotation
- * field for an input stream.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Not defined and must not be accessed. HAL must not apply any rotation
- * on output images.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_3:
- *
- * Always set by camera service. HAL must inspect this field during stream
- * configuration and returns -EINVAL if HAL cannot perform such rotation.
- * HAL must always support CAMERA3_STREAM_ROTATION_0, so a
- * configure_streams() call must not fail for unsupported rotation if
- * rotation field of all streams is CAMERA3_STREAM_ROTATION_0.
- *
- */
- int rotation;
-
- /**
- * The physical camera id this stream belongs to.
- *
- * <= CAMERA_DEVICE_API_VERISON_3_4:
- *
- * Not defined and must not be accessed.
- *
- * >= CAMERA_DEVICE_API_VERISON_3_5:
- *
- * Always set by camera service. If the camera device is not a logical
- * multi camera, or if the camera is a logical multi camera but the stream
- * is not a physical output stream, this field will point to a 0-length
- * string.
- *
- * A logical multi camera is a camera device backed by multiple physical
- * cameras that are also exposed to the application. And for a logical
- * multi camera, a physical output stream is an output stream specifically
- * requested on an underlying physical camera.
- *
- * For an input stream, this field is guaranteed to be a 0-length string.
- */
- const char* physical_camera_id;
-
- /* reserved for future use */
- void *reserved[6];
-
-#ifdef CAMERA_NEEDS_SEC_RESERVED_FIELD
- char reserved_sec[0x28];
-#endif
-
-} camera3_stream_t;
-
-/**
- * camera3_stream_configuration_t:
- *
- * A structure of stream definitions, used by configure_streams(). This
- * structure defines all the output streams and the reprocessing input
- * stream for the current camera use case.
- */
-typedef struct camera3_stream_configuration {
- /**
- * The total number of streams requested by the framework. This includes
- * both input and output streams. The number of streams will be at least 1,
- * and there will be at least one output-capable stream.
- */
- uint32_t num_streams;
-
- /**
- * An array of camera stream pointers, defining the input/output
- * configuration for the camera HAL device.
- *
- * At most one input-capable stream may be defined (INPUT or BIDIRECTIONAL)
- * in a single configuration.
- *
- * At least one output-capable stream must be defined (OUTPUT or
- * BIDIRECTIONAL).
- */
- camera3_stream_t **streams;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_3:
- *
- * The operation mode of streams in this configuration, one of the value
- * defined in camera3_stream_configuration_mode_t. The HAL can use this
- * mode as an indicator to set the stream property (e.g.,
- * camera3_stream->max_buffers) appropriately. For example, if the
- * configuration is
- * CAMERA3_STREAM_CONFIGURATION_CONSTRAINED_HIGH_SPEED_MODE, the HAL may
- * want to set aside more buffers for batch mode operation (see
- * android.control.availableHighSpeedVideoConfigurations for batch mode
- * definition).
- *
- */
- uint32_t operation_mode;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- *
- * The session metadata buffer contains the initial values of
- * ANDROID_REQUEST_AVAILABLE_SESSION_KEYS. This field is optional
- * and camera clients can choose to ignore it, in which case it will
- * be set to NULL. If parameters are present, then Hal should examine
- * the parameter values and configure its internal camera pipeline
- * accordingly.
- */
- const camera_metadata_t *session_parameters;
-} camera3_stream_configuration_t;
-
-/**
- * camera3_buffer_status_t:
- *
- * The current status of a single stream buffer.
- */
-typedef enum camera3_buffer_status {
- /**
- * The buffer is in a normal state, and can be used after waiting on its
- * sync fence.
- */
- CAMERA3_BUFFER_STATUS_OK = 0,
-
- /**
- * The buffer does not contain valid data, and the data in it should not be
- * used. The sync fence must still be waited on before reusing the buffer.
- */
- CAMERA3_BUFFER_STATUS_ERROR = 1
-
-} camera3_buffer_status_t;
-
-/**
- * camera3_stream_buffer_t:
- *
- * A single buffer from a camera3 stream. It includes a handle to its parent
- * stream, the handle to the gralloc buffer itself, and sync fences
- *
- * The buffer does not specify whether it is to be used for input or output;
- * that is determined by its parent stream type and how the buffer is passed to
- * the HAL device.
- */
-typedef struct camera3_stream_buffer {
- /**
- * The handle of the stream this buffer is associated with
- */
- camera3_stream_t *stream;
-
- /**
- * The native handle to the buffer
- */
- buffer_handle_t *buffer;
-
- /**
- * Current state of the buffer, one of the camera3_buffer_status_t
- * values. The framework will not pass buffers to the HAL that are in an
- * error state. In case a buffer could not be filled by the HAL, it must
- * have its status set to CAMERA3_BUFFER_STATUS_ERROR when returned to the
- * framework with process_capture_result().
- */
- int status;
-
- /**
- * The acquire sync fence for this buffer. The HAL must wait on this fence
- * fd before attempting to read from or write to this buffer.
- *
- * The framework may be set to -1 to indicate that no waiting is necessary
- * for this buffer.
- *
- * When the HAL returns an output buffer to the framework with
- * process_capture_result(), the acquire_fence must be set to -1. If the HAL
- * never waits on the acquire_fence due to an error in filling a buffer,
- * when calling process_capture_result() the HAL must set the release_fence
- * of the buffer to be the acquire_fence passed to it by the framework. This
- * will allow the framework to wait on the fence before reusing the buffer.
- *
- * For input buffers, the HAL must not change the acquire_fence field during
- * the process_capture_request() call.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * When the HAL returns an input buffer to the framework with
- * process_capture_result(), the acquire_fence must be set to -1. If the HAL
- * never waits on input buffer acquire fence due to an error, the sync
- * fences should be handled similarly to the way they are handled for output
- * buffers.
- */
- int acquire_fence;
-
- /**
- * The release sync fence for this buffer. The HAL must set this fence when
- * returning buffers to the framework, or write -1 to indicate that no
- * waiting is required for this buffer.
- *
- * For the output buffers, the fences must be set in the output_buffers
- * array passed to process_capture_result().
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * For the input buffer, the release fence must be set by the
- * process_capture_request() call.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * For the input buffer, the fences must be set in the input_buffer
- * passed to process_capture_result().
- *
- * After signaling the release_fence for this buffer, the HAL
- * should not make any further attempts to access this buffer as the
- * ownership has been fully transferred back to the framework.
- *
- * If a fence of -1 was specified then the ownership of this buffer
- * is transferred back immediately upon the call of process_capture_result.
- */
- int release_fence;
-
-} camera3_stream_buffer_t;
-
-/**
- * camera3_stream_buffer_set_t:
- *
- * The complete set of gralloc buffers for a stream. This structure is given to
- * register_stream_buffers() to allow the camera HAL device to register/map/etc
- * newly allocated stream buffers.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Deprecated (and not used). In particular,
- * register_stream_buffers is also deprecated and will never be invoked.
- *
- */
-typedef struct camera3_stream_buffer_set {
- /**
- * The stream handle for the stream these buffers belong to
- */
- camera3_stream_t *stream;
-
- /**
- * The number of buffers in this stream. It is guaranteed to be at least
- * stream->max_buffers.
- */
- uint32_t num_buffers;
-
- /**
- * The array of gralloc buffer handles for this stream. If the stream format
- * is set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, the camera HAL device
- * should inspect the passed-in buffers to determine any platform-private
- * pixel format information.
- */
- buffer_handle_t **buffers;
-
-} camera3_stream_buffer_set_t;
-
-/**
- * camera3_jpeg_blob:
- *
- * Transport header for compressed JPEG or JPEG_APP_SEGMENTS buffers in output streams.
- *
- * To capture JPEG or JPEG_APP_SEGMENTS images, a stream is created using the pixel format
- * HAL_PIXEL_FORMAT_BLOB. The buffer size for the stream is calculated by the
- * framework, based on the static metadata field android.jpeg.maxSize for JPEG,
- * and android.jpeg.maxAppsSegments for JPEG_APP_SEGMENTS.
- *
- * Since compressed JPEG/JPEG_APP_SEGMENTS images are of variable size, the HAL needs to
- * include the final size of the image using this structure inside the output
- * stream buffer. The JPEG blob ID field must be set to CAMERA3_JPEG_BLOB_ID for
- * JPEG and CAMERA3_JPEG_APP_SEGMENTS_BLOB_ID for APP segments.
- *
- * Transport header should be at the end of the output stream buffer. That
- * means the jpeg_blob_id must start at byte[buffer_size -
- * sizeof(camera3_jpeg_blob)], where the buffer_size is the size of gralloc buffer.
- * The blob data itself starts at the beginning of the buffer and should be
- * jpeg_size bytes long. HAL using this transport header for JPEG must account for
- * it in android.jpeg.maxSize. For JPEG APP segments, camera framework makes
- * sure that the output stream buffer is large enough for the transport header.
- */
-typedef struct camera3_jpeg_blob {
- uint16_t jpeg_blob_id;
- uint32_t jpeg_size;
-} camera3_jpeg_blob_t;
-
-enum {
- CAMERA3_JPEG_BLOB_ID = 0x00FF,
- CAMERA3_JPEG_APP_SEGMENTS_BLOB_ID = 0x0100,
-};
-
-/**********************************************************************
- *
- * Message definitions for the HAL notify() callback.
- *
- * These definitions are used for the HAL notify callback, to signal
- * asynchronous events from the HAL device to the Android framework.
- *
- */
-
-/**
- * camera3_msg_type:
- *
- * Indicates the type of message sent, which specifies which member of the
- * message union is valid.
- *
- */
-typedef enum camera3_msg_type {
- /**
- * An error has occurred. camera3_notify_msg.message.error contains the
- * error information.
- */
- CAMERA3_MSG_ERROR = 1,
-
- /**
- * The exposure of a given request or processing a reprocess request has
- * begun. camera3_notify_msg.message.shutter contains the information
- * the capture.
- */
- CAMERA3_MSG_SHUTTER = 2,
-
- /**
- * Number of framework message types
- */
- CAMERA3_NUM_MESSAGES
-
-} camera3_msg_type_t;
-
-/**
- * Defined error codes for CAMERA_MSG_ERROR
- */
-typedef enum camera3_error_msg_code {
- /**
- * A serious failure occured. No further frames or buffer streams will
- * be produced by the device. Device should be treated as closed. The
- * client must reopen the device to use it again. The frame_number field
- * is unused.
- */
- CAMERA3_MSG_ERROR_DEVICE = 1,
-
- /**
- * An error has occurred in processing a request. No output (metadata or
- * buffers) will be produced for this request. The frame_number field
- * specifies which request has been dropped. Subsequent requests are
- * unaffected, and the device remains operational.
- */
- CAMERA3_MSG_ERROR_REQUEST = 2,
-
- /**
- * An error has occurred in producing an output result metadata buffer
- * for a request, but output stream buffers for it will still be
- * available. Subsequent requests are unaffected, and the device remains
- * operational. The frame_number field specifies the request for which
- * result metadata won't be available.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_6:
- *
- * In case the result metadata is absent for a logical camera device, then the
- * error_stream pointer must be set to NULL.
- * If the result metadata cannot be produced for a physical camera device, then
- * error_stream must contain a pointer to a respective stream associated with
- * that physical device.
- */
- CAMERA3_MSG_ERROR_RESULT = 3,
-
- /**
- * An error has occurred in placing an output buffer into a stream for a
- * request. The frame metadata and other buffers may still be
- * available. Subsequent requests are unaffected, and the device remains
- * operational. The frame_number field specifies the request for which the
- * buffer was dropped, and error_stream contains a pointer to the stream
- * that dropped the frame.
- */
- CAMERA3_MSG_ERROR_BUFFER = 4,
-
- /**
- * Number of error types
- */
- CAMERA3_MSG_NUM_ERRORS
-
-} camera3_error_msg_code_t;
-
-/**
- * camera3_error_msg_t:
- *
- * Message contents for CAMERA3_MSG_ERROR
- */
-typedef struct camera3_error_msg {
- /**
- * Frame number of the request the error applies to. 0 if the frame number
- * isn't applicable to the error.
- */
- uint32_t frame_number;
-
- /**
- * Pointer to the stream that had a failure. NULL if the stream isn't
- * applicable to the error.
- */
- camera3_stream_t *error_stream;
-
- /**
- * The code for this error; one of the CAMERA_MSG_ERROR enum values.
- */
- int error_code;
-
-} camera3_error_msg_t;
-
-/**
- * camera3_shutter_msg_t:
- *
- * Message contents for CAMERA3_MSG_SHUTTER
- */
-typedef struct camera3_shutter_msg {
- /**
- * Frame number of the request that has begun exposure or reprocessing.
- */
- uint32_t frame_number;
-
- /**
- * Timestamp for the start of capture. For a reprocess request, this must
- * be input image's start of capture. This must match the capture result
- * metadata's sensor exposure start timestamp.
- */
- uint64_t timestamp;
-
-} camera3_shutter_msg_t;
-
-/**
- * camera3_notify_msg_t:
- *
- * The message structure sent to camera3_callback_ops_t.notify()
- */
-typedef struct camera3_notify_msg {
-
- /**
- * The message type. One of camera3_notify_msg_type, or a private extension.
- */
- int type;
-
- union {
- /**
- * Error message contents. Valid if type is CAMERA3_MSG_ERROR
- */
- camera3_error_msg_t error;
-
- /**
- * Shutter message contents. Valid if type is CAMERA3_MSG_SHUTTER
- */
- camera3_shutter_msg_t shutter;
-
- /**
- * Generic message contents. Used to ensure a minimum size for custom
- * message types.
- */
- uint8_t generic[32];
- } message;
-
-} camera3_notify_msg_t;
-
-
-/**********************************************************************
- *
- * Types definition for request_stream_buffers() callback.
- *
- */
-
-/**
- * camera3_buffer_request_status_t:
- *
- * The overall buffer request status returned by request_stream_buffers()
- */
-typedef enum camera3_buffer_request_status {
- /**
- * request_stream_buffers() call succeeded and all requested buffers are
- * returned.
- */
- CAMERA3_BUF_REQ_OK = 0,
-
- /**
- * request_stream_buffers() call failed for some streams.
- * Check per stream status for each returned camera3_stream_buffer_ret_t.
- */
- CAMERA3_BUF_REQ_FAILED_PARTIAL = 1,
-
- /**
- * request_stream_buffers() call failed for all streams and no buffers are
- * returned at all. Camera service is about to or is performing
- * configure_streams() call. HAL must wait until next configure_streams()
- * call is finished before requesting buffers again.
- */
- CAMERA3_BUF_REQ_FAILED_CONFIGURING = 2,
-
- /**
- * request_stream_buffers() call failed for all streams and no buffers are
- * returned at all. Failure due to bad camera3_buffer_request input, eg:
- * unknown stream or repeated stream in the list of buffer requests.
- */
- CAMERA3_BUF_REQ_FAILED_ILLEGAL_ARGUMENTS = 3,
-
- /**
- * request_stream_buffers() call failed for all streams and no buffers are
- * returned at all. This can happen for unknown reasons or a combination
- * of different failure reasons per stream. For the latter case, caller can
- * check per stream failure reason returned in camera3_stream_buffer_ret.
- */
- CAMERA3_BUF_REQ_FAILED_UNKNOWN = 4,
-
- /**
- * Number of buffer request status
- */
- CAMERA3_BUF_REQ_NUM_STATUS
-
-} camera3_buffer_request_status_t;
-
-/**
- * camera3_stream_buffer_req_status_t:
- *
- * The per stream buffer request status returned by request_stream_buffers()
- */
-typedef enum camera3_stream_buffer_req_status {
- /**
- * Get buffer succeeds and all requested buffers are returned.
- */
- CAMERA3_PS_BUF_REQ_OK = 0,
-
- /**
- * Get buffer failed due to timeout waiting for an available buffer. This is
- * likely due to the client application holding too many buffers, or the
- * system is under memory pressure.
- * This is not a fatal error. HAL can try to request buffer for this stream
- * later. If HAL cannot get a buffer for certain capture request in time
- * due to this error, HAL can send an ERROR_REQUEST to camera service and
- * drop processing that request.
- */
- CAMERA3_PS_BUF_REQ_NO_BUFFER_AVAILABLE = 1,
-
- /**
- * Get buffer failed due to HAL has reached its maxBuffer count. This is not
- * a fatal error. HAL can try to request buffer for this stream again after
- * it returns at least one buffer of that stream to camera service.
- */
- CAMERA3_PS_BUF_REQ_MAX_BUFFER_EXCEEDED = 2,
-
- /**
- * Get buffer failed due to the stream is disconnected by client
- * application, has been removed, or not recognized by camera service.
- * This means application is no longer interested in this stream.
- * Requesting buffer for this stream will never succeed after this error is
- * returned. HAL must safely return all buffers of this stream after
- * getting this error. If HAL gets another capture request later targeting
- * a disconnected stream, HAL must send an ERROR_REQUEST to camera service
- * and drop processing that request.
- */
- CAMERA3_PS_BUF_REQ_STREAM_DISCONNECTED = 3,
-
- /**
- * Get buffer failed for unknown reason. This is a fatal error and HAL must
- * send ERROR_DEVICE to camera service and be ready to be closed.
- */
- CAMERA3_PS_BUF_REQ_UNKNOWN_ERROR = 4,
-
- /**
- * Number of buffer request status
- */
- CAMERA3_PS_BUF_REQ_NUM_STATUS
-} camera3_stream_buffer_req_status_t;
-
-typedef struct camera3_buffer_request {
- /**
- * The stream HAL wants to request buffer from
- */
- camera3_stream_t *stream;
-
- /**
- * The number of buffers HAL requested
- */
- uint32_t num_buffers_requested;
-} camera3_buffer_request_t;
-
-typedef struct camera3_stream_buffer_ret {
- /**
- * The stream HAL wants to request buffer from
- */
- camera3_stream_t *stream;
-
- /**
- * The status of buffer request of this stream
- */
- camera3_stream_buffer_req_status_t status;
-
- /**
- * Number of output buffers returned. Must be 0 when above status is not
- * CAMERA3_PS_BUF_REQ_OK; otherwise the value must be equal to
- * num_buffers_requested in the corresponding camera3_buffer_request_t
- */
- uint32_t num_output_buffers;
-
- /**
- * The returned output buffers for the stream.
- * Caller of request_stream_buffers() should supply this with enough memory
- * (num_buffers_requested * sizeof(camera3_stream_buffer_t))
- */
- camera3_stream_buffer_t *output_buffers;
-} camera3_stream_buffer_ret_t;
-
-
-/**********************************************************************
- *
- * Capture request/result definitions for the HAL process_capture_request()
- * method, and the process_capture_result() callback.
- *
- */
-
-/**
- * camera3_request_template_t:
- *
- * Available template types for
- * camera3_device_ops.construct_default_request_settings()
- */
-typedef enum camera3_request_template {
- /**
- * Standard camera preview operation with 3A on auto.
- */
- CAMERA3_TEMPLATE_PREVIEW = 1,
-
- /**
- * Standard camera high-quality still capture with 3A and flash on auto.
- */
- CAMERA3_TEMPLATE_STILL_CAPTURE = 2,
-
- /**
- * Standard video recording plus preview with 3A on auto, torch off.
- */
- CAMERA3_TEMPLATE_VIDEO_RECORD = 3,
-
- /**
- * High-quality still capture while recording video. Application will
- * include preview, video record, and full-resolution YUV or JPEG streams in
- * request. Must not cause stuttering on video stream. 3A on auto.
- */
- CAMERA3_TEMPLATE_VIDEO_SNAPSHOT = 4,
-
- /**
- * Zero-shutter-lag mode. Application will request preview and
- * full-resolution data for each frame, and reprocess it to JPEG when a
- * still image is requested by user. Settings should provide highest-quality
- * full-resolution images without compromising preview frame rate. 3A on
- * auto.
- */
- CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG = 5,
-
- /**
- * A basic template for direct application control of capture
- * parameters. All automatic control is disabled (auto-exposure, auto-white
- * balance, auto-focus), and post-processing parameters are set to preview
- * quality. The manual capture parameters (exposure, sensitivity, etc.)
- * are set to reasonable defaults, but should be overridden by the
- * application depending on the intended use case.
- */
- CAMERA3_TEMPLATE_MANUAL = 6,
-
- /* Total number of templates */
- CAMERA3_TEMPLATE_COUNT,
-
- /**
- * First value for vendor-defined request templates
- */
- CAMERA3_VENDOR_TEMPLATE_START = 0x40000000
-
-} camera3_request_template_t;
-
-/**
- * camera3_capture_request_t:
- *
- * A single request for image capture/buffer reprocessing, sent to the Camera
- * HAL device by the framework in process_capture_request().
- *
- * The request contains the settings to be used for this capture, and the set of
- * output buffers to write the resulting image data in. It may optionally
- * contain an input buffer, in which case the request is for reprocessing that
- * input buffer instead of capturing a new image with the camera sensor. The
- * capture is identified by the frame_number.
- *
- * In response, the camera HAL device must send a camera3_capture_result
- * structure asynchronously to the framework, using the process_capture_result()
- * callback.
- */
-typedef struct camera3_capture_request {
- /**
- * The frame number is an incrementing integer set by the framework to
- * uniquely identify this capture. It needs to be returned in the result
- * call, and is also used to identify the request in asynchronous
- * notifications sent to camera3_callback_ops_t.notify().
- */
- uint32_t frame_number;
-
- /**
- * The settings buffer contains the capture and processing parameters for
- * the request. As a special case, a NULL settings buffer indicates that the
- * settings are identical to the most-recently submitted capture request. A
- * NULL buffer cannot be used as the first submitted request after a
- * configure_streams() call.
- */
- const camera_metadata_t *settings;
-
- /**
- * The input stream buffer to use for this request, if any.
- *
- * If input_buffer is NULL, then the request is for a new capture from the
- * imager. If input_buffer is valid, the request is for reprocessing the
- * image contained in input_buffer.
- *
- * In the latter case, the HAL must set the release_fence of the
- * input_buffer to a valid sync fence, or to -1 if the HAL does not support
- * sync, before process_capture_request() returns.
- *
- * The HAL is required to wait on the acquire sync fence of the input buffer
- * before accessing it.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * Any input buffer included here will have been registered with the HAL
- * through register_stream_buffers() before its inclusion in a request.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * The buffers will not have been pre-registered with the HAL.
- * Subsequent requests may reuse buffers, or provide entirely new buffers.
- */
- camera3_stream_buffer_t *input_buffer;
-
- /**
- * The number of output buffers for this capture request. Must be at least
- * 1.
- */
- uint32_t num_output_buffers;
-
- /**
- * An array of num_output_buffers stream buffers, to be filled with image
- * data from this capture/reprocess. The HAL must wait on the acquire fences
- * of each stream buffer before writing to them.
- *
- * The HAL takes ownership of the actual buffer_handle_t entries in
- * output_buffers; the framework does not access them until they are
- * returned in a camera3_capture_result_t.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * All the buffers included here will have been registered with the HAL
- * through register_stream_buffers() before their inclusion in a request.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Any or all of the buffers included here may be brand new in this
- * request (having never before seen by the HAL).
- */
- const camera3_stream_buffer_t *output_buffers;
-
- /**
- * <= CAMERA_DEVICE_API_VERISON_3_4:
- *
- * Not defined and must not be accessed.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- * The number of physical camera settings to be applied. If 'num_physcam_settings'
- * equals 0 or a physical device is not included, then Hal must decide the
- * specific physical device settings based on the default 'settings'.
- */
- uint32_t num_physcam_settings;
-
- /**
- * <= CAMERA_DEVICE_API_VERISON_3_4:
- *
- * Not defined and must not be accessed.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- * The physical camera ids. The array will contain 'num_physcam_settings'
- * camera id strings for all physical devices that have specific settings.
- * In case some id is invalid, the process capture request must fail and return
- * -EINVAL.
- */
- const char **physcam_id;
-
- /**
- * <= CAMERA_DEVICE_API_VERISON_3_4:
- *
- * Not defined and must not be accessed.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- * The capture settings for the physical cameras. The array will contain
- * 'num_physcam_settings' settings for invididual physical devices. In
- * case the settings at some particular index are empty, the process capture
- * request must fail and return -EINVAL.
- */
- const camera_metadata_t **physcam_settings;
-
-} camera3_capture_request_t;
-
-/**
- * camera3_capture_result_t:
- *
- * The result of a single capture/reprocess by the camera HAL device. This is
- * sent to the framework asynchronously with process_capture_result(), in
- * response to a single capture request sent to the HAL with
- * process_capture_request(). Multiple process_capture_result() calls may be
- * performed by the HAL for each request.
- *
- * Each call, all with the same frame
- * number, may contain some subset of the output buffers, and/or the result
- * metadata. The metadata may only be provided once for a given frame number;
- * all other calls must set the result metadata to NULL.
- *
- * The result structure contains the output metadata from this capture, and the
- * set of output buffers that have been/will be filled for this capture. Each
- * output buffer may come with a release sync fence that the framework will wait
- * on before reading, in case the buffer has not yet been filled by the HAL.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * The metadata may be provided multiple times for a single frame number. The
- * framework will accumulate together the final result set by combining each
- * partial result together into the total result set.
- *
- * If an input buffer is given in a request, the HAL must return it in one of
- * the process_capture_result calls, and the call may be to just return the input
- * buffer, without metadata and output buffers; the sync fences must be handled
- * the same way they are done for output buffers.
- *
- *
- * Performance considerations:
- *
- * Applications will also receive these partial results immediately, so sending
- * partial results is a highly recommended performance optimization to avoid
- * the total pipeline latency before sending the results for what is known very
- * early on in the pipeline.
- *
- * A typical use case might be calculating the AF state halfway through the
- * pipeline; by sending the state back to the framework immediately, we get a
- * 50% performance increase and perceived responsiveness of the auto-focus.
- *
- */
-typedef struct camera3_capture_result {
- /**
- * The frame number is an incrementing integer set by the framework in the
- * submitted request to uniquely identify this capture. It is also used to
- * identify the request in asynchronous notifications sent to
- * camera3_callback_ops_t.notify().
- */
- uint32_t frame_number;
-
- /**
- * The result metadata for this capture. This contains information about the
- * final capture parameters, the state of the capture and post-processing
- * hardware, the state of the 3A algorithms, if enabled, and the output of
- * any enabled statistics units.
- *
- * Only one call to process_capture_result() with a given frame_number may
- * include the result metadata. All other calls for the same frame_number
- * must set this to NULL.
- *
- * If there was an error producing the result metadata, result must be an
- * empty metadata buffer, and notify() must be called with ERROR_RESULT.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Multiple calls to process_capture_result() with a given frame_number
- * may include the result metadata.
- *
- * Partial metadata submitted should not include any metadata key returned
- * in a previous partial result for a given frame. Each new partial result
- * for that frame must also set a distinct partial_result value.
- *
- * If notify has been called with ERROR_RESULT, all further partial
- * results for that frame are ignored by the framework.
- */
- const camera_metadata_t *result;
-
- /**
- * The number of output buffers returned in this result structure. Must be
- * less than or equal to the matching capture request's count. If this is
- * less than the buffer count in the capture request, at least one more call
- * to process_capture_result with the same frame_number must be made, to
- * return the remaining output buffers to the framework. This may only be
- * zero if the structure includes valid result metadata or an input buffer
- * is returned in this result.
- */
- uint32_t num_output_buffers;
-
- /**
- * The handles for the output stream buffers for this capture. They may not
- * yet be filled at the time the HAL calls process_capture_result(); the
- * framework will wait on the release sync fences provided by the HAL before
- * reading the buffers.
- *
- * The HAL must set the stream buffer's release sync fence to a valid sync
- * fd, or to -1 if the buffer has already been filled.
- *
- * If the HAL encounters an error while processing the buffer, and the
- * buffer is not filled, the buffer's status field must be set to
- * CAMERA3_BUFFER_STATUS_ERROR. If the HAL did not wait on the acquire fence
- * before encountering the error, the acquire fence should be copied into
- * the release fence, to allow the framework to wait on the fence before
- * reusing the buffer.
- *
- * The acquire fence must be set to -1 for all output buffers. If
- * num_output_buffers is zero, this may be NULL. In that case, at least one
- * more process_capture_result call must be made by the HAL to provide the
- * output buffers.
- *
- * When process_capture_result is called with a new buffer for a frame,
- * all previous frames' buffers for that corresponding stream must have been
- * already delivered (the fences need not have yet been signaled).
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Gralloc buffers for a frame may be sent to framework before the
- * corresponding SHUTTER-notify.
- *
- * Performance considerations:
- *
- * Buffers delivered to the framework will not be dispatched to the
- * application layer until a start of exposure timestamp has been received
- * via a SHUTTER notify() call. It is highly recommended to
- * dispatch that call as early as possible.
- */
- const camera3_stream_buffer_t *output_buffers;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * The handle for the input stream buffer for this capture. It may not
- * yet be consumed at the time the HAL calls process_capture_result(); the
- * framework will wait on the release sync fences provided by the HAL before
- * reusing the buffer.
- *
- * The HAL should handle the sync fences the same way they are done for
- * output_buffers.
- *
- * Only one input buffer is allowed to be sent per request. Similarly to
- * output buffers, the ordering of returned input buffers must be
- * maintained by the HAL.
- *
- * Performance considerations:
- *
- * The input buffer should be returned as early as possible. If the HAL
- * supports sync fences, it can call process_capture_result to hand it back
- * with sync fences being set appropriately. If the sync fences are not
- * supported, the buffer can only be returned when it is consumed, which
- * may take long time; the HAL may choose to copy this input buffer to make
- * the buffer return sooner.
- */
- const camera3_stream_buffer_t *input_buffer;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * In order to take advantage of partial results, the HAL must set the
- * static metadata android.request.partialResultCount to the number of
- * partial results it will send for each frame.
- *
- * Each new capture result with a partial result must set
- * this field (partial_result) to a distinct inclusive value between
- * 1 and android.request.partialResultCount.
- *
- * HALs not wishing to take advantage of this feature must not
- * set an android.request.partialResultCount or partial_result to a value
- * other than 1.
- *
- * This value must be set to 0 when a capture result contains buffers only
- * and no metadata.
- */
- uint32_t partial_result;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- *
- * Specifies the number of physical camera metadata this capture result
- * contains. It must be equal to the number of physical cameras being
- * requested from.
- *
- * If the current camera device is not a logical multi-camera, or the
- * corresponding capture_request doesn't request on any physical camera,
- * this field must be 0.
- */
- uint32_t num_physcam_metadata;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- *
- * An array of strings containing the physical camera ids for the returned
- * physical camera metadata. The length of the array is
- * num_physcam_metadata.
- */
- const char **physcam_ids;
-
- /**
- * >= CAMERA_DEVICE_API_VERSION_3_5:
- *
- * The array of physical camera metadata for the physical cameras being
- * requested upon. This array should have a 1-to-1 mapping with the
- * physcam_ids. The length of the array is num_physcam_metadata.
- */
- const camera_metadata_t **physcam_metadata;
-
-} camera3_capture_result_t;
-
-/**********************************************************************
- *
- * Callback methods for the HAL to call into the framework.
- *
- * These methods are used to return metadata and image buffers for a completed
- * or failed captures, and to notify the framework of asynchronous events such
- * as errors.
- *
- * The framework will not call back into the HAL from within these callbacks,
- * and these calls will not block for extended periods.
- *
- */
-typedef struct camera3_callback_ops {
-
- /**
- * process_capture_result:
- *
- * Send results from a completed capture to the framework.
- * process_capture_result() may be invoked multiple times by the HAL in
- * response to a single capture request. This allows, for example, the
- * metadata and low-resolution buffers to be returned in one call, and
- * post-processed JPEG buffers in a later call, once it is available. Each
- * call must include the frame number of the request it is returning
- * metadata or buffers for.
- *
- * A component (buffer or metadata) of the complete result may only be
- * included in one process_capture_result call. A buffer for each stream,
- * and the result metadata, must be returned by the HAL for each request in
- * one of the process_capture_result calls, even in case of errors producing
- * some of the output. A call to process_capture_result() with neither
- * output buffers or result metadata is not allowed.
- *
- * The order of returning metadata and buffers for a single result does not
- * matter, but buffers for a given stream must be returned in FIFO order. So
- * the buffer for request 5 for stream A must always be returned before the
- * buffer for request 6 for stream A. This also applies to the result
- * metadata; the metadata for request 5 must be returned before the metadata
- * for request 6.
- *
- * However, different streams are independent of each other, so it is
- * acceptable and expected that the buffer for request 5 for stream A may be
- * returned after the buffer for request 6 for stream B is. And it is
- * acceptable that the result metadata for request 6 for stream B is
- * returned before the buffer for request 5 for stream A is.
- *
- * The HAL retains ownership of result structure, which only needs to be
- * valid to access during this call. The framework will copy whatever it
- * needs before this call returns.
- *
- * The output buffers do not need to be filled yet; the framework will wait
- * on the stream buffer release sync fence before reading the buffer
- * data. Therefore, this method should be called by the HAL as soon as
- * possible, even if some or all of the output buffers are still in
- * being filled. The HAL must include valid release sync fences into each
- * output_buffers stream buffer entry, or -1 if that stream buffer is
- * already filled.
- *
- * If the result buffer cannot be constructed for a request, the HAL should
- * return an empty metadata buffer, but still provide the output buffers and
- * their sync fences. In addition, notify() must be called with an
- * ERROR_RESULT message.
- *
- * If an output buffer cannot be filled, its status field must be set to
- * STATUS_ERROR. In addition, notify() must be called with a ERROR_BUFFER
- * message.
- *
- * If the entire capture has failed, then this method still needs to be
- * called to return the output buffers to the framework. All the buffer
- * statuses should be STATUS_ERROR, and the result metadata should be an
- * empty buffer. In addition, notify() must be called with a ERROR_REQUEST
- * message. In this case, individual ERROR_RESULT/ERROR_BUFFER messages
- * should not be sent.
- *
- * Performance requirements:
- *
- * This is a non-blocking call. The framework will return this call in 5ms.
- *
- * The pipeline latency (see S7 for definition) should be less than or equal to
- * 4 frame intervals, and must be less than or equal to 8 frame intervals.
- *
- */
- void (*process_capture_result)(const struct camera3_callback_ops *,
- const camera3_capture_result_t *result);
-
- /**
- * notify:
- *
- * Asynchronous notification callback from the HAL, fired for various
- * reasons. Only for information independent of frame capture, or that
- * require specific timing. The ownership of the message structure remains
- * with the HAL, and the msg only needs to be valid for the duration of this
- * call.
- *
- * Multiple threads may call notify() simultaneously.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * The notification for the start of exposure for a given request must be
- * sent by the HAL before the first call to process_capture_result() for
- * that request is made.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Buffers delivered to the framework will not be dispatched to the
- * application layer until a start of exposure timestamp (or input image's
- * start of exposure timestamp for a reprocess request) has been received
- * via a SHUTTER notify() call. It is highly recommended to dispatch this
- * call as early as possible.
- *
- * ------------------------------------------------------------------------
- * Performance requirements:
- *
- * This is a non-blocking call. The framework will return this call in 5ms.
- */
- void (*notify)(const struct camera3_callback_ops *,
- const camera3_notify_msg_t *msg);
-
- /**
- * request_stream_buffers:
- *
- * <= CAMERA_DEVICE_API_VERISON_3_5:
- *
- * DO NOT USE: not defined and must be NULL.
- *
- * >= CAMERA_DEVICE_API_VERISON_3_6:
- *
- * Synchronous callback for HAL to ask for output buffer from camera service.
- *
- * This call may be serialized in camera service so it is strongly
- * recommended to only call this method from one thread.
- *
- * When camera device advertises
- * (android.info.supportedBufferManagementVersion ==
- * ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION_HIDL_DEVICE_3_5), HAL
- * can use this method to request buffers from camera service.
- *
- * Caller is responsible for allocating enough memory for returned_buf_reqs
- * argument (num_buffer_reqs * sizeof(camera3_stream_buffer_ret_t)) bytes
- * and also the memory for the output_buffers field in each
- * camera3_stream_buffer_ret_t
- * (num_buffers_requested * sizeof(camera3_stream_buffer_t)) bytes
- *
- * Performance requirements:
- * This is a blocking call that takes more time with more buffers requested.
- * HAL should not request large amount of buffers on a latency critical code
- * path. It is highly recommended to use a dedicated thread to perform
- * all requestStreamBuffer calls, and adjust the thread priority and/or
- * timing of making the call in order for buffers to arrive before HAL is
- * ready to fill the buffer.
- */
- camera3_buffer_request_status_t (*request_stream_buffers)(
- const struct camera3_callback_ops *,
- uint32_t num_buffer_reqs,
- const camera3_buffer_request_t *buffer_reqs,
- /*out*/uint32_t *num_returned_buf_reqs,
- /*out*/camera3_stream_buffer_ret_t *returned_buf_reqs);
-
- /**
- * return_stream_buffers:
- *
- * <= CAMERA_DEVICE_API_VERISON_3_5:
- *
- * DO NOT USE: not defined and must be NULL.
- *
- * >= CAMERA_DEVICE_API_VERISON_3_6:
- *
- * Synchronous callback for HAL to return output buffers to camera service.
- *
- * If this method is called during a configure_streams() call, it will be
- * blocked until camera service finishes the ongoing configure_streams() call.
- */
- void (*return_stream_buffers)(
- const struct camera3_callback_ops *,
- uint32_t num_buffers,
- const camera3_stream_buffer_t* const* buffers);
-
-} camera3_callback_ops_t;
-
-/**********************************************************************
- *
- * Camera device operations
- *
- */
-typedef struct camera3_device_ops {
-
- /**
- * initialize:
- *
- * One-time initialization to pass framework callback function pointers to
- * the HAL. Will be called once after a successful open() call, before any
- * other functions are called on the camera3_device_ops structure.
- *
- * Performance requirements:
- *
- * This should be a non-blocking call. The HAL should return from this call
- * in 5ms, and must return from this call in 10ms.
- *
- * Return values:
- *
- * 0: On successful initialization
- *
- * -ENODEV: If initialization fails. Only close() can be called successfully
- * by the framework after this.
- */
- int (*initialize)(const struct camera3_device *,
- const camera3_callback_ops_t *callback_ops);
-
- /**********************************************************************
- * Stream management
- */
-
- /**
- * configure_streams:
- *
- * CAMERA_DEVICE_API_VERSION_3_0 only:
- *
- * Reset the HAL camera device processing pipeline and set up new input and
- * output streams. This call replaces any existing stream configuration with
- * the streams defined in the stream_list. This method will be called at
- * least once after initialize() before a request is submitted with
- * process_capture_request().
- *
- * The stream_list must contain at least one output-capable stream, and may
- * not contain more than one input-capable stream.
- *
- * The stream_list may contain streams that are also in the currently-active
- * set of streams (from the previous call to configure_stream()). These
- * streams will already have valid values for usage, max_buffers, and the
- * private pointer.
- *
- * If such a stream has already had its buffers registered,
- * register_stream_buffers() will not be called again for the stream, and
- * buffers from the stream can be immediately included in input requests.
- *
- * If the HAL needs to change the stream configuration for an existing
- * stream due to the new configuration, it may rewrite the values of usage
- * and/or max_buffers during the configure call.
- *
- * The framework will detect such a change, and will then reallocate the
- * stream buffers, and call register_stream_buffers() again before using
- * buffers from that stream in a request.
- *
- * If a currently-active stream is not included in stream_list, the HAL may
- * safely remove any references to that stream. It will not be reused in a
- * later configure() call by the framework, and all the gralloc buffers for
- * it will be freed after the configure_streams() call returns.
- *
- * The stream_list structure is owned by the framework, and may not be
- * accessed once this call completes. The address of an individual
- * camera3_stream_t structure will remain valid for access by the HAL until
- * the end of the first configure_stream() call which no longer includes
- * that camera3_stream_t in the stream_list argument. The HAL may not change
- * values in the stream structure outside of the private pointer, except for
- * the usage and max_buffers members during the configure_streams() call
- * itself.
- *
- * If the stream is new, the usage, max_buffer, and private pointer fields
- * of the stream structure will all be set to 0. The HAL device must set
- * these fields before the configure_streams() call returns. These fields
- * are then used by the framework and the platform gralloc module to
- * allocate the gralloc buffers for each stream.
- *
- * Before such a new stream can have its buffers included in a capture
- * request, the framework will call register_stream_buffers() with that
- * stream. However, the framework is not required to register buffers for
- * _all_ streams before submitting a request. This allows for quick startup
- * of (for example) a preview stream, with allocation for other streams
- * happening later or concurrently.
- *
- * ------------------------------------------------------------------------
- * CAMERA_DEVICE_API_VERSION_3_1 only:
- *
- * Reset the HAL camera device processing pipeline and set up new input and
- * output streams. This call replaces any existing stream configuration with
- * the streams defined in the stream_list. This method will be called at
- * least once after initialize() before a request is submitted with
- * process_capture_request().
- *
- * The stream_list must contain at least one output-capable stream, and may
- * not contain more than one input-capable stream.
- *
- * The stream_list may contain streams that are also in the currently-active
- * set of streams (from the previous call to configure_stream()). These
- * streams will already have valid values for usage, max_buffers, and the
- * private pointer.
- *
- * If such a stream has already had its buffers registered,
- * register_stream_buffers() will not be called again for the stream, and
- * buffers from the stream can be immediately included in input requests.
- *
- * If the HAL needs to change the stream configuration for an existing
- * stream due to the new configuration, it may rewrite the values of usage
- * and/or max_buffers during the configure call.
- *
- * The framework will detect such a change, and will then reallocate the
- * stream buffers, and call register_stream_buffers() again before using
- * buffers from that stream in a request.
- *
- * If a currently-active stream is not included in stream_list, the HAL may
- * safely remove any references to that stream. It will not be reused in a
- * later configure() call by the framework, and all the gralloc buffers for
- * it will be freed after the configure_streams() call returns.
- *
- * The stream_list structure is owned by the framework, and may not be
- * accessed once this call completes. The address of an individual
- * camera3_stream_t structure will remain valid for access by the HAL until
- * the end of the first configure_stream() call which no longer includes
- * that camera3_stream_t in the stream_list argument. The HAL may not change
- * values in the stream structure outside of the private pointer, except for
- * the usage and max_buffers members during the configure_streams() call
- * itself.
- *
- * If the stream is new, max_buffer, and private pointer fields of the
- * stream structure will all be set to 0. The usage will be set to the
- * consumer usage flags. The HAL device must set these fields before the
- * configure_streams() call returns. These fields are then used by the
- * framework and the platform gralloc module to allocate the gralloc
- * buffers for each stream.
- *
- * Before such a new stream can have its buffers included in a capture
- * request, the framework will call register_stream_buffers() with that
- * stream. However, the framework is not required to register buffers for
- * _all_ streams before submitting a request. This allows for quick startup
- * of (for example) a preview stream, with allocation for other streams
- * happening later or concurrently.
- *
- * ------------------------------------------------------------------------
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * Reset the HAL camera device processing pipeline and set up new input and
- * output streams. This call replaces any existing stream configuration with
- * the streams defined in the stream_list. This method will be called at
- * least once after initialize() before a request is submitted with
- * process_capture_request().
- *
- * The stream_list must contain at least one output-capable stream, and may
- * not contain more than one input-capable stream.
- *
- * The stream_list may contain streams that are also in the currently-active
- * set of streams (from the previous call to configure_stream()). These
- * streams will already have valid values for usage, max_buffers, and the
- * private pointer.
- *
- * If the HAL needs to change the stream configuration for an existing
- * stream due to the new configuration, it may rewrite the values of usage
- * and/or max_buffers during the configure call.
- *
- * The framework will detect such a change, and may then reallocate the
- * stream buffers before using buffers from that stream in a request.
- *
- * If a currently-active stream is not included in stream_list, the HAL may
- * safely remove any references to that stream. It will not be reused in a
- * later configure() call by the framework, and all the gralloc buffers for
- * it will be freed after the configure_streams() call returns.
- *
- * The stream_list structure is owned by the framework, and may not be
- * accessed once this call completes. The address of an individual
- * camera3_stream_t structure will remain valid for access by the HAL until
- * the end of the first configure_stream() call which no longer includes
- * that camera3_stream_t in the stream_list argument. The HAL may not change
- * values in the stream structure outside of the private pointer, except for
- * the usage and max_buffers members during the configure_streams() call
- * itself.
- *
- * If the stream is new, max_buffer, and private pointer fields of the
- * stream structure will all be set to 0. The usage will be set to the
- * consumer usage flags. The HAL device must set these fields before the
- * configure_streams() call returns. These fields are then used by the
- * framework and the platform gralloc module to allocate the gralloc
- * buffers for each stream.
- *
- * Newly allocated buffers may be included in a capture request at any time
- * by the framework. Once a gralloc buffer is returned to the framework
- * with process_capture_result (and its respective release_fence has been
- * signaled) the framework may free or reuse it at any time.
- *
- * ------------------------------------------------------------------------
- *
- * Preconditions:
- *
- * The framework will only call this method when no captures are being
- * processed. That is, all results have been returned to the framework, and
- * all in-flight input and output buffers have been returned and their
- * release sync fences have been signaled by the HAL. The framework will not
- * submit new requests for capture while the configure_streams() call is
- * underway.
- *
- * Postconditions:
- *
- * The HAL device must configure itself to provide maximum possible output
- * frame rate given the sizes and formats of the output streams, as
- * documented in the camera device's static metadata.
- *
- * Performance requirements:
- *
- * This call is expected to be heavyweight and possibly take several hundred
- * milliseconds to complete, since it may require resetting and
- * reconfiguring the image sensor and the camera processing pipeline.
- * Nevertheless, the HAL device should attempt to minimize the
- * reconfiguration delay to minimize the user-visible pauses during
- * application operational mode changes (such as switching from still
- * capture to video recording).
- *
- * The HAL should return from this call in 500ms, and must return from this
- * call in 1000ms.
- *
- * Return values:
- *
- * 0: On successful stream configuration
- *
- * -EINVAL: If the requested stream configuration is invalid. Some examples
- * of invalid stream configurations include:
- *
- * - Including more than 1 input-capable stream (INPUT or
- * BIDIRECTIONAL)
- *
- * - Not including any output-capable streams (OUTPUT or
- * BIDIRECTIONAL)
- *
- * - Including streams with unsupported formats, or an unsupported
- * size for that format.
- *
- * - Including too many output streams of a certain format.
- *
- * - Unsupported rotation configuration (only applies to
- * devices with version >= CAMERA_DEVICE_API_VERSION_3_3)
- *
- * - Stream sizes/formats don't satisfy the
- * camera3_stream_configuration_t->operation_mode requirements for non-NORMAL mode,
- * or the requested operation_mode is not supported by the HAL.
- * (only applies to devices with version >= CAMERA_DEVICE_API_VERSION_3_3)
- *
- * Note that the framework submitting an invalid stream
- * configuration is not normal operation, since stream
- * configurations are checked before configure. An invalid
- * configuration means that a bug exists in the framework code, or
- * there is a mismatch between the HAL's static metadata and the
- * requirements on streams.
- *
- * -ENODEV: If there has been a fatal error and the device is no longer
- * operational. Only close() can be called successfully by the
- * framework after this error is returned.
- */
- int (*configure_streams)(const struct camera3_device *,
- camera3_stream_configuration_t *stream_list);
-
- /**
- * register_stream_buffers:
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * DEPRECATED. This will not be called and must be set to NULL.
- *
- * <= CAMERA_DEVICE_API_VERSION_3_1:
- *
- * Register buffers for a given stream with the HAL device. This method is
- * called by the framework after a new stream is defined by
- * configure_streams, and before buffers from that stream are included in a
- * capture request. If the same stream is listed in a subsequent
- * configure_streams() call, register_stream_buffers will _not_ be called
- * again for that stream.
- *
- * The framework does not need to register buffers for all configured
- * streams before it submits the first capture request. This allows quick
- * startup for preview (or similar use cases) while other streams are still
- * being allocated.
- *
- * This method is intended to allow the HAL device to map or otherwise
- * prepare the buffers for later use. The buffers passed in will already be
- * locked for use. At the end of the call, all the buffers must be ready to
- * be returned to the stream. The buffer_set argument is only valid for the
- * duration of this call.
- *
- * If the stream format was set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,
- * the camera HAL should inspect the passed-in buffers here to determine any
- * platform-private pixel format information.
- *
- * Performance requirements:
- *
- * This should be a non-blocking call. The HAL should return from this call
- * in 1ms, and must return from this call in 5ms.
- *
- * Return values:
- *
- * 0: On successful registration of the new stream buffers
- *
- * -EINVAL: If the stream_buffer_set does not refer to a valid active
- * stream, or if the buffers array is invalid.
- *
- * -ENOMEM: If there was a failure in registering the buffers. The framework
- * must consider all the stream buffers to be unregistered, and can
- * try to register again later.
- *
- * -ENODEV: If there is a fatal error, and the device is no longer
- * operational. Only close() can be called successfully by the
- * framework after this error is returned.
- */
- int (*register_stream_buffers)(const struct camera3_device *,
- const camera3_stream_buffer_set_t *buffer_set);
-
- /**********************************************************************
- * Request creation and submission
- */
-
- /**
- * construct_default_request_settings:
- *
- * Create capture settings for standard camera use cases.
- *
- * The device must return a settings buffer that is configured to meet the
- * requested use case, which must be one of the CAMERA3_TEMPLATE_*
- * enums. All request control fields must be included.
- *
- * The HAL retains ownership of this structure, but the pointer to the
- * structure must be valid until the device is closed. The framework and the
- * HAL may not modify the buffer once it is returned by this call. The same
- * buffer may be returned for subsequent calls for the same template, or for
- * other templates.
- *
- * Performance requirements:
- *
- * This should be a non-blocking call. The HAL should return from this call
- * in 1ms, and must return from this call in 5ms.
- *
- * Return values:
- *
- * Valid metadata: On successful creation of a default settings
- * buffer.
- *
- * NULL: In case of a fatal error. After this is returned, only
- * the close() method can be called successfully by the
- * framework.
- */
- const camera_metadata_t* (*construct_default_request_settings)(
- const struct camera3_device *,
- int type);
-
- /**
- * process_capture_request:
- *
- * Send a new capture request to the HAL. The HAL should not return from
- * this call until it is ready to accept the next request to process. Only
- * one call to process_capture_request() will be made at a time by the
- * framework, and the calls will all be from the same thread. The next call
- * to process_capture_request() will be made as soon as a new request and
- * its associated buffers are available. In a normal preview scenario, this
- * means the function will be called again by the framework almost
- * instantly.
- *
- * The actual request processing is asynchronous, with the results of
- * capture being returned by the HAL through the process_capture_result()
- * call. This call requires the result metadata to be available, but output
- * buffers may simply provide sync fences to wait on. Multiple requests are
- * expected to be in flight at once, to maintain full output frame rate.
- *
- * The framework retains ownership of the request structure. It is only
- * guaranteed to be valid during this call. The HAL device must make copies
- * of the information it needs to retain for the capture processing. The HAL
- * is responsible for waiting on and closing the buffers' fences and
- * returning the buffer handles to the framework.
- *
- * The HAL must write the file descriptor for the input buffer's release
- * sync fence into input_buffer->release_fence, if input_buffer is not
- * NULL. If the HAL returns -1 for the input buffer release sync fence, the
- * framework is free to immediately reuse the input buffer. Otherwise, the
- * framework will wait on the sync fence before refilling and reusing the
- * input buffer.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- *
- * The input/output buffers provided by the framework in each request
- * may be brand new (having never before seen by the HAL).
- *
- * ------------------------------------------------------------------------
- * Performance considerations:
- *
- * Handling a new buffer should be extremely lightweight and there should be
- * no frame rate degradation or frame jitter introduced.
- *
- * This call must return fast enough to ensure that the requested frame
- * rate can be sustained, especially for streaming cases (post-processing
- * quality settings set to FAST). The HAL should return this call in 1
- * frame interval, and must return from this call in 4 frame intervals.
- *
- * Return values:
- *
- * 0: On a successful start to processing the capture request
- *
- * -EINVAL: If the input is malformed (the settings are NULL when not
- * allowed, invalid physical camera settings,
- * there are 0 output buffers, etc) and capture processing
- * cannot start. Failures during request processing should be
- * handled by calling camera3_callback_ops_t.notify(). In case of
- * this error, the framework will retain responsibility for the
- * stream buffers' fences and the buffer handles; the HAL should
- * not close the fences or return these buffers with
- * process_capture_result.
- *
- * -ENODEV: If the camera device has encountered a serious error. After this
- * error is returned, only the close() method can be successfully
- * called by the framework.
- *
- */
- int (*process_capture_request)(const struct camera3_device *,
- camera3_capture_request_t *request);
-
- /**********************************************************************
- * Miscellaneous methods
- */
-
- /**
- * get_metadata_vendor_tag_ops:
- *
- * Get methods to query for vendor extension metadata tag information. The
- * HAL should fill in all the vendor tag operation methods, or leave ops
- * unchanged if no vendor tags are defined.
- *
- * The definition of vendor_tag_query_ops_t can be found in
- * system/media/camera/include/system/camera_metadata.h.
- *
- * >= CAMERA_DEVICE_API_VERSION_3_2:
- * DEPRECATED. This function has been deprecated and should be set to
- * NULL by the HAL. Please implement get_vendor_tag_ops in camera_common.h
- * instead.
- */
- void (*get_metadata_vendor_tag_ops)(const struct camera3_device*,
- vendor_tag_query_ops_t* ops);
-
- /**
- * dump:
- *
- * Print out debugging state for the camera device. This will be called by
- * the framework when the camera service is asked for a debug dump, which
- * happens when using the dumpsys tool, or when capturing a bugreport.
- *
- * The passed-in file descriptor can be used to write debugging text using
- * dprintf() or write(). The text should be in ASCII encoding only.
- *
- * Performance requirements:
- *
- * This must be a non-blocking call. The HAL should return from this call
- * in 1ms, must return from this call in 10ms. This call must avoid
- * deadlocks, as it may be called at any point during camera operation.
- * Any synchronization primitives used (such as mutex locks or semaphores)
- * should be acquired with a timeout.
- */
- void (*dump)(const struct camera3_device *, int fd);
-
- /**
- * flush:
- *
- * Flush all currently in-process captures and all buffers in the pipeline
- * on the given device. The framework will use this to dump all state as
- * quickly as possible in order to prepare for a configure_streams() call.
- *
- * No buffers are required to be successfully returned, so every buffer
- * held at the time of flush() (whether successfully filled or not) may be
- * returned with CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed
- * to return valid (CAMERA3_BUFFER_STATUS_OK) buffers during this call,
- * provided they are successfully filled.
- *
- * All requests currently in the HAL are expected to be returned as soon as
- * possible. Not-in-process requests should return errors immediately. Any
- * interruptible hardware blocks should be stopped, and any uninterruptible
- * blocks should be waited on.
- *
- * flush() may be called concurrently to process_capture_request(), with the expectation that
- * process_capture_request will return quickly and the request submitted in that
- * process_capture_request call is treated like all other in-flight requests. Due to
- * concurrency issues, it is possible that from the HAL's point of view, a
- * process_capture_request() call may be started after flush has been invoked but has not
- * returned yet. If such a call happens before flush() returns, the HAL should treat the new
- * capture request like other in-flight pending requests (see #4 below).
- *
- * More specifically, the HAL must follow below requirements for various cases:
- *
- * 1. For captures that are too late for the HAL to cancel/stop, and will be
- * completed normally by the HAL; i.e. the HAL can send shutter/notify and
- * process_capture_result and buffers as normal.
- *
- * 2. For pending requests that have not done any processing, the HAL must call notify
- * CAMERA3_MSG_ERROR_REQUEST, and return all the output buffers with
- * process_capture_result in the error state (CAMERA3_BUFFER_STATUS_ERROR).
- * The HAL must not place the release fence into an error state, instead,
- * the release fences must be set to the acquire fences passed by the framework,
- * or -1 if they have been waited on by the HAL already. This is also the path
- * to follow for any captures for which the HAL already called notify() with
- * CAMERA3_MSG_SHUTTER but won't be producing any metadata/valid buffers for.
- * After CAMERA3_MSG_ERROR_REQUEST, for a given frame, only process_capture_results with
- * buffers in CAMERA3_BUFFER_STATUS_ERROR are allowed. No further notifys or
- * process_capture_result with non-null metadata is allowed.
- *
- * 3. For partially completed pending requests that will not have all the output
- * buffers or perhaps missing metadata, the HAL should follow below:
- *
- * 3.1. Call notify with CAMERA3_MSG_ERROR_RESULT if some of the expected result
- * metadata (i.e. one or more partial metadata) won't be available for the capture.
- *
- * 3.2. Call notify with CAMERA3_MSG_ERROR_BUFFER for every buffer that won't
- * be produced for the capture.
- *
- * 3.3 Call notify with CAMERA3_MSG_SHUTTER with the capture timestamp before
- * any buffers/metadata are returned with process_capture_result.
- *
- * 3.4 For captures that will produce some results, the HAL must not call
- * CAMERA3_MSG_ERROR_REQUEST, since that indicates complete failure.
- *
- * 3.5. Valid buffers/metadata should be passed to the framework as normal.
- *
- * 3.6. Failed buffers should be returned to the framework as described for case 2.
- * But failed buffers do not have to follow the strict ordering valid buffers do,
- * and may be out-of-order with respect to valid buffers. For example, if buffers
- * A, B, C, D, E are sent, D and E are failed, then A, E, B, D, C is an acceptable
- * return order.
- *
- * 3.7. For fully-missing metadata, calling CAMERA3_MSG_ERROR_RESULT is sufficient, no
- * need to call process_capture_result with NULL metadata or equivalent.
- *
- * 4. If a flush() is invoked while a process_capture_request() invocation is active, that
- * process call should return as soon as possible. In addition, if a process_capture_request()
- * call is made after flush() has been invoked but before flush() has returned, the
- * capture request provided by the late process_capture_request call should be treated like
- * a pending request in case #2 above.
- *
- * flush() should only return when there are no more outstanding buffers or
- * requests left in the HAL. The framework may call configure_streams (as
- * the HAL state is now quiesced) or may issue new requests.
- *
- * Note that it's sufficient to only support fully-succeeded and fully-failed result cases.
- * However, it is highly desirable to support the partial failure cases as well, as it
- * could help improve the flush call overall performance.
- *
- * Performance requirements:
- *
- * The HAL should return from this call in 100ms, and must return from this
- * call in 1000ms. And this call must not be blocked longer than pipeline
- * latency (see S7 for definition).
- *
- * Version information:
- *
- * only available if device version >= CAMERA_DEVICE_API_VERSION_3_1.
- *
- * Return values:
- *
- * 0: On a successful flush of the camera HAL.
- *
- * -EINVAL: If the input is malformed (the device is not valid).
- *
- * -ENODEV: If the camera device has encountered a serious error. After this
- * error is returned, only the close() method can be successfully
- * called by the framework.
- */
- int (*flush)(const struct camera3_device *);
-
- /**
- * signal_stream_flush:
- *
- * <= CAMERA_DEVICE_API_VERISON_3_5:
- *
- * Not defined and must be NULL
- *
- * >= CAMERA_DEVICE_API_VERISON_3_6:
- *
- * Signaling HAL camera service is about to perform configure_streams() call
- * and HAL must return all buffers of designated streams. HAL must finish
- * inflight requests normally and return all buffers belonging to the
- * designated streams through process_capture_result() or
- * return_stream_buffers() API in a timely manner, or camera service will run
- * into a fatal error.
- *
- * Note that this call serves as an optional hint and camera service may
- * skip calling this if all buffers are already returned.
- *
- */
- void (*signal_stream_flush)(const struct camera3_device*,
- uint32_t num_streams,
- const camera3_stream_t* const* streams);
-
- /**
- * is_reconfiguration_required:
- *
- * <= CAMERA_DEVICE_API_VERISON_3_5:
- *
- * Not defined and must be NULL
- *
- * >= CAMERA_DEVICE_API_VERISON_3_6:
- *
- * Check whether complete stream reconfiguration is required for possible new session
- * parameter values.
- *
- * This method must be called by the camera framework in case the client changes
- * the value of any advertised session parameters. Depending on the specific values
- * the HAL can decide whether a complete stream reconfiguration is required. In case
- * the HAL returns -ENVAL, the camera framework must skip the internal reconfiguration.
- * In case Hal returns 0, the framework must reconfigure the streams and pass the
- * new session parameter values accordingly.
- * This call may be done by the framework some time before the request with new parameters
- * is submitted to the HAL, and the request may be cancelled before it ever gets submitted.
- * Therefore, the HAL must not use this query as an indication to change its behavior in any
- * way.
- * ------------------------------------------------------------------------
- *
- * Preconditions:
- *
- * The framework can call this method at any time after active
- * session configuration. There must be no impact on the performance of
- * pending camera requests in any way. In particular there must not be
- * any glitches or delays during normal camera streaming.
- *
- * Performance requirements:
- * HW and SW camera settings must not be changed and there must not be
- * a user-visible impact on camera performance.
- *
- * @param oldSessionParams The currently applied session parameters.
- * @param newSessionParams The new session parameters set by client.
- *
- * @return Status Status code for the operation, one of:
- * 0: In case the stream reconfiguration is required
- *
- * -EINVAL: In case the stream reconfiguration is not required.
- *
- * -ENOSYS: In case the camera device does not support the
- * reconfiguration query.
- */
- int (*is_reconfiguration_required)(const struct camera3_device*,
- const camera_metadata_t* old_session_params,
- const camera_metadata_t* new_session_params);
-
- /* reserved for future use */
- void *reserved[6];
-} camera3_device_ops_t;
-
-/**********************************************************************
- *
- * Camera device definition
- *
- */
-typedef struct camera3_device {
- /**
- * common.version must equal CAMERA_DEVICE_API_VERSION_3_0 to identify this
- * device as implementing version 3.0 of the camera device HAL.
- *
- * Performance requirements:
- *
- * Camera open (common.module->common.methods->open) should return in 200ms, and must return
- * in 500ms.
- * Camera close (common.close) should return in 200ms, and must return in 500ms.
- *
- */
- hw_device_t common;
- camera3_device_ops_t *ops;
- void *priv;
-} camera3_device_t;
-
-__END_DECLS
-
-#endif /* #ifdef ANDROID_INCLUDE_CAMERA3_H */
+++ /dev/null
-/*
- * Copyright (C) 2012 The Android Open Source Project
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-// FIXME: add well-defined names for cameras
-
-#ifndef ANDROID_INCLUDE_CAMERA_COMMON_H
-#define ANDROID_INCLUDE_CAMERA_COMMON_H
-
-#include <stdint.h>
-#include <stdbool.h>
-#include <sys/cdefs.h>
-#include <sys/types.h>
-#include <cutils/native_handle.h>
-#include <system/camera.h>
-#include <system/camera_vendor_tags.h>
-#include <hardware/hardware.h>
-#include <hardware/gralloc.h>
-
-__BEGIN_DECLS
-
-/**
- * The id of this module
- */
-#define CAMERA_HARDWARE_MODULE_ID "camera"
-
-/**
- * Module versioning information for the Camera hardware module, based on
- * camera_module_t.common.module_api_version. The two most significant hex
- * digits represent the major version, and the two least significant represent
- * the minor version.
- *
- *******************************************************************************
- * Versions: 0.X - 1.X [CAMERA_MODULE_API_VERSION_1_0]
- *
- * Camera modules that report these version numbers implement the initial
- * camera module HAL interface. All camera devices openable through this
- * module support only version 1 of the camera device HAL. The device_version
- * and static_camera_characteristics fields of camera_info are not valid. Only
- * the android.hardware.Camera API can be supported by this module and its
- * devices.
- *
- *******************************************************************************
- * Version: 2.0 [CAMERA_MODULE_API_VERSION_2_0]
- *
- * Camera modules that report this version number implement the second version
- * of the camera module HAL interface. Camera devices openable through this
- * module may support either version 1.0 or version 2.0 of the camera device
- * HAL interface. The device_version field of camera_info is always valid; the
- * static_camera_characteristics field of camera_info is valid if the
- * device_version field is 2.0 or higher.
- *
- *******************************************************************************
- * Version: 2.1 [CAMERA_MODULE_API_VERSION_2_1]
- *
- * This camera module version adds support for asynchronous callbacks to the
- * framework from the camera HAL module, which is used to notify the framework
- * about changes to the camera module state. Modules that provide a valid
- * set_callbacks() method must report at least this version number.
- *
- *******************************************************************************
- * Version: 2.2 [CAMERA_MODULE_API_VERSION_2_2]
- *
- * This camera module version adds vendor tag support from the module, and
- * deprecates the old vendor_tag_query_ops that were previously only
- * accessible with a device open.
- *
- *******************************************************************************
- * Version: 2.3 [CAMERA_MODULE_API_VERSION_2_3]
- *
- * This camera module version adds open legacy camera HAL device support.
- * Framework can use it to open the camera device as lower device HAL version
- * HAL device if the same device can support multiple device API versions.
- * The standard hardware module open call (common.methods->open) continues
- * to open the camera device with the latest supported version, which is
- * also the version listed in camera_info_t.device_version.
- *
- *******************************************************************************
- * Version: 2.4 [CAMERA_MODULE_API_VERSION_2_4]
- *
- * This camera module version adds below API changes:
- *
- * 1. Torch mode support. The framework can use it to turn on torch mode for
- * any camera device that has a flash unit, without opening a camera device. The
- * camera device has a higher priority accessing the flash unit than the camera
- * module; opening a camera device will turn off the torch if it had been enabled
- * through the module interface. When there are any resource conflicts, such as
- * open() is called to open a camera device, the camera HAL module must notify the
- * framework through the torch mode status callback that the torch mode has been
- * turned off.
- *
- * 2. External camera (e.g. USB hot-plug camera) support. The API updates specify that
- * the camera static info is only available when camera is connected and ready to
- * use for external hot-plug cameras. Calls to get static info will be invalid
- * calls when camera status is not CAMERA_DEVICE_STATUS_PRESENT. The frameworks
- * will only count on device status change callbacks to manage the available external
- * camera list.
- *
- * 3. Camera arbitration hints. This module version adds support for explicitly
- * indicating the number of camera devices that can be simultaneously opened and used.
- * To specify valid combinations of devices, the resource_cost and conflicting_devices
- * fields should always be set in the camera_info structure returned by the
- * get_camera_info call.
- *
- * 4. Module initialization method. This will be called by the camera service
- * right after the HAL module is loaded, to allow for one-time initialization
- * of the HAL. It is called before any other module methods are invoked.
- *
- *******************************************************************************
- * Version: 2.5 [CAMERA_MODULE_API_VERSION_2_5]
- *
- * This camera module version adds below API changes:
- *
- * 1. Support to query characteristics of a non-standalone physical camera, which can
- * only be accessed as part of a logical camera. It also adds camera stream combination
- * query.
- *
- * 2. Ability to query whether a particular camera stream combination is
- * supported by the camera device.
- *
- * 3. Device state change notification. This module version also supports
- * notification about the overall device state change, such as
- * folding/unfolding, or covering/uncovering of shutter.
- */
-
-/**
- * Predefined macros for currently-defined version numbers
- */
-
-/**
- * All module versions <= HARDWARE_MODULE_API_VERSION(1, 0xFF) must be treated
- * as CAMERA_MODULE_API_VERSION_1_0
- */
-#define CAMERA_MODULE_API_VERSION_1_0 HARDWARE_MODULE_API_VERSION(1, 0)
-#define CAMERA_MODULE_API_VERSION_2_0 HARDWARE_MODULE_API_VERSION(2, 0)
-#define CAMERA_MODULE_API_VERSION_2_1 HARDWARE_MODULE_API_VERSION(2, 1)
-#define CAMERA_MODULE_API_VERSION_2_2 HARDWARE_MODULE_API_VERSION(2, 2)
-#define CAMERA_MODULE_API_VERSION_2_3 HARDWARE_MODULE_API_VERSION(2, 3)
-#define CAMERA_MODULE_API_VERSION_2_4 HARDWARE_MODULE_API_VERSION(2, 4)
-#define CAMERA_MODULE_API_VERSION_2_5 HARDWARE_MODULE_API_VERSION(2, 5)
-
-#define CAMERA_MODULE_API_VERSION_CURRENT CAMERA_MODULE_API_VERSION_2_5
-
-/**
- * All device versions <= HARDWARE_DEVICE_API_VERSION(1, 0xFF) must be treated
- * as CAMERA_DEVICE_API_VERSION_1_0
- */
-#define CAMERA_DEVICE_API_VERSION_1_0 HARDWARE_DEVICE_API_VERSION(1, 0) // DEPRECATED
-#define CAMERA_DEVICE_API_VERSION_2_0 HARDWARE_DEVICE_API_VERSION(2, 0) // NO LONGER SUPPORTED
-#define CAMERA_DEVICE_API_VERSION_2_1 HARDWARE_DEVICE_API_VERSION(2, 1) // NO LONGER SUPPORTED
-#define CAMERA_DEVICE_API_VERSION_3_0 HARDWARE_DEVICE_API_VERSION(3, 0) // NO LONGER SUPPORTED
-#define CAMERA_DEVICE_API_VERSION_3_1 HARDWARE_DEVICE_API_VERSION(3, 1) // NO LONGER SUPPORTED
-#define CAMERA_DEVICE_API_VERSION_3_2 HARDWARE_DEVICE_API_VERSION(3, 2)
-#define CAMERA_DEVICE_API_VERSION_3_3 HARDWARE_DEVICE_API_VERSION(3, 3)
-#define CAMERA_DEVICE_API_VERSION_3_4 HARDWARE_DEVICE_API_VERSION(3, 4)
-#define CAMERA_DEVICE_API_VERSION_3_5 HARDWARE_DEVICE_API_VERSION(3, 5)
-#define CAMERA_DEVICE_API_VERSION_3_6 HARDWARE_DEVICE_API_VERSION(3, 6)
-
-// Device version 3.5 is current, older HAL camera device versions are not
-// recommended for new devices.
-#define CAMERA_DEVICE_API_VERSION_CURRENT CAMERA_DEVICE_API_VERSION_3_5
-
-/**
- * Defined in /system/media/camera/include/system/camera_metadata.h
- */
-typedef struct camera_metadata camera_metadata_t;
-
-typedef struct camera_info {
- /**
- * The direction that the camera faces to. See system/core/include/system/camera.h
- * for camera facing definitions.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * It should be CAMERA_FACING_BACK or CAMERA_FACING_FRONT.
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * It should be CAMERA_FACING_BACK, CAMERA_FACING_FRONT or
- * CAMERA_FACING_EXTERNAL.
- */
- int facing;
-
- /**
- * The orientation of the camera image. The value is the angle that the
- * camera image needs to be rotated clockwise so it shows correctly on the
- * display in its natural orientation. It should be 0, 90, 180, or 270.
- *
- * For example, suppose a device has a naturally tall screen. The
- * back-facing camera sensor is mounted in landscape. You are looking at the
- * screen. If the top side of the camera sensor is aligned with the right
- * edge of the screen in natural orientation, the value should be 90. If the
- * top side of a front-facing camera sensor is aligned with the right of the
- * screen, the value should be 270.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * Valid in all camera_module versions.
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * Valid if camera facing is CAMERA_FACING_BACK or CAMERA_FACING_FRONT,
- * not valid if camera facing is CAMERA_FACING_EXTERNAL.
- */
- int orientation;
-
- /**
- * The value of camera_device_t.common.version.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_0:
- *
- * Not valid. Can be assumed to be CAMERA_DEVICE_API_VERSION_1_0. Do
- * not read this field.
- *
- * CAMERA_MODULE_API_VERSION_2_0 or higher:
- *
- * Always valid
- *
- */
- uint32_t device_version;
-
- /**
- * The camera's fixed characteristics, which include all static camera metadata
- * specified in system/media/camera/docs/docs.html. This should be a sorted metadata
- * buffer, and may not be modified or freed by the caller. The pointer should remain
- * valid for the lifetime of the camera module, and values in it may not
- * change after it is returned by get_camera_info().
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_0:
- *
- * Not valid. Extra characteristics are not available. Do not read this
- * field.
- *
- * CAMERA_MODULE_API_VERSION_2_0 or higher:
- *
- * Valid if device_version >= CAMERA_DEVICE_API_VERSION_2_0. Do not read
- * otherwise.
- *
- */
- const camera_metadata_t *static_camera_characteristics;
-
- /**
- * The total resource "cost" of using this camera, represented as an integer
- * value in the range [0, 100] where 100 represents total usage of the shared
- * resource that is the limiting bottleneck of the camera subsystem. This may
- * be a very rough estimate, and is used as a hint to the camera service to
- * determine when to disallow multiple applications from simultaneously
- * opening different cameras advertised by the camera service.
- *
- * The camera service must be able to simultaneously open and use any
- * combination of camera devices exposed by the HAL where the sum of
- * the resource costs of these cameras is <= 100. For determining cost,
- * each camera device must be assumed to be configured and operating at
- * the maximally resource-consuming framerate and stream size settings
- * available in the configuration settings exposed for that device through
- * the camera metadata.
- *
- * The camera service may still attempt to simultaneously open combinations
- * of camera devices with a total resource cost > 100. This may succeed or
- * fail. If this succeeds, combinations of configurations that are not
- * supported due to resource constraints from having multiple open devices
- * should fail during the configure calls. If the total resource cost is
- * <= 100, open and configure should never fail for any stream configuration
- * settings or other device capabilities that would normally succeed for a
- * device when it is the only open camera device.
- *
- * This field will be used to determine whether background applications are
- * allowed to use this camera device while other applications are using other
- * camera devices. Note: multiple applications will never be allowed by the
- * camera service to simultaneously open the same camera device.
- *
- * Example use cases:
- *
- * Ex. 1: Camera Device 0 = Back Camera
- * Camera Device 1 = Front Camera
- * - Using both camera devices causes a large framerate slowdown due to
- * limited ISP bandwidth.
- *
- * Configuration:
- *
- * Camera Device 0 - resource_cost = 51
- * conflicting_devices = null
- * Camera Device 1 - resource_cost = 51
- * conflicting_devices = null
- *
- * Result:
- *
- * Since the sum of the resource costs is > 100, if a higher-priority
- * application has either device open, no lower-priority applications will be
- * allowed by the camera service to open either device. If a lower-priority
- * application is using a device that a higher-priority subsequently attempts
- * to open, the lower-priority application will be forced to disconnect the
- * the device.
- *
- * If the highest-priority application chooses, it may still attempt to open
- * both devices (since these devices are not listed as conflicting in the
- * conflicting_devices fields), but usage of these devices may fail in the
- * open or configure calls.
- *
- * Ex. 2: Camera Device 0 = Left Back Camera
- * Camera Device 1 = Right Back Camera
- * Camera Device 2 = Combined stereo camera using both right and left
- * back camera sensors used by devices 0, and 1
- * Camera Device 3 = Front Camera
- * - Due to do hardware constraints, up to two cameras may be open at once. The
- * combined stereo camera may never be used at the same time as either of the
- * two back camera devices (device 0, 1), and typically requires too much
- * bandwidth to use at the same time as the front camera (device 3).
- *
- * Configuration:
- *
- * Camera Device 0 - resource_cost = 50
- * conflicting_devices = { 2 }
- * Camera Device 1 - resource_cost = 50
- * conflicting_devices = { 2 }
- * Camera Device 2 - resource_cost = 100
- * conflicting_devices = { 0, 1 }
- * Camera Device 3 - resource_cost = 50
- * conflicting_devices = null
- *
- * Result:
- *
- * Based on the conflicting_devices fields, the camera service guarantees that
- * the following sets of open devices will never be allowed: { 1, 2 }, { 0, 2 }.
- *
- * Based on the resource_cost fields, if a high-priority foreground application
- * is using camera device 0, a background application would be allowed to open
- * camera device 1 or 3 (but would be forced to disconnect it again if the
- * foreground application opened another device).
- *
- * The highest priority application may still attempt to simultaneously open
- * devices 0, 2, and 3, but the HAL may fail in open or configure calls for
- * this combination.
- *
- * Ex. 3: Camera Device 0 = Back Camera
- * Camera Device 1 = Front Camera
- * Camera Device 2 = Low-power Front Camera that uses the same
- * sensor as device 1, but only exposes image stream
- * resolutions that can be used in low-power mode
- * - Using both front cameras (device 1, 2) at the same time is impossible due
- * a shared physical sensor. Using the back and "high-power" front camera
- * (device 1) may be impossible for some stream configurations due to hardware
- * limitations, but the "low-power" front camera option may always be used as
- * it has special dedicated hardware.
- *
- * Configuration:
- *
- * Camera Device 0 - resource_cost = 100
- * conflicting_devices = null
- * Camera Device 1 - resource_cost = 100
- * conflicting_devices = { 2 }
- * Camera Device 2 - resource_cost = 0
- * conflicting_devices = { 1 }
- * Result:
- *
- * Based on the conflicting_devices fields, the camera service guarantees that
- * the following sets of open devices will never be allowed: { 1, 2 }.
- *
- * Based on the resource_cost fields, only the highest priority application
- * may attempt to open both device 0 and 1 at the same time. If a higher-priority
- * application is not using device 1 or 2, a low-priority background application
- * may open device 2 (but will be forced to disconnect it if a higher-priority
- * application subsequently opens device 1 or 2).
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * Not valid. Can be assumed to be 100. Do not read this field.
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * Always valid.
- */
- int resource_cost;
-
- /**
- * An array of camera device IDs represented as NULL-terminated strings
- * indicating other devices that cannot be simultaneously opened while this
- * camera device is in use.
- *
- * This field is intended to be used to indicate that this camera device
- * is a composite of several other camera devices, or otherwise has
- * hardware dependencies that prohibit simultaneous usage. If there are no
- * dependencies, a NULL may be returned in this field to indicate this.
- *
- * The camera service will never simultaneously open any of the devices
- * in this list while this camera device is open.
- *
- * The strings pointed to in this field will not be cleaned up by the camera
- * service, and must remain while this device is plugged in.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * Not valid. Can be assumed to be NULL. Do not read this field.
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * Always valid.
- */
- char** conflicting_devices;
-
- /**
- * The length of the array given in the conflicting_devices field.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * Not valid. Can be assumed to be 0. Do not read this field.
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * Always valid.
- */
- size_t conflicting_devices_length;
-
-} camera_info_t;
-
-/**
- * camera_device_status_t:
- *
- * The current status of the camera device, as provided by the HAL through the
- * camera_module_callbacks.camera_device_status_change() call.
- *
- * At module load time, the framework will assume all camera devices are in the
- * CAMERA_DEVICE_STATUS_PRESENT state. The HAL should invoke
- * camera_module_callbacks::camera_device_status_change to inform the framework
- * of any initially NOT_PRESENT devices.
- *
- * Allowed transitions:
- * PRESENT -> NOT_PRESENT
- * NOT_PRESENT -> ENUMERATING
- * NOT_PRESENT -> PRESENT
- * ENUMERATING -> PRESENT
- * ENUMERATING -> NOT_PRESENT
- */
-typedef enum camera_device_status {
- /**
- * The camera device is not currently connected, and opening it will return
- * failure.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * Calls to get_camera_info must still succeed, and provide the same information
- * it would if the camera were connected.
- *
- * CAMERA_MODULE_API_VERSION_2_4:
- *
- * The camera device at this status must return -EINVAL for get_camera_info call,
- * as the device is not connected.
- */
- CAMERA_DEVICE_STATUS_NOT_PRESENT = 0,
-
- /**
- * The camera device is connected, and opening it will succeed.
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * The information returned by get_camera_info cannot change due to this status
- * change. By default, the framework will assume all devices are in this state.
- *
- * CAMERA_MODULE_API_VERSION_2_4:
- *
- * The information returned by get_camera_info will become valid after a device's
- * status changes to this. By default, the framework will assume all devices are in
- * this state.
- */
- CAMERA_DEVICE_STATUS_PRESENT = 1,
-
- /**
- * The camera device is connected, but it is undergoing an enumeration and
- * so opening the device will return -EBUSY.
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * Calls to get_camera_info must still succeed, as if the camera was in the
- * PRESENT status.
- *
- * CAMERA_MODULE_API_VERSION_2_4:
- *
- * The camera device at this status must return -EINVAL for get_camera_info for call,
- * as the device is not ready.
- */
- CAMERA_DEVICE_STATUS_ENUMERATING = 2,
-
-} camera_device_status_t;
-
-/**
- * torch_mode_status_t:
- *
- * The current status of the torch mode, as provided by the HAL through the
- * camera_module_callbacks.torch_mode_status_change() call.
- *
- * The torch mode status of a camera device is applicable only when the camera
- * device is present. The framework will not call set_torch_mode() to turn on
- * torch mode of a camera device if the camera device is not present. At module
- * load time, the framework will assume torch modes are in the
- * TORCH_MODE_STATUS_AVAILABLE_OFF state if the camera device is present and
- * android.flash.info.available is reported as true via get_camera_info() call.
- *
- * The behaviors of the camera HAL module that the framework expects in the
- * following situations when a camera device's status changes:
- * 1. A previously-disconnected camera device becomes connected.
- * After camera_module_callbacks::camera_device_status_change() is invoked
- * to inform the framework that the camera device is present, the framework
- * will assume the camera device's torch mode is in
- * TORCH_MODE_STATUS_AVAILABLE_OFF state. The camera HAL module does not need
- * to invoke camera_module_callbacks::torch_mode_status_change() unless the
- * flash unit is unavailable to use by set_torch_mode().
- *
- * 2. A previously-connected camera becomes disconnected.
- * After camera_module_callbacks::camera_device_status_change() is invoked
- * to inform the framework that the camera device is not present, the
- * framework will not call set_torch_mode() for the disconnected camera
- * device until its flash unit becomes available again. The camera HAL
- * module does not need to invoke
- * camera_module_callbacks::torch_mode_status_change() separately to inform
- * that the flash unit has become unavailable.
- *
- * 3. open() is called to open a camera device.
- * The camera HAL module must invoke
- * camera_module_callbacks::torch_mode_status_change() for all flash units
- * that have entered TORCH_MODE_STATUS_NOT_AVAILABLE state and can not be
- * turned on by calling set_torch_mode() anymore due to this open() call.
- * open() must not trigger TORCH_MODE_STATUS_AVAILABLE_OFF before
- * TORCH_MODE_STATUS_NOT_AVAILABLE for all flash units that have become
- * unavailable.
- *
- * 4. close() is called to close a camera device.
- * The camera HAL module must invoke
- * camera_module_callbacks::torch_mode_status_change() for all flash units
- * that have entered TORCH_MODE_STATUS_AVAILABLE_OFF state and can be turned
- * on by calling set_torch_mode() again because of enough resources freed
- * up by this close() call.
- *
- * Note that the framework calling set_torch_mode() successfully must trigger
- * TORCH_MODE_STATUS_AVAILABLE_OFF or TORCH_MODE_STATUS_AVAILABLE_ON callback
- * for the given camera device. Additionally it must trigger
- * TORCH_MODE_STATUS_AVAILABLE_OFF callbacks for other previously-on torch
- * modes if HAL cannot keep multiple torch modes on simultaneously.
- */
-typedef enum torch_mode_status {
-
- /**
- * The flash unit is no longer available and the torch mode can not be
- * turned on by calling set_torch_mode(). If the torch mode is on, it
- * will be turned off by HAL before HAL calls torch_mode_status_change().
- */
- TORCH_MODE_STATUS_NOT_AVAILABLE = 0,
-
- /**
- * A torch mode has become off and available to be turned on via
- * set_torch_mode(). This may happen in the following
- * cases:
- * 1. After the resources to turn on the torch mode have become available.
- * 2. After set_torch_mode() is called to turn off the torch mode.
- * 3. After the framework turned on the torch mode of some other camera
- * device and HAL had to turn off the torch modes of any camera devices
- * that were previously on.
- */
- TORCH_MODE_STATUS_AVAILABLE_OFF = 1,
-
- /**
- * A torch mode has become on and available to be turned off via
- * set_torch_mode(). This can happen only after set_torch_mode() is called
- * to turn on the torch mode.
- */
- TORCH_MODE_STATUS_AVAILABLE_ON = 2,
-
-} torch_mode_status_t;
-
-/**
- * Callback functions for the camera HAL module to use to inform the framework
- * of changes to the camera subsystem.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * Each callback is called only by HAL modules implementing the indicated
- * version or higher of the HAL module API interface.
- *
- * CAMERA_MODULE_API_VERSION_2_1:
- * camera_device_status_change()
- *
- * CAMERA_MODULE_API_VERSION_2_4:
- * torch_mode_status_change()
-
- */
-typedef struct camera_module_callbacks {
-
- /**
- * camera_device_status_change:
- *
- * Callback to the framework to indicate that the state of a specific camera
- * device has changed. At module load time, the framework will assume all
- * camera devices are in the CAMERA_DEVICE_STATUS_PRESENT state. The HAL
- * must call this method to inform the framework of any initially
- * NOT_PRESENT devices.
- *
- * This callback is added for CAMERA_MODULE_API_VERSION_2_1.
- *
- * camera_module_callbacks: The instance of camera_module_callbacks_t passed
- * to the module with set_callbacks.
- *
- * camera_id: The ID of the camera device that has a new status.
- *
- * new_status: The new status code, one of the camera_device_status_t enums,
- * or a platform-specific status.
- *
- */
- void (*camera_device_status_change)(const struct camera_module_callbacks*,
- int camera_id,
- int new_status);
-
- /**
- * torch_mode_status_change:
- *
- * Callback to the framework to indicate that the state of the torch mode
- * of the flash unit associated with a specific camera device has changed.
- * At module load time, the framework will assume the torch modes are in
- * the TORCH_MODE_STATUS_AVAILABLE_OFF state if android.flash.info.available
- * is reported as true via get_camera_info() call.
- *
- * This callback is added for CAMERA_MODULE_API_VERSION_2_4.
- *
- * camera_module_callbacks: The instance of camera_module_callbacks_t
- * passed to the module with set_callbacks.
- *
- * camera_id: The ID of camera device whose flash unit has a new torch mode
- * status.
- *
- * new_status: The new status code, one of the torch_mode_status_t enums.
- */
- void (*torch_mode_status_change)(const struct camera_module_callbacks*,
- const char* camera_id,
- int new_status);
-
-
-} camera_module_callbacks_t;
-
-/**
- * camera_stream_t:
- *
- * A handle to a single camera input or output stream. A stream is defined by
- * the framework by its buffer resolution and format and gralloc usage flags.
- *
- * The stream structures are owned by the framework and pointers to a
- * camera_stream passed into the HAL by is_stream_combination_supported() are
- * only valid within the scope of the call.
- *
- * All camera_stream members are immutable.
- */
-typedef struct camera_stream {
- /**
- * The type of the stream, one of the camera3_stream_type_t values.
- */
- int stream_type;
-
- /**
- * The width in pixels of the buffers in this stream
- */
- uint32_t width;
-
- /**
- * The height in pixels of the buffers in this stream
- */
- uint32_t height;
-
- /**
- * The pixel format for the buffers in this stream. Format is a value from
- * the HAL_PIXEL_FORMAT_* list in system/core/include/system/graphics.h, or
- * from device-specific headers.
- *
- * If HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, then the platform
- * gralloc module will select a format based on the usage flags provided by
- * the camera device and the other endpoint of the stream.
- *
- */
- int format;
-
- /**
- * The gralloc usage flags for this stream, as needed by the HAL. The usage
- * flags are defined in gralloc.h (GRALLOC_USAGE_*), or in device-specific
- * headers.
- *
- * For output streams, these are the HAL's producer usage flags. For input
- * streams, these are the HAL's consumer usage flags. The usage flags from
- * the producer and the consumer will be combined together and then passed
- * to the platform gralloc HAL module for allocating the gralloc buffers for
- * each stream.
- *
- * The usage flag for an output stream may be bitwise
- * combination of usage flags for multiple consumers, for the purpose of
- * sharing one camera stream between those consumers. The HAL must fail
- * the stream combination query call with -EINVAL if the combined flags cannot be
- * supported due to imcompatible buffer format, dataSpace, or other hardware
- * limitations.
- */
- uint32_t usage;
-
- /**
- * A field that describes the contents of the buffer. The format and buffer
- * dimensions define the memory layout and structure of the stream buffers,
- * while dataSpace defines the meaning of the data within the buffer.
- *
- * For most formats, dataSpace defines the color space of the image data.
- * In addition, for some formats, dataSpace indicates whether image- or
- * depth-based data is requested. See system/core/include/system/graphics.h
- * for details of formats and valid dataSpace values for each format.
- *
- * Always set by the camera service. The dataspace values are set
- * using the V0 dataspace definitions in graphics.h
- */
- android_dataspace_t data_space;
-
- /**
- * The required output rotation of the stream, one of
- * the camera3_stream_rotation_t values. This must be inspected by HAL along
- * with stream width and height. For example, if the rotation is 90 degree
- * and the stream width and height is 720 and 1280 respectively, camera service
- * will supply buffers of size 720x1280, and HAL should capture a 1280x720 image
- * and rotate the image by 90 degree counterclockwise. The rotation field is
- * no-op when the stream type is input. Camera HAL must ignore the rotation
- * field for an input stream.
- *
- * Always set by camera service. HAL must inspect this field during stream
- * combination query and return -EINVAL if it cannot perform such rotation.
- * HAL must always support CAMERA3_STREAM_ROTATION_0, so a
- * is_stream_combination_supported() call must not fail for unsupported rotation if
- * rotation field of all streams is CAMERA3_STREAM_ROTATION_0.
- *
- */
- int rotation;
-
- /**
- * The physical camera id this stream belongs to.
- * Always set by camera service. If the camera device is not a logical
- * multi camera, or if the camera is a logical multi camera but the stream
- * is not a physical output stream, this field will point to a 0-length
- * string.
- *
- * A logical multi camera is a camera device backed by multiple physical
- * cameras that are also exposed to the application. And for a logical
- * multi camera, a physical output stream is an output stream specifically
- * requested on an underlying physical camera.
- *
- * For an input stream, this field is guaranteed to be a 0-length string.
- */
- const char* physical_camera_id;
-
-} camera_stream_t;
-
-/**
- * camera_stream_combination_t:
- *
- * A structure of stream definitions, used by is_stream_combination_supported(). This
- * structure defines all the input & output streams for specific camera use case.
- */
-typedef struct camera_stream_combination {
- /**
- * The total number of streams by the framework. This includes
- * both input and output streams. The number of streams will be at least 1,
- * and there will be at least one output-capable stream.
- */
- uint32_t num_streams;
-
- /**
- * An array of camera streams, defining the input/output
- * stream combination for the camera HAL device.
- *
- * At most one input-capable stream may be defined.
- *
- * At least one output-capable stream must be defined.
- */
- camera_stream_t *streams;
-
- /**
- * The operation mode of streams in this stream combination, one of the value
- * defined in camera3_stream_configuration_mode_t.
- *
- */
- uint32_t operation_mode;
-
-} camera_stream_combination_t;
-
-/**
- * device_state_t:
- *
- * Possible physical states of the overall device, for use with
- * notify_device_state_change.
- */
-typedef enum device_state {
- /**
- * The device is in its normal physical configuration. This is the default if the
- * device does not support multiple different states.
- */
- NORMAL = 0,
-
- /**
- * Camera device(s) facing backward are covered.
- */
- BACK_COVERED = 1 << 0,
-
- /**
- * Camera device(s) facing foward are covered.
- */
- FRONT_COVERED = 1 << 1,
-
- /**
- * The device is folded. If not set, the device is unfolded or does not
- * support folding.
- *
- * The exact point when this status change happens during the folding
- * operation is device-specific.
- */
- FOLDED = 1 << 2,
-
- /**
- * First vendor-specific device state. All bits above and including this one
- * are for vendor state values. Values below this one must only be used
- * for framework-defined states.
- */
- VENDOR_STATE_START = 1LL << 32
-
-} device_state_t;
-
-typedef struct camera_module {
- /**
- * Common methods of the camera module. This *must* be the first member of
- * camera_module as users of this structure will cast a hw_module_t to
- * camera_module pointer in contexts where it's known the hw_module_t
- * references a camera_module.
- *
- * The return values for common.methods->open for camera_module are:
- *
- * 0: On a successful open of the camera device.
- *
- * -ENODEV: The camera device cannot be opened due to an internal
- * error.
- *
- * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
- * and/or the module is invalid.
- *
- * -EBUSY: The camera device was already opened for this camera id
- * (by using this method or open_legacy),
- * regardless of the device HAL version it was opened as.
- *
- * -EUSERS: The maximal number of camera devices that can be
- * opened concurrently were opened already, either by
- * this method or the open_legacy method.
- *
- * All other return values from common.methods->open will be treated as
- * -ENODEV.
- */
- hw_module_t common;
-
- /**
- * get_number_of_cameras:
- *
- * Returns the number of camera devices accessible through the camera
- * module. The camera devices are numbered 0 through N-1, where N is the
- * value returned by this call. The name of the camera device for open() is
- * simply the number converted to a string. That is, "0" for camera ID 0,
- * "1" for camera ID 1.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_3 or lower:
- *
- * The value here must be static, and cannot change after the first call
- * to this method.
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * The value here must be static, and must count only built-in cameras,
- * which have CAMERA_FACING_BACK or CAMERA_FACING_FRONT camera facing values
- * (camera_info.facing). The HAL must not include the external cameras
- * (camera_info.facing == CAMERA_FACING_EXTERNAL) into the return value
- * of this call. Frameworks will use camera_device_status_change callback
- * to manage number of external cameras.
- */
- int (*get_number_of_cameras)(void);
-
-#ifdef CAMERA_NEEDS_SEC_GET_CAM_POS_V1
- /**
- * get_cam_pos:
- *
- * Unknown. Needed by prebuilt camera module from the Samsung GTO device.
- *
- * Return values found so far:
- *
- * 0: On a successful operation
- *
- * -EINVAL: The input arguments are invalid
- *
- */
- int (*get_cam_pos)(void);
-#endif
-
- /**
- * get_camera_info:
- *
- * Return the static camera information for a given camera device. This
- * information may not change for a camera device.
- *
- * Return values:
- *
- * 0: On a successful operation
- *
- * -ENODEV: The information cannot be provided due to an internal
- * error.
- *
- * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
- * and/or the module is invalid.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_2_4 or higher:
- *
- * When a camera is disconnected, its camera id becomes invalid. Calling this
- * this method with this invalid camera id will get -EINVAL and NULL camera
- * static metadata (camera_info.static_camera_characteristics).
- */
- int (*get_camera_info)(int camera_id, struct camera_info *info);
-
-#ifdef CAMERA_NEEDS_SEC_GET_CAM_POS_V2
- /**
- * get_cam_pos:
- *
- * Unknown. Needed by prebuilt camera module from the Samsung GTA4L device.
- *
- * Return values found so far:
- *
- * 0: On a successful operation
- *
- * -EINVAL: The input arguments are invalid
- *
- */
- int (*get_cam_pos)(void);
-#endif
-
- /**
- * set_callbacks:
- *
- * Provide callback function pointers to the HAL module to inform framework
- * of asynchronous camera module events. The framework will call this
- * function once after initial camera HAL module load, after the
- * get_number_of_cameras() method is called for the first time, and before
- * any other calls to the module.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_0, CAMERA_MODULE_API_VERSION_2_0:
- *
- * Not provided by HAL module. Framework may not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_1:
- *
- * Valid to be called by the framework.
- *
- * Return values:
- *
- * 0: On a successful operation
- *
- * -ENODEV: The operation cannot be completed due to an internal
- * error.
- *
- * -EINVAL: The input arguments are invalid, i.e. the callbacks are
- * null
- */
- int (*set_callbacks)(const camera_module_callbacks_t *callbacks);
-
- /**
- * get_vendor_tag_ops:
- *
- * Get methods to query for vendor extension metadata tag information. The
- * HAL should fill in all the vendor tag operation methods, or leave ops
- * unchanged if no vendor tags are defined.
- *
- * The vendor_tag_ops structure used here is defined in:
- * system/media/camera/include/system/vendor_tags.h
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1:
- * Not provided by HAL module. Framework may not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_2:
- * Valid to be called by the framework.
- */
- void (*get_vendor_tag_ops)(vendor_tag_ops_t* ops);
-
- /**
- * open_legacy:
- *
- * Open a specific legacy camera HAL device if multiple device HAL API
- * versions are supported by this camera HAL module. For example, if the
- * camera module supports both CAMERA_DEVICE_API_VERSION_1_0 and
- * CAMERA_DEVICE_API_VERSION_3_2 device API for the same camera id,
- * framework can call this function to open the camera device as
- * CAMERA_DEVICE_API_VERSION_1_0 device.
- *
- * This is an optional method. A Camera HAL module does not need to support
- * more than one device HAL version per device, and such modules may return
- * -ENOSYS for all calls to this method. For all older HAL device API
- * versions that are not supported, it may return -EOPNOTSUPP. When above
- * cases occur, The normal open() method (common.methods->open) will be
- * used by the framework instead.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2:
- * Not provided by HAL module. Framework will not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_3:
- * Valid to be called by the framework.
- *
- * Return values:
- *
- * 0: On a successful open of the camera device.
- *
- * -ENOSYS This method is not supported.
- *
- * -EOPNOTSUPP: The requested HAL version is not supported by this method.
- *
- * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
- * and/or the module is invalid.
- *
- * -EBUSY: The camera device was already opened for this camera id
- * (by using this method or common.methods->open method),
- * regardless of the device HAL version it was opened as.
- *
- * -EUSERS: The maximal number of camera devices that can be
- * opened concurrently were opened already, either by
- * this method or common.methods->open method.
- */
- int (*open_legacy)(const struct hw_module_t* module, const char* id,
- uint32_t halVersion, struct hw_device_t** device);
-
- /**
- * set_torch_mode:
- *
- * Turn on or off the torch mode of the flash unit associated with a given
- * camera ID. If the operation is successful, HAL must notify the framework
- * torch state by invoking
- * camera_module_callbacks.torch_mode_status_change() with the new state.
- *
- * The camera device has a higher priority accessing the flash unit. When
- * there are any resource conflicts, such as open() is called to open a
- * camera device, HAL module must notify the framework through
- * camera_module_callbacks.torch_mode_status_change() that the
- * torch mode has been turned off and the torch mode state has become
- * TORCH_MODE_STATUS_NOT_AVAILABLE. When resources to turn on torch mode
- * become available again, HAL module must notify the framework through
- * camera_module_callbacks.torch_mode_status_change() that the torch mode
- * state has become TORCH_MODE_STATUS_AVAILABLE_OFF for set_torch_mode() to
- * be called.
- *
- * When the framework calls set_torch_mode() to turn on the torch mode of a
- * flash unit, if HAL cannot keep multiple torch modes on simultaneously,
- * HAL should turn off the torch mode that was turned on by
- * a previous set_torch_mode() call and notify the framework that the torch
- * mode state of that flash unit has become TORCH_MODE_STATUS_AVAILABLE_OFF.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3:
- * Not provided by HAL module. Framework will not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_4:
- * Valid to be called by the framework.
- *
- * Return values:
- *
- * 0: On a successful operation.
- *
- * -ENOSYS: The camera device does not support this operation. It is
- * returned if and only if android.flash.info.available is
- * false.
- *
- * -EBUSY: The camera device is already in use.
- *
- * -EUSERS: The resources needed to turn on the torch mode are not
- * available, typically because other camera devices are
- * holding the resources to make using the flash unit not
- * possible.
- *
- * -EINVAL: camera_id is invalid.
- *
- */
- int (*set_torch_mode)(const char* camera_id, bool enabled);
-
- /**
- * init:
- *
- * This method is called by the camera service before any other methods
- * are invoked, right after the camera HAL library has been successfully
- * loaded. It may be left as NULL by the HAL module, if no initialization
- * in needed.
- *
- * It can be used by HAL implementations to perform initialization and
- * other one-time operations.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3:
- * Not provided by HAL module. Framework will not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_4:
- * If not NULL, will always be called by the framework once after the HAL
- * module is loaded, before any other HAL module method is called.
- *
- * Return values:
- *
- * 0: On a successful operation.
- *
- * -ENODEV: Initialization cannot be completed due to an internal
- * error. The HAL must be assumed to be in a nonfunctional
- * state.
- *
- */
- int (*init)();
-
- /**
- * get_physical_camera_info:
- *
- * Return the static metadata for a physical camera as a part of a logical
- * camera device. This function is only called for those physical camera
- * ID(s) that are not exposed independently. In other words, camera_id will
- * be greater or equal to the return value of get_number_of_cameras().
- *
- * Return values:
- *
- * 0: On a successful operation
- *
- * -ENODEV: The information cannot be provided due to an internal
- * error.
- *
- * -EINVAL: The input arguments are invalid, i.e. the id is invalid,
- * and/or the module is invalid.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3/2_4:
- * Not provided by HAL module. Framework will not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_5 or higher:
- * If any of the camera devices accessible through this camera module is
- * a logical multi-camera, and at least one of the physical cameras isn't
- * a stand-alone camera device, this function will be called by the camera
- * framework. Calling this function with invalid physical_camera_id will
- * get -EINVAL, and NULL static_metadata.
- */
- int (*get_physical_camera_info)(int physical_camera_id,
- camera_metadata_t **static_metadata);
-
- /**
- * is_stream_combination_supported:
- *
- * Check for device support of specific camera stream combination.
- *
- * Return values:
- *
- * 0: In case the stream combination is supported.
- *
- * -EINVAL: In case the stream combination is not supported.
- *
- * -ENOSYS: In case stream combination query is not supported.
- *
- * Version information (based on camera_module_t.common.module_api_version):
- *
- * CAMERA_MODULE_API_VERSION_1_x/2_0/2_1/2_2/2_3/2_4:
- * Not provided by HAL module. Framework will not call this function.
- *
- * CAMERA_MODULE_API_VERSION_2_5 or higher:
- * Valid to be called by the framework.
- */
- int (*is_stream_combination_supported)(int camera_id,
- const camera_stream_combination_t *streams);
-
- /**
- * notify_device_state_change:
- *
- * Notify the camera module that the state of the overall device has
- * changed in some way that the HAL may want to know about.
- *
- * For example, a physical shutter may have been uncovered or covered,
- * or a camera may have been covered or uncovered by an add-on keyboard
- * or other accessory.
- *
- * The state is a bitfield of potential states, and some physical configurations
- * could plausibly correspond to multiple different combinations of state bits.
- * The HAL must ignore any state bits it is not actively using to determine
- * the appropriate camera configuration.
- *
- * For example, on some devices the FOLDED state could mean that
- * backward-facing cameras are covered by the fold, so FOLDED by itself implies
- * BACK_COVERED. But other devices may support folding but not cover any cameras
- * when folded, so for those FOLDED would not imply any of the other flags.
- * Since these relationships are very device-specific, it is difficult to specify
- * a comprehensive policy. But as a recommendation, it is suggested that if a flag
- * necessarily implies other flags are set as well, then those flags should be set.
- * So even though FOLDED would be enough to infer BACK_COVERED on some devices, the
- * BACK_COVERED flag should also be set for clarity.
- *
- * This method may be invoked by the HAL client at any time. It must not
- * cause any active camera device sessions to be closed, but may dynamically
- * change which physical camera a logical multi-camera is using for its
- * active and future output.
- *
- * The method must be invoked by the HAL client at least once before the
- * client calls ICameraDevice::open on any camera device interfaces listed
- * by this provider, to establish the initial device state.
- *
- * Note that the deviceState is 64-bit bitmask, with system defined states in
- * lower 32-bit and vendor defined states in upper 32-bit.
- */
- void (*notify_device_state_change)(uint64_t deviceState);
-
- /* reserved for future use */
- void* reserved[2];
-} camera_module_t;
-
-__END_DECLS
-
-#endif /* ANDROID_INCLUDE_CAMERA_COMMON_H */
projects / GitHub / LineageOS / android_hardware_samsung.git / commitdiff