CameraConstrainedHighSpeedCaptureSession

Discard all captures currently pending and in-progress as fast as possible.

The camera device will discard all of its current work as fast as possible. Some in-flight captures may complete successfully and call CaptureCallback.onCaptureCompleted, while others will trigger their CaptureCallback.onCaptureFailed callbacks. If a repeating request or a repeating burst is set, it will be cleared.

This method is the fastest way to switch the camera device to a new session with android.hardware.camera2.CameraDevice#createCaptureSession or CameraDevice.createReprocessableCaptureSession, at the cost of discarding in-progress work. It must be called before the new session is created. Once all pending requests are either completed or thrown away, the StateCallback.onReady callback will be called, if the session has not been closed. Otherwise, the StateCallback.onClosed callback will be fired when a new session is created by the camera device.

Cancelling will introduce at least a brief pause in the stream of data from the camera device, since once the camera device is emptied, the first new request has to make it through the entire camera pipeline before new output buffers are produced.

This means that using abortCaptures() to simply remove pending requests is not recommended; it's best used for quickly switching output configurations, or for cancelling long in-progress requests (such as a multi-second capture).

Submit a request for an image to be captured by the camera device.

The request defines all the parameters for capturing the single image, including sensor, lens, flash, and post-processing settings.

Each request will produce one CaptureResult and produce new frames for one or more target Surfaces, set with the CaptureRequest builder's CaptureRequest.Builder.addTarget method. The target surfaces (set with CaptureRequest.Builder.addTarget) must be a subset of the surfaces provided when this capture session was created.

Multiple regular and reprocess requests can be in progress at once. If there are only regular requests or reprocess requests in progress, they are processed in first-in, first-out order. If there are both regular and reprocess requests in progress, regular requests are processed in first-in, first-out order and reprocess requests are processed in first-in, first-out order, respectively. However, the processing order of a regular request and a reprocess request in progress is not specified. In other words, a regular request will always be processed before regular requests that are submitted later. A reprocess request will always be processed before reprocess requests that are submitted later. However, a regular request may not be processed before reprocess requests that are submitted later.

Requests submitted through this method have higher priority than those submitted through setRepeatingRequest or setRepeatingBurst, and will be processed as soon as the current repeat/repeatBurst processing completes.

All capture sessions can be used for capturing images from the camera but only capture sessions created by createReprocessableCaptureSession can submit reprocess capture requests. Submitting a reprocess request to a regular capture session will result in an IllegalArgumentException.

Submitting a request that targets Surfaces with an unsupported dynamic range combination will result in an IllegalArgumentException.

Submit a list of requests to be captured in sequence as a burst. The burst will be captured in the minimum amount of time possible, and will not be interleaved with requests submitted by other capture or repeat calls.

Regular and reprocess requests can be mixed together in a single burst. Regular requests will be captured in order and reprocess requests will be processed in order, respectively. However, the processing order between a regular request and a reprocess request is not specified. Each capture produces one CaptureResult and image buffers for one or more target surfaces. The target surfaces (set with CaptureRequest.Builder.addTarget) must be a subset of the surfaces provided when this capture session was created.

The main difference between this method and simply calling capture repeatedly is that this method guarantees that no other requests will be interspersed with the burst.

All capture sessions can be used for capturing images from the camera but only capture sessions created by createReprocessableCaptureSession can submit reprocess capture requests. Submitting a reprocess request to a regular capture session will result in an IllegalArgumentException.

Submitting a request that targets Surfaces with an unsupported dynamic range combination will result in an IllegalArgumentException.

Submit a list of requests to be captured in sequence as a burst. The burst will be captured in the minimum amount of time possible, and will not be interleaved with requests submitted by other capture or repeat calls.

The behavior of this method matches that of captureBurst(List,CaptureCallback,Handler), except that it uses java.util.concurrent.Executor as an argument instead of android.os.Handler.

Submit a request for an image to be captured by the camera device.

The behavior of this method matches that of capture(CaptureRequest,CaptureCallback,Handler), except that it uses java.util.concurrent.Executor as an argument instead of android.os.Handler.

Close this capture session asynchronously.

Closing a session frees up the target output Surfaces of the session for reuse with either a new session, or to other APIs that can draw to Surfaces.

Note that for common usage scenarios like creating a new session or closing the camera device, it is faster to call respective APIs directly (see below for more details) without calling into this method. This API is only useful when application wants to unconfigure the camera but keep the device open for later use.

Creating a new capture session with android.hardware.camera2.CameraDevice#createCaptureSession will close any existing capture session automatically, and call the older session listener's StateCallback.onClosed callback. Using android.hardware.camera2.CameraDevice#createCaptureSession directly without closing is the recommended approach for quickly switching to a new session, since unchanged target outputs can be reused more efficiently.

Closing the device with CameraDevice.close directly without calling this API is also recommended for quickly closing the camera.

Once a session is closed, all methods on it will throw an IllegalStateException, and any repeating requests or bursts are stopped (as if stopRepeating() was called). However, any in-progress capture requests submitted to the session will be completed as normal; once all captures have completed and the session has been torn down, StateCallback.onClosed will be called.

Closing a session is idempotent; closing more than once has no effect.

Finalize the output configurations that now have their deferred and/or extra Surfaces included.

For camera use cases where a preview and other output configurations need to be configured, it can take some time for the preview Surface to be ready. For example, if the preview Surface is obtained from android.view.SurfaceView, the SurfaceView will only be ready after the UI layout is done, potentially delaying camera startup.

To speed up camera startup time, the application can configure the CameraCaptureSession with the eventual preview size (via android.hardware.camera2.params.OutputConfiguration#OutputConfiguration(Size,java.lang.Class)), and defer the preview output configuration until the Surface is ready. After the CameraCaptureSession is created successfully with this deferred output and other normal outputs, the application can start submitting requests as long as they do not include deferred output Surfaces. Once a deferred Surface is ready, the application can add the Surface to the deferred output configuration with the OutputConfiguration.addSurface method, and then update the deferred output configuration via this method, before it can submit capture requests with this output target.

This function can also be called in case where multiple surfaces share the same OutputConfiguration, and one of the surfaces becomes available after the CameraCaptureSession is created. In that case, the application must first create the OutputConfiguration with the available Surface, then enable further surface sharing via OutputConfiguration.enableSurfaceSharing, before creating the CameraCaptureSession. After the CameraCaptureSession is created, and once the extra Surface becomes available, the application must then call OutputConfiguration.addSurface before finalizing the configuration with this method.

If the provided OutputConfigurations are unchanged from session creation, this function call has no effect. This function must only be called once for a particular output configuration.

Starting with Android C deferred Surfaces can be dynamically updated by calling updateOutputConfigurations(List). Using deferred surface updates, clients will no longer be limited to finalizing surfaces a single time and will be enabled to switch to and from deferred surface state at any time.

The output Surfaces included by this list of OutputConfigurations can be used as CaptureRequest targets as soon as this call returns.

This method is not supported by LEGACY-level devices.

Get the camera device that this session is created for.

Get the input Surface associated with a reprocessable capture session.

Each reprocessable capture session has an input Surface where the reprocess capture requests get the input images from, rather than the camera device. The application can create a ImageWriter with this input Surface and use it to provide input images for reprocess capture requests. When the reprocessable capture session is closed, the input Surface is abandoned and becomes invalid.

Return if the application can submit reprocess capture requests with this camera capture session.

Pre-allocate all buffers for an output Surface.

Normally, the image buffers for a given output Surface are allocated on-demand, to minimize startup latency and memory overhead.

However, in some cases, it may be desirable for the buffers to be allocated before any requests targeting the Surface are actually submitted to the device. Large buffers may take some time to allocate, which can result in delays in submitting requests until sufficient buffers are allocated to reach steady-state behavior. Such delays can cause bursts to take longer than desired, or cause skips or stutters in preview output.

The prepare() method can be used to perform this preallocation. It may only be called for a given output Surface before that Surface is used as a target for a request. The number of buffers allocated is the sum of the count needed by the consumer providing the output Surface, and the maximum number needed by the camera device to fill its pipeline. Since this may be a larger number than what is actually required for steady-state operation, using prepare may result in higher memory consumption than the normal on-demand behavior results in. Prepare() will also delay the time to first output to a given Surface, in exchange for smoother frame rate once the allocation is complete.

For example, an application that creates an android.media.ImageReader#newInstance with a maxImages argument of 10, but only uses 3 simultaneous Images at once would normally only cause those 3 images to be allocated (plus what is needed by the camera device for smooth operation). But using prepare() on the ImageReader Surface will result in all 10 Images being allocated. So applications using this method should take care to request only the number of buffers actually necessary for their application.

If the same output Surface is used in consecutive sessions (without closing the first session explicitly), then its already-allocated buffers are carried over, and if it was used as a target of a capture request in the first session, prepare cannot be called on it in the second session.

Once allocation is complete, StateCallback.onSurfacePrepared will be invoked with the Surface provided to this method. Between the prepare call and the onSurfacePrepared call, the Surface provided to prepare must not be used as a target of a CaptureRequest submitted to this session.

Note that if 2 surfaces share the same stream via OutputConfiguration.enableSurfaceSharing and OutputConfiguration.addSurface, prepare() only needs to be called on one surface, and StateCallback.onSurfacePrepared will be triggered for both surfaces.

LEGACY devices cannot pre-allocate output buffers; for those devices, StateCallback.onSurfacePrepared will be immediately called, and no preallocation is done.

Request endlessly repeating capture of a sequence of images by this capture session.

With this method, the camera device will continually capture images, cycling through the settings in the provided list of CaptureRequests, at the maximum rate possible.

If a request is submitted through capture or captureBurst, the current repetition of the request list will be completed before the higher-priority request is handled. This guarantees that the application always receives a complete repeat burst captured in minimal time, instead of bursts interleaved with higher-priority captures, or incomplete captures.

Repeating burst requests are a simple way for an application to maintain a preview or other continuous stream of frames where each request is different in a predictable way, without having to continually submit requests through captureBurst.

To stop the repeating capture, call stopRepeating. Any ongoing burst will still be completed, however. Calling abortCaptures will also clear the request.

Calling this method will replace a previously-set repeating request or burst set up by this method or setRepeatingRequest, although any in-progress burst will be completed before the new repeat burst will be used.

This method does not support reprocess capture requests because each reprocess CaptureRequest must be created from the TotalCaptureResult that matches the input image to be reprocessed. This is either the TotalCaptureResult of capture that is sent for reprocessing, or one of the TotalCaptureResults of a set of captures, when data