<tag id="REPROC">
Entry is required for the YUV or PRIVATE reprocessing capability.
</tag>
+ <tag id="LOGICALCAMERA">
+ Entry is required for logical multi-camera capability.
+ </tag>
<tag id="FUTURE">
Entry is under-specified and is not required for now. This is for book-keeping purpose,
do not implement or use it, it may be revised for future.
sequence.
</notes>
</value>
+ <value hal_version="3.3">ON_EXTERNAL_FLASH
+ <notes>
+ An external flash has been turned on.
+
+ It informs the camera device that an external flash has been turned on, and that
+ metering (and continuous focus if active) should be quickly recaculated to account
+ for the external flash. Otherwise, this mode acts like ON.
+
+ When the external flash is turned off, AE mode should be changed to one of the
+ other available AE modes.
+
+ If the camera device supports AE external flash mode, aeState must be
+ FLASH_REQUIRED after the camera device finishes AE scan and it's too dark without
+ flash.
+ </notes>
+ </value>
</enum>
<description>The desired mode for the camera device's
auto-exposure routine.</description>
:------------:|:----------------:|:---------:|:-----------------------:
INACTIVE | | INACTIVE | Camera device auto exposure algorithm is disabled
- When android.control.aeMode is AE_MODE_ON_*:
+ When android.control.aeMode is AE_MODE_ON*:
State | Transition Cause | New State | Notes
:-------------:|:--------------------------------------------:|:--------------:|:-----------------:
Any state (excluding LOCKED) | android.control.aePrecaptureTrigger is START | PRECAPTURE | Start AE precapture metering sequence
Any state (excluding LOCKED) | android.control.aePrecaptureTrigger is CANCEL| INACTIVE | Currently active precapture metering sequence is canceled
+ If the camera device supports AE external flash mode (ON_EXTERNAL_FLASH is included in
+ android.control.aeAvailableModes), aeState must be FLASH_REQUIRED after the camera device
+ finishes AE scan and it's too dark without flash.
+
For the above table, the camera device may skip reporting any state changes that happen
without application intervention (i.e. mode switch, trigger, locking). Any state that
can be skipped in that manner is called a transient state.
- For example, for above AE modes (AE_MODE_ON_*), in addition to the state transitions
+ For example, for above AE modes (AE_MODE_ON*), in addition to the state transitions
listed in above table, it is also legal for the camera device to skip one or more
transient states between two results. See below table for examples:
<dynamic>
<clone entry="android.control.enableZsl" kind="controls">
</clone>
- <entry name="afSceneChange" type="int32" visibility="public" enum="true" hal_version="3.3">
+ <entry name="afSceneChange" type="byte" visibility="public" enum="true" hal_version="3.3">
<enum>
<value>NOT_DETECTED
<notes>Scene change is not detected within the AF region(s).</notes></value>
result. Otherwise the value will be NOT_DETECTED. The threshold for detection is similar
to what would trigger a new passive focus scan to begin in CONTINUOUS autofocus modes.
- afSceneChange may be DETECTED only if afMode is AF_MODE_CONTINUOUS_VIDEO or
- AF_MODE_CONTINUOUS_PICTURE. In other AF modes, afSceneChange must be NOT_DETECTED.
-
This key will be available if the camera device advertises this key via {@link
android.hardware.camera2.CameraCharacteristics#getAvailableCaptureResultKeys|ACAMERA_REQUEST_AVAILABLE_RESULT_KEYS}.
</details>
<notes>The value of android.lens.poseTranslation is relative to the optical center of
the largest camera device facing the same direction as this camera.
- This default value for API levels before Android P.
+ This is the default value for API levels before Android P.
</notes>
</value>
<value>GYROSCOPE
<notes>The value of android.lens.poseTranslation is relative to the position of the
primary gyroscope of this Android device.
-
- This is the value reported by all devices that support the MOTION_TRACKING capability.
</notes>
</value>
</enum>
<details>
Different calibration methods and use cases can produce better or worse results
depending on the selected coordinate origin.
-
- For devices designed to support the MOTION_TRACKING capability, the GYROSCOPE origin
- makes device calibration and later usage by applications combining camera and gyroscope
- information together simpler.
</details>
</entry>
</static>
</value>
<value optional="true" hal_version="3.3" >MOTION_TRACKING
<notes>
- The device supports controls and metadata required for accurate motion tracking for
- use cases such as augmented reality, electronic image stabilization, and so on.
+ The camera device supports the MOTION_TRACKING value for
+ android.control.captureIntent, which limits maximum exposure time to 20 ms.
- This means this camera device has accurate optical calibration and timestamps relative
- to the inertial sensors.
+ This limits the motion blur of capture images, resulting in better image tracking
+ results for use cases such as image stabilization or augmented reality.
+ </notes>
+ </value>
+ <value optional="true" hal_version="3.3">LOGICAL_MULTI_CAMERA
+ <notes>
+ The camera device is a logical camera backed by two or more physical cameras that are
+ also exposed to the application.
This capability requires the camera device to support the following:
- * Capture request templates {@link
- android.hardware.camera2.CameraDevice#TEMPLATE_MOTION_TRACKING_PREVIEW} and {@link
- android.hardware.camera2.CameraDevice#TEMPLATE_MOTION_TRACKING_BEST} are defined.
- * The stream configurations listed in {@link
- android.hardware.camera2.CameraDevice#createCaptureSession} for MOTION_TRACKING are
- supported, either at 30 or 60fps maximum frame rate.
- * The following camera characteristics and capture result metadata are provided:
- - android.lens.intrinsicCalibration
- - android.lens.radialDistortion
+ * This camera device must list the following static metadata entries in {@link
+ android.hardware.camera2.CameraCharacteristics}:
+ - android.logicalMultiCamera.physicalIds
+ - android.logicalMultiCamera.sensorSyncType
+ * The underlying physical cameras' static metadata must list the following entries,
+ so that the application can correlate pixels from the physical streams:
+ - android.lens.poseReference
- android.lens.poseRotation
- android.lens.poseTranslation
- - android.lens.poseReference with value GYROSCOPE
- * The android.sensor.info.timestampSource field has value `REALTIME`. When compared to
- timestamps from the device's gyroscopes, the clock difference for events occuring at
- the same actual time instant will be less than 1 ms.
- * The value of the android.sensor.rollingShutterSkew field is accurate to within 1 ms.
- * The value of android.sensor.exposureTime is guaranteed to be available in the
- capture result.
- * The android.control.captureIntent control supports MOTION_TRACKING to limit maximum
- exposure to 20 milliseconds.
- * The stream configurations required for MOTION_TRACKING (listed at {@link
- android.hardware.camera2.CameraDevice#createCaptureSession}) can operate at least at
- 30fps; optionally, they can operate at 60fps, and '[60, 60]' is listed in
- android.control.aeAvailableTargetFpsRanges.
+ - android.lens.intrinsicCalibration
+ - android.lens.radialDistortion
+ * The logical camera device must be LIMITED or higher device.
+
+ Both the logical camera device and its underlying physical devices support the
+ mandatory stream combinations required for their device levels.
+
+ Additionally, for each guaranteed stream combination, the logical camera supports:
+
+ * Replacing one logical {@link android.graphics.ImageFormat#YUV_420_888|AIMAGE_FORMAT_YUV_420_888 YUV_420_888}
+ or raw stream with two physical streams of the same size and format, each from a
+ separate physical camera, given that the size and format are supported by both
+ physical cameras.
+ * Adding two raw streams, each from one physical camera, if the logical camera doesn't
+ advertise RAW capability, but the underlying physical cameras do. This is usually
+ the case when the physical cameras have different sensor sizes.
+
+ Using physical streams in place of a logical stream of the same size and format will
+ not slow down the frame rate of the capture, as long as the minimum frame duration
+ of the physical and logical streams are the same.
</notes>
</value>
+
</enum>
<description>List of capabilities that this camera device
advertises as fully supporting.</description>
enum notes. The entry android.depth.maxDepthSamples must be available
if the DEPTH_POINT_CLOUD format is supported (HAL pixel format BLOB, dataspace
DEPTH).
+
+ For a camera device with LOGICAL_MULTI_CAMERA capability, it should operate in the
+ same way as a physical camera device based on its hardware level and capabilities.
+ It's recommended that its feature set is superset of that of individual physical cameras.
</hal_details>
</entry>
<entry name="availableRequestKeys" type="int32" visibility="ndk_public"
</hal_details>
</entry>
<entry name="availableSessionKeys" type="int32" visibility="ndk_public"
- container="array" hwlevel="legacy" hal_version="3.4">
+ container="array" hwlevel="legacy" hal_version="3.3">
<array>
<size>n</size>
</array>
lifetime. Typical examples include parameters that require a
time-consuming hardware re-configuration or internal camera pipeline
change. For performance reasons we advise clients to pass their initial
- values as part of
+ values as part of
{@link SessionConfiguration#setSessionParameters|ACameraDevice_createCaptureSessionWithSessionParameters}.
Once the camera capture session is enabled it is also recommended to avoid
changing them from their initial values set in
{@link android.hardware.camera2.CameraCharacteristics#getAvailableSessionKeys}.
</hal_details>
</entry>
+ <entry name="availablePhysicalCameraRequestKeys" type="int32" visibility="hidden"
+ container="array" hwlevel="limited" hal_version="3.3">
+ <array>
+ <size>n</size>
+ </array>
+ <description>A subset of the available request keys that can be overriden for
+ physical devices backing a logical multi-camera.</description>
+ <details>
+ This is a subset of android.request.availableRequestKeys which contains a list
+ of keys that can be overriden using {@link CaptureRequest.Builder#setPhysicalCameraKey}.
+ The respective value of such request key can be obtained by calling
+ {@link CaptureRequest.Builder#getPhysicalCameraKey}. Capture requests that contain
+ individual physical device requests must be built via
+ {@link android.hardware.camera2.CameraDevice#createCaptureRequest(int, Set)}.
+ </details>
+ <hal_details>
+ Vendor tags can be listed here. Vendor tag metadata should also
+ use the extensions C api (refer to
+ android.hardware.camera.device.V3_4.CaptureRequest.physicalCameraSettings for more
+ details).
+
+ Setting/getting vendor tags will be checked against the metadata
+ vendor extensions API and not against this field.
+
+ The HAL must not consume any request tags in the session parameters that
+ are not listed either here or in the vendor tag list.
+
+ There should be no overlap between this set of keys and the available session keys
+ {@link android.hardware.camera2.CameraCharacteristics#getAvailableSessionKeys} along
+ with any other controls that can have impact on the dual-camera sync.
+
+ The public camera2 API will always make the vendor tags visible
+ via
+ {@link android.hardware.camera2.CameraCharacteristics#getAvailablePhysicalCameraRequestKeys}.
+ </hal_details>
+ </entry>
</static>
</section>
<section name="scaler">
LEGACY mode devices will always only support OFF.
</details>
</entry>
+ <entry name="availableOisDataModes" 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 OIS data output modes for android.statistics.oisDataMode that
+ are supported by this camera device.
+ </description>
+ <range>Any value listed in android.statistics.oisDataMode</range>
+ <details>
+ If no OIS data output is available for this camera device, this key will
+ contain only OFF.
+ </details>
+ </entry>
</namespace>
</static>
<dynamic>
<clone entry="android.statistics.lensShadingMapMode" kind="controls">
</clone>
</dynamic>
+ <controls>
+ <entry name="oisDataMode" type="byte" visibility="public" enum="true" hal_version="3.3">
+ <enum>
+ <value>OFF
+ <notes>Do not include OIS data in the capture result.</notes></value>
+ <value>ON
+ <notes>Include OIS data in the capture result.</notes></value>
+ </enum>
+ <description>A control for selecting whether OIS position information is included in output
+ result metadata.</description>
+ <range>android.Statistics.info.availableOisDataModes</range>
+ <details>When set to ON,
+ android.statistics.oisTimestamps, android.statistics.oisShiftPixelX,
+ and android.statistics.oisShiftPixelY provide OIS data in the output result metadata.
+ </details>
+ </entry>
+ </controls>
+ <dynamic>
+ <clone entry="android.statistics.oisDataMode" kind="controls">
+ </clone>
+ <entry name="oisTimestamps" type="int64" visibility="public" container="array" hal_version="3.3">
+ <array>
+ <size>n</size>
+ </array>
+ <description>
+ An array of timestamps of OIS samples, in nanoseconds.
+ </description>
+ <units>nanoseconds</units>
+ <details>
+ The array contains the timestamps of OIS samples. The timestamps are in the same
+ timebase as and comparable to android.sensor.timestamp.
+ </details>
+ </entry>
+ <entry name="oisXShifts" type="float" visibility="public" container="array" hal_version="3.3">
+ <array>
+ <size>n</size>
+ </array>
+ <description>
+ An array of shifts of OIS samples, in x direction.
+ </description>
+ <units>Pixels in active array.</units>
+ <details>
+ The array contains the amount of shifts in x direction, in pixels, based on OIS samples.
+ A positive value is a shift from left to right in active array coordinate system. For
+ example, if the optical center is (1000, 500) in active array coordinates, an shift of
+ (3, 0) puts the new optical center at (1003, 500).
+
+ The number of shifts must match the number of timestamps in
+ android.statistics.oisTimestamps.
+ </details>
+ </entry>
+ <entry name="oisYShifts" type="float" visibility="public" container="array" hal_version="3.3">
+ <array>
+ <size>n</size>
+ </array>
+ <description>
+ An array of shifts of OIS samples, in y direction.
+ </description>
+ <units>Pixels in active array.</units>
+ <details>
+ The array contains the amount of shifts in y direction, in pixels, based on OIS samples.
+ A positive value is a shift from top to bottom in active array coordinate system. For
+ example, if the optical center is (1000, 500) in active array coordinates, an shift of
+ (0, 5) puts the new optical center at (1000, 505).
+
+ The number of shifts must match the number of timestamps in
+ android.statistics.oisTimestamps.
+ </details>
+ </entry>
+ </dynamic>
</section>
<section name="tonemap">
<controls>
`RAW`)
</notes>
</value>
+ <value hal_version="3.3">
+ EXTERNAL
+ <notes>
+ This camera device is backed by an external camera connected to this Android device.
+
+ The device has capability identical to a LIMITED level device, with the following
+ exceptions:
+
+ * The device may not report lens/sensor related information such as
+ - android.lens.focalLength
+ - android.lens.info.hyperfocalDistance
+ - android.sensor.info.physicalSize
+ - android.sensor.info.whiteLevel
+ - android.sensor.blackLevelPattern
+ - android.sensor.info.colorFilterArrangement
+ - android.sensor.rollingShutterSkew
+ * The device will report 0 for android.sensor.orientation
+ * The device has less guarantee on stable framerate, as the framerate partly depends
+ on the external camera being used.
+ </notes>
+ </value>
</enum>
<description>
Generally classifies the overall set of the camera device functionality.
Camera HAL3+ must not implement LEGACY mode. It is there for backwards compatibility in
the `android.hardware.camera2` user-facing API only on legacy HALv1 devices, and is
implemented by the camera framework code.
+
+ EXTERNAL level devices have lower peformance bar in CTS since the peformance might depend
+ on the external camera being used and is not fully controlled by the device manufacturer.
+ The ITS test suite is exempted for the same reason.
</hal_details>
</entry>
<entry name="version" type="byte" visibility="public" typedef="string" hal_version="3.3">
</entry>
</static>
</section>
+ <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>
</namespace>
</metadata>
OSDN Git Service
