diff --git a/api/current.txt b/api/current.txt
index 5cef398a8a81a..46a4741080932 100644
--- a/api/current.txt
+++ b/api/current.txt
@@ -17036,6 +17036,7 @@ package android.hardware.camera2 {
field @NonNull public static final android.hardware.camera2.CameraCharacteristics.Key List of rotate-and-crop modes for {@link CaptureRequest#SCALER_ROTATE_AND_CROP android.scaler.rotateAndCrop} that are supported by this camera device. This entry lists the valid modes for {@link CaptureRequest#SCALER_ROTATE_AND_CROP android.scaler.rotateAndCrop} for this camera device. Starting with API level 30, all devices will list at least Range of valid values: Optional - The value for this key may be {@code null} on some devices. The area of the image sensor which corresponds to active pixels after any geometric
* distortion correction has been applied. No rotate and crop is applied. Processed outputs are in the sensor orientation. Processed images are rotated by 90 degrees clockwise, and then cropped
+ * to the original aspect ratio. Processed images are rotated by 180 degrees. Since the aspect ratio does not
+ * change, no cropping is performed. Processed images are rotated by 270 degrees clockwise, and then cropped
+ * to the original aspect ratio. The camera API automatically selects the best concrete value for
+ * rotate-and-crop based on the application's support for resizability and the current
+ * multi-window mode. If the application does not support resizing but the display mode for its main
+ * Activity is not in a typical orientation, the camera API will set When a value other than NONE is selected, several metadata fields will also be parsed
+ * differently to ensure that coordinates are correctly handled for features like drawing
+ * face detection boxes or passing in tap-to-focus coordinates. The camera API will
+ * convert positions in the active array coordinate system to/from the cropped-and-rotated
+ * coordinate system to make the operation transparent for applications. No coordinate mapping will be done when the application selects a non-AUTO mode. Whether a rotation-and-crop operation is applied to processed
+ * outputs from the camera. This control is primarily intended to help camera applications with no support for
+ * multi-window modes to work correctly on devices where multi-window scenarios are
+ * unavoidable, such as foldables or other devices with variable display geometry or more
+ * free-form window placement (such as laptops, which often place portrait-orientation apps
+ * in landscape with pillarboxing). If supported, the default value is When Capture results will contain the actual value selected by the API;
+ * Applications can also select their preferred cropping mode, either to opt out of the
+ * backwards-compatibility treatment, or to use the cropping feature themselves as needed.
+ * In this case, no coordinate translation will be done automatically, and all controls
+ * will continue to use the normal active array coordinates. Cropping and rotating is done after the application of digital zoom (via either
+ * {@link CaptureRequest#SCALER_CROP_REGION android.scaler.cropRegion} or {@link CaptureRequest#CONTROL_ZOOM_RATIO android.control.zoomRatio}), but before each individual
+ * output is further cropped and scaled. It only affects processed outputs such as
+ * YUV, PRIVATE, and JPEG. It has no effect on RAW outputs. When As a visual example, the figure below shows the effect of With these settings, the regions of the active array covered by the output streams are: Since the buffers are rotated, the buffers as seen by the application are: Possible values:
+ * ROTATE_AND_CROP_NONE.
+ * Devices with support for rotate-and-crop will additionally list at least
+ * ROTATE_AND_CROP_AUTO and ROTATE_AND_CROP_90.
+ * Any value listed in {@link CaptureRequest#SCALER_ROTATE_AND_CROP android.scaler.rotateAndCrop}ROTATE_AND_CROP_90
+ * or some other supported rotation value, depending on device configuration,
+ * to ensure preview and captured images are correctly shown to the user. Otherwise,
+ * ROTATE_AND_CROP_NONE will be selected.ROTATE_AND_CROP_AUTO, which allows the camera API
+ * to enable backwards-compatibility support for applications that do not support resizing
+ * / multi-window modes, when the device is in fact in a multi-window mode (such as inset
+ * portrait on laptops, or on a foldable device in some fold states). In addition,
+ * ROTATE_AND_CROP_NONE and ROTATE_AND_CROP_90 will always be available if this control
+ * is supported by the device. If not supported, devices API level 30 or higher will always
+ * list only ROTATE_AND_CROP_NONE.CROP_AUTO is in use, and the camera API activates backward-compatibility mode,
+ * several metadata fields will also be parsed differently to ensure that coordinates are
+ * correctly handled for features like drawing face detection boxes or passing in
+ * tap-to-focus coordinates. The camera API will convert positions in the active array
+ * coordinate system to/from the cropped-and-rotated coordinate system to make the
+ * operation transparent for applications. The following controls are affected:
+ *
+ * ROTATE_AND_CROP_AUTO will never be seen in a capture result.CROP_90 or CROP_270 are selected, there is a significant loss to the field of
+ * view. For example, with a 4:3 aspect ratio output of 1600x1200, CROP_90 will still
+ * produce 1600x1200 output, but these buffers are cropped from a vertical 3:4 slice at the
+ * center of the 4:3 area, then rotated to be 4:3, and then upscaled to 1600x1200. Only
+ * 56.25% of the original FOV is still visible. In general, for an aspect ratio of w:h,
+ * the crop and rotate operation leaves (h/w)^2 of the field of view visible. For 16:9,
+ * this is ~31.6%.ROTATE_AND_CROP_90 on the
+ * outputs for the following parameters:
+ *
+ * 2000x1500(500, 375), size: (1000, 750) (4:3 aspect ratio)640x480 and YUV 1280x720ROTATE_AND_CROP_90
+ *
+ * (219, 375), size: (562, 750)(289, 375), size: (422, 750)
+ *
+ * (781, 375) on active array, size: (640, 480), downscaled 1.17x from sensor pixels(711, 375) on active array, size: (1280, 720), upscaled 1.71x from sensor pixels
+ *
Available values for this device:
+ * {@link CameraCharacteristics#SCALER_AVAILABLE_ROTATE_AND_CROP_MODES android.scaler.availableRotateAndCropModes}
Optional - The value for this key may be {@code null} on some devices.
+ * + * @see CaptureRequest#CONTROL_AE_REGIONS + * @see CaptureRequest#CONTROL_AF_REGIONS + * @see CaptureRequest#CONTROL_AWB_REGIONS + * @see CaptureRequest#CONTROL_ZOOM_RATIO + * @see CameraCharacteristics#SCALER_AVAILABLE_ROTATE_AND_CROP_MODES + * @see CaptureRequest#SCALER_CROP_REGION + * @see CaptureResult#STATISTICS_FACES + * @see #SCALER_ROTATE_AND_CROP_NONE + * @see #SCALER_ROTATE_AND_CROP_90 + * @see #SCALER_ROTATE_AND_CROP_180 + * @see #SCALER_ROTATE_AND_CROP_270 + * @see #SCALER_ROTATE_AND_CROP_AUTO + */ + @PublicKey + @NonNull + public static final KeyDuration each pixel is exposed to * light.
diff --git a/core/java/android/hardware/camera2/CaptureResult.java b/core/java/android/hardware/camera2/CaptureResult.java index 9b305b32b61d8..26f29e38d37e8 100644 --- a/core/java/android/hardware/camera2/CaptureResult.java +++ b/core/java/android/hardware/camera2/CaptureResult.java @@ -3483,6 +3483,99 @@ public class CaptureResult extends CameraMetadataWhether a rotation-and-crop operation is applied to processed + * outputs from the camera.
+ *This control is primarily intended to help camera applications with no support for + * multi-window modes to work correctly on devices where multi-window scenarios are + * unavoidable, such as foldables or other devices with variable display geometry or more + * free-form window placement (such as laptops, which often place portrait-orientation apps + * in landscape with pillarboxing).
+ *If supported, the default value is ROTATE_AND_CROP_AUTO, which allows the camera API
+ * to enable backwards-compatibility support for applications that do not support resizing
+ * / multi-window modes, when the device is in fact in a multi-window mode (such as inset
+ * portrait on laptops, or on a foldable device in some fold states). In addition,
+ * ROTATE_AND_CROP_NONE and ROTATE_AND_CROP_90 will always be available if this control
+ * is supported by the device. If not supported, devices API level 30 or higher will always
+ * list only ROTATE_AND_CROP_NONE.
When CROP_AUTO is in use, and the camera API activates backward-compatibility mode,
+ * several metadata fields will also be parsed differently to ensure that coordinates are
+ * correctly handled for features like drawing face detection boxes or passing in
+ * tap-to-focus coordinates. The camera API will convert positions in the active array
+ * coordinate system to/from the cropped-and-rotated coordinate system to make the
+ * operation transparent for applications. The following controls are affected:
Capture results will contain the actual value selected by the API;
+ * ROTATE_AND_CROP_AUTO will never be seen in a capture result.
Applications can also select their preferred cropping mode, either to opt out of the + * backwards-compatibility treatment, or to use the cropping feature themselves as needed. + * In this case, no coordinate translation will be done automatically, and all controls + * will continue to use the normal active array coordinates.
+ *Cropping and rotating is done after the application of digital zoom (via either + * {@link CaptureRequest#SCALER_CROP_REGION android.scaler.cropRegion} or {@link CaptureRequest#CONTROL_ZOOM_RATIO android.control.zoomRatio}), but before each individual + * output is further cropped and scaled. It only affects processed outputs such as + * YUV, PRIVATE, and JPEG. It has no effect on RAW outputs.
+ *When CROP_90 or CROP_270 are selected, there is a significant loss to the field of
+ * view. For example, with a 4:3 aspect ratio output of 1600x1200, CROP_90 will still
+ * produce 1600x1200 output, but these buffers are cropped from a vertical 3:4 slice at the
+ * center of the 4:3 area, then rotated to be 4:3, and then upscaled to 1600x1200. Only
+ * 56.25% of the original FOV is still visible. In general, for an aspect ratio of w:h,
+ * the crop and rotate operation leaves (h/w)^2 of the field of view visible. For 16:9,
+ * this is ~31.6%.
As a visual example, the figure below shows the effect of ROTATE_AND_CROP_90 on the
+ * outputs for the following parameters:
2000x1500(500, 375), size: (1000, 750) (4:3 aspect ratio)640x480 and YUV 1280x720ROTATE_AND_CROP_90
With these settings, the regions of the active array covered by the output streams are:
+ *(219, 375), size: (562, 750)(289, 375), size: (422, 750)Since the buffers are rotated, the buffers as seen by the application are:
+ *(781, 375) on active array, size: (640, 480), downscaled 1.17x from sensor pixels(711, 375) on active array, size: (1280, 720), upscaled 1.71x from sensor pixelsPossible values: + *
Available values for this device:
+ * {@link CameraCharacteristics#SCALER_AVAILABLE_ROTATE_AND_CROP_MODES android.scaler.availableRotateAndCropModes}
Optional - The value for this key may be {@code null} on some devices.
+ * + * @see CaptureRequest#CONTROL_AE_REGIONS + * @see CaptureRequest#CONTROL_AF_REGIONS + * @see CaptureRequest#CONTROL_AWB_REGIONS + * @see CaptureRequest#CONTROL_ZOOM_RATIO + * @see CameraCharacteristics#SCALER_AVAILABLE_ROTATE_AND_CROP_MODES + * @see CaptureRequest#SCALER_CROP_REGION + * @see CaptureResult#STATISTICS_FACES + * @see #SCALER_ROTATE_AND_CROP_NONE + * @see #SCALER_ROTATE_AND_CROP_90 + * @see #SCALER_ROTATE_AND_CROP_180 + * @see #SCALER_ROTATE_AND_CROP_270 + * @see #SCALER_ROTATE_AND_CROP_AUTO + */ + @PublicKey + @NonNull + public static final KeyDuration each pixel is exposed to * light.
diff --git a/docs/html/reference/images/camera2/metadata/android.scaler.rotateAndCrop/crop-region-rotate-90-43-ratio.png b/docs/html/reference/images/camera2/metadata/android.scaler.rotateAndCrop/crop-region-rotate-90-43-ratio.png new file mode 100644 index 0000000000000..2633996521b5d Binary files /dev/null and b/docs/html/reference/images/camera2/metadata/android.scaler.rotateAndCrop/crop-region-rotate-90-43-ratio.png differ