+ <section name="logicalMultiCamera">
+ <static>
+ <entry name="physicalIds" type="byte" visibility="hidden"
+ container="array" hwlevel="limited" hal_version="3.3">
+ <array>
+ <size>n</size>
+ </array>
+ <description>String containing the ids of the underlying physical cameras.
+ </description>
+ <units>UTF-8 null-terminated string</units>
+ <details>
+ For a logical camera, this is concatenation of all underlying physical camera ids.
+ The null terminator for physical camera id must be preserved so that the whole string
+ can be tokenized using '\0' to generate list of physical camera ids.
+
+ For example, if the physical camera ids of the logical camera are "2" and "3", the
+ value of this tag will be ['2', '\0', '3', '\0'].
+
+ The number of physical camera ids must be no less than 2.
+ </details>
+ <tag id="LOGICALCAMERA" />
+ </entry>
+ <entry name="sensorSyncType" type="byte" visibility="public"
+ enum="true" hwlevel="limited" hal_version="3.3">
+ <enum>
+ <value>APPROXIMATE
+ <notes>
+ A software mechanism is used to synchronize between the physical cameras. As a result,
+ the timestamp of an image from a physical stream is only an approximation of the
+ image sensor start-of-exposure time.
+ </notes>
+ </value>
+ <value>CALIBRATED
+ <notes>
+ The camera device supports frame timestamp synchronization at the hardware level,
+ and the timestamp of a physical stream image accurately reflects its
+ start-of-exposure time.
+ </notes>
+ </value>
+ </enum>
+ <description>The accuracy of frame timestamp synchronization between physical cameras</description>
+ <details>
+ The accuracy of the frame timestamp synchronization determines the physical cameras'
+ ability to start exposure at the same time. If the sensorSyncType is CALIBRATED,
+ the physical camera sensors usually run in master-slave mode so that their shutter
+ time is synchronized. For APPROXIMATE sensorSyncType, the camera sensors usually run in
+ master-master mode, and there could be offset between their start of exposure.
+
+ In both cases, all images generated for a particular capture request still carry the same
+ timestamps, so that they can be used to look up the matching frame number and
+ onCaptureStarted callback.
+ </details>
+ <tag id="LOGICALCAMERA" />
+ </entry>
+ </static>
+ </section>
+ <section name="distortionCorrection">
+ <controls>
+ <entry name="mode" type="byte" visibility="public" enum="true" hal_version="3.3">
+ <enum>
+ <value>OFF
+ <notes>No distortion correction is applied.</notes></value>
+ <value>FAST <notes>Lens distortion correction is applied without reducing frame rate
+ relative to sensor output. It may be the same as OFF if distortion correction would
+ reduce frame rate relative to sensor.</notes></value>
+ <value>HIGH_QUALITY <notes>High-quality distortion correction is applied, at the cost of
+ possibly reduced frame rate relative to sensor output.</notes></value>
+ </enum>
+ <description>Mode of operation for the lens distortion correction block.</description>
+ <range>android.distortionCorrection.availableModes</range>
+ <details>The lens distortion correction block attempts to improve image quality by fixing
+ radial, tangential, or other geometric aberrations in the camera device's optics. If
+ available, the android.lens.distortion field documents the lens's distortion parameters.
+
+ OFF means no distortion correction is done.
+
+ FAST/HIGH_QUALITY both mean camera device determined distortion correction will be
+ applied. HIGH_QUALITY mode indicates that the camera device will use the highest-quality
+ correction algorithms, even if it slows down capture rate. FAST means the camera device
+ will not slow down capture rate when applying correction. FAST may be the same as OFF if
+ any correction at all would slow down capture rate. Every output stream will have a
+ similar amount of enhancement applied.
+
+ The correction only applies to processed outputs such as YUV, JPEG, or DEPTH16; it is not
+ applied to any RAW output. Metadata coordinates such as face rectangles or metering
+ regions are also not affected by correction.
+
+ Applications enabling distortion correction need to pay extra attention when converting
+ image coordinates between corrected output buffers and the sensor array. For example, if
+ the app supports tap-to-focus and enables correction, it then has to apply the distortion
+ model described in android.lens.distortion to the image buffer tap coordinates to properly
+ calculate the tap position on the sensor active array to be used with
+ android.control.afRegions. The same applies in reverse to detected face rectangles if
+ they need to be drawn on top of the corrected output buffers.
+ </details>
+ </entry>
+ </controls>
+ <static>
+ <entry name="availableModes" type="byte" visibility="public"
+ type_notes="list of enums" container="array" typedef="enumList" hal_version="3.3">
+ <array>
+ <size>n</size>
+ </array>
+ <description>
+ List of distortion correction modes for android.distortionCorrection.mode that are
+ supported by this camera device.
+ </description>
+ <range>Any value listed in android.distortionCorrection.mode</range>
+ <details>
+ No device is required to support this API; such devices will always list only 'OFF'.
+ All devices that support this API will list both FAST and HIGH_QUALITY.
+ </details>
+ <hal_details>
+ HAL must support both FAST and HIGH_QUALITY if distortion correction is available
+ on the camera device, but the underlying implementation can be the same for both modes.
+ That is, if the highest quality implementation on the camera device does not slow down
+ capture rate, then FAST and HIGH_QUALITY will generate the same output.
+ </hal_details>
+ <tag id="V1" />
+ <tag id="REPROC" />
+ </entry>
+ </static>
+ <dynamic>
+ <clone entry="android.distortionCorrection.mode" kind="controls" hal_version="3.3">
+ </clone>
+ </dynamic>
+ </section>