Camera: HIDLized camera HALs, first set
* Common camera definitions (camera.common/1.0)
* Basic status codes, shared types
* Provider 2.4 API (camera.provider/2.4), including vendor tag APIs
* Enumerate and acquire camera device instances
* Mostly equivalent to legacy camera module v2.4.
* Device 1.0 API (camera.device/1.0)
* Mostly equivalent to legacy camera HAL v1.0.
* Device 3.2 API (camera.device/3.2)
* Mostly equivalent to legacy camera HAL v3.2.
* Metadata 3.2 API (camera.metadata/3.2)
* Definitions for valid metadata fields for device 3.2
Only the key initial interfaces are added; default implementations are
in a later CL. Other interfaces that will likely need to be added:
* Other provider minor versions
* Other device 3.x minor versions
Test: make -j32
Bug: 30985004
Bug: 32991603
Change-Id: I1c6a9a269bf45276055707bbc58cfc50d29fa919
diff --git a/camera/device/3.2/ICameraDeviceSession.hal b/camera/device/3.2/ICameraDeviceSession.hal
new file mode 100644
index 0000000..c8cc246
--- /dev/null
+++ b/camera/device/3.2/ICameraDeviceSession.hal
@@ -0,0 +1,360 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+package android.hardware.camera.device@3.2;
+
+import android.hardware.camera.common@1.0::types;
+
+/**
+ * Camera device active session interface.
+ *
+ * Obtained via ICameraDevice::open(), this interface contains the methods to
+ * configure and request captures from an active camera device.
+ *
+ */
+interface ICameraDeviceSession {
+
+ /**
+ * constructDefaultRequestSettings:
+ *
+ * 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.
+ *
+ * Performance requirements:
+ *
+ * This must be a non-blocking call. The HAL should return from this call
+ * in 1ms, and must return from this call in 5ms.
+ *
+ * Return values:
+ * @return status Status code for the operation, one of:
+ * OK:
+ * On a successful construction of default settings.
+ * INTERNAL_ERROR:
+ * An unexpected internal error occurred, and the default settings
+ * are not available.
+ * CAMERA_DISCONNECTED:
+ * An external camera device has been disconnected, and is no longer
+ * available. This camera device interface is now stale, and a new
+ * instance must be acquired if the device is reconnected. All
+ * subsequent calls on this interface must return
+ * CAMERA_DISCONNECTED.
+ * @return template The default capture request settings for the requested
+ * use case, or an empty metadata structure if status is not OK.
+ *
+ */
+ constructDefaultRequestSettings(RequestTemplate type) generates
+ (Status status, CameraMetadata requestTemplate);
+
+ /**
+ * configureStreams:
+ *
+ * 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 streamList. This method must be called at
+ * least once before a request is submitted with processCaptureRequest().
+ *
+ * The streamList must contain at least one output-capable stream, and may
+ * not contain more than one input-capable stream.
+ *
+ * The streamList may contain streams that are also in the currently-active
+ * set of streams (from the previous call to configureStreams()). These
+ * streams must already have valid values for usage, maxBuffers, 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 maxBuffers during the configure call.
+ *
+ * The framework must 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 streamList, the HAL may
+ * safely remove any references to that stream. It must not be reused in a
+ * later configureStreams() call by the framework, and all the gralloc
+ * buffers for it must be freed after the configureStreams() call returns.
+ *
+ * If the stream is new, the maxBuffer field of the stream structure must be
+ * set to 0. The usage must be set to the consumer usage flags. The HAL
+ * device must set these fields in the configureStreams() return values.
+ * 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 processCaptureResult (and its respective releaseFence has been
+ * signaled) the framework may free or reuse it at any time.
+ *
+ * ------------------------------------------------------------------------
+ *
+ * Preconditions:
+ *
+ * The framework must 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 must not
+ * submit new requests for capture while the configureStreams() 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 Status Status code for the operation, one of:
+ * OK:
+ * On successful stream configuration.
+ * INTERNAL_ERROR:
+ * 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.
+ * ILLEGAL_ARGUMENT:
+ * If the requested stream configuration is invalid. Some examples
+ * of invalid stream configurations include:
+ * - Including more than 1 INPUT stream
+ * - Not including any OUTPUT streams
+ * - Including streams with unsupported formats, or an unsupported
+ * size for that format.
+ * - Including too many output streams of a certain format.
+ * - Unsupported rotation configuration
+ * - 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.
+ * The camera service cannot filter out all possible illegal stream
+ * configurations, since some devices may support more simultaneous
+ * streams or larger stream resolutions than the minimum required
+ * for a given camera device hardware level. The HAL must return an
+ * ILLEGAL_ARGUMENT for any unsupported stream set, and then be
+ * ready to accept a future valid stream configuration in a later
+ * configureStreams call.
+ * @return finalConfiguration The stream parameters desired by the HAL for
+ * each stream, including maximum buffers, the usage flags, and the
+ * override format.
+ *
+ */
+ configureStreams(StreamConfiguration requestedConfiguration)
+ generates (Status status,
+ HalStreamConfiguration halConfiguration);
+
+ /**
+ * processCaptureRequest:
+ *
+ * Send a new capture request to the HAL. The HAL must not return from
+ * this call until it is ready to accept the next request to process. Only
+ * one call to processCaptureRequest() must be made at a time by the
+ * framework, and the calls must all be from the same thread. The next call
+ * to processCaptureRequest() must be made as soon as a new request and
+ * its associated buffers are available. In a normal preview scenario, this
+ * means the function is generally 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 processCaptureResult()
+ * 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
+ * valid. 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 must wait on the sync fence before refilling and reusing the
+ * input buffer.
+ *
+ * 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 must 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 status Status code for the operation, one of:
+ * OK:
+ * On a successful start to processing the capture request
+ * ILLEGAL_ARGUMENT:
+ * If the input is malformed (the settings are empty when not
+ * allowed, there are 0 output buffers, etc) and capture processing
+ * cannot start. Failures during request processing must be
+ * handled by calling ICameraDeviceCallback::notify(). In case of
+ * this error, the framework retains responsibility for the
+ * stream buffers' fences and the buffer handles; the HAL must not
+ * close the fences or return these buffers with
+ * ICameraDeviceCallback::processCaptureResult().
+ * INTERNAL_ERROR:
+ * 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.
+ *
+ */
+ processCaptureRequest(CaptureRequest request)
+ generates (Status status);
+
+ /**
+ * flush:
+ *
+ * Flush all currently in-process captures and all buffers in the pipeline
+ * on the given device. Generally, this method is used 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 must return errors immediately. Any
+ * interruptible hardware blocks must be stopped, and any uninterruptible
+ * blocks must be waited on.
+ *
+ * flush() may be called concurrently to processCaptureRequest(), with the
+ * expectation that processCaptureRequest returns quickly and the
+ * request submitted in that processCaptureRequest 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 processCaptureRequest() call may
+ * be started after flush has been invoked but has not returned yet. If such
+ * a call happens before flush() returns, the HAL must 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 must be
+ * completed normally by the HAL; i.e. the HAL can send shutter/notify
+ * and processCaptureResult 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 processCaptureResult 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
+ * processCaptureResults with buffers in CAMERA3_BUFFER_STATUS_ERROR
+ * are allowed. No further notifys or processCaptureResult with
+ * non-empty metadata is allowed.
+ *
+ * 3. For partially completed pending requests that do not have all the
+ * output buffers or perhaps missing metadata, the HAL must 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
+ * processCaptureResult.
+ *
+ * 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 must be passed to the framework as
+ * normal.
+ *
+ * 3.6. Failed buffers must 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 processCaptureResult with empty
+ * metadata or equivalent.
+ *
+ * 4. If a flush() is invoked while a processCaptureRequest() invocation
+ * is active, that process call must return as soon as possible. In
+ * addition, if a processCaptureRequest() call is made after flush()
+ * has been invoked but before flush() has returned, the capture request
+ * provided by the late processCaptureRequest call must be treated
+ * like a pending request in case #2 above.
+ *
+ * flush() must 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).
+ *
+ * @return status Status code for the operation, one of:
+ * OK:
+ * On a successful flush of the camera HAL.
+ * INTERNAL_ERROR:
+ * 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.
+ */
+ flush() generates (Status status);
+
+ /**
+ * close:
+ *
+ * Shut down the camera device.
+ *
+ * After this call, all calls to this session instance must return
+ * INTERNAL_ERROR.
+ *
+ * This method must always succeed, even if the device has encountered a
+ * serious error.
+ */
+ close();
+};