FakeImage
class FakeImage : MutableImageWrapper
Fake implementation of MutableImageWrapper for testing.
This class supports optional injection of both a ByteBuffer and a HardwareBuffer.
HardwareBuffer & Backing Behavior
If a hardwareBuffer is provided, its width, height, and format metadata will be verified and accessible. However, accessing pixel data directly from within the HardwareBuffer is not supported on pure JVM. Accessing the buffer fields from imagePlanes will use data backed by the byteBuffer parameter and/or byteBuffer field on this image.
If provided, the HardwareBuffer will be closed when this FakeImage is closed.
Summary
Public constructors |
|---|
FakeImage( |
Public functions |
|
|---|---|
open Unit |
close() |
open String |
toString() |
open T? |
Attempt to unwrap this object into an underlying type. |
Public properties |
|
|---|---|
Int |
|
open Rect |
|
open Int |
|
open Int |
|
open HardwareBuffer? |
Returns a handle to the underlying image's hardware buffer, or |
open Int |
|
open List<ImagePlane> |
|
Boolean |
|
open SyncFence? |
|
open Long |
|
open Int |
Public constructors
FakeImage
FakeImage(
width: Int,
height: Int,
format: Int,
timestamp: Long,
byteBuffer: ByteBuffer? = null,
hardwareBuffer: HardwareBuffer? = null,
cropRect: Rect = Rect(0, 0, width, height)
)
Public functions
unwrapAs
open fun <T : Any> unwrapAs(type: Class<T>): T?
Attempt to unwrap this object into an underlying type.
This operation is not safe and should be used with caution as it makes no guarantees about the state of the underlying objects. In particular, implementations should assume that fakes, test wrappers will always return null. Finally this method should return null when unwrapping into the provided type is not supported.
| Returns | |
|---|---|
T? |
unwrapped object matching T or null |
Public properties
hardwareBuffer
open val hardwareBuffer: HardwareBuffer?
Returns a handle to the underlying image's hardware buffer, or null if this image does not support hardware buffer.
The android.hardware.HardwareBuffer follows the lifecycle of its associated image. It is not required to be closed explicitly; however, the image needs to be closed after finishing processing the hardware buffer. In other words, if the hardware buffer is being used, the image cannot be closed.
| See also | |
|---|---|
getHardwareBuffer |