There is no guarantee that the static metadata
pointer passed in the "DeviceCb" contructor will
be valid after the call completes. The device
callback instance is expected to be active until
the camera session is open. Clone the required
metadata in "DeviceCb" and manage the lifetime
appropriately by using the "CameraMetadata"
wrapper.
Bug: 135976837
Test: CameraHidlTest#processCaptureRequestPreview
Change-Id: Idd3c6c8c2e5a3fc44a49712e25a04009cbd471b1
Multi-camera API requirement is relaxed to allow camera device not
support physical stream combinations. Adjust the test accordingly.
Test: processMultiCaptureRequestPreview
Bug: 135688720
Bug: 135728906
Change-Id: I8c5269c5d3fd7f6eef440c818706629af2233196
It's legit to have bufId 0 in processCaptureResult with HAL buffer
manager, but not for returnStreamBuffers.
Test: the failed test can now pass
Bug: 135565913
Change-Id: I05947bc159bb9ba00a670b98d4622f685b4ac760
Use IMapper 3.0 if available. Otherwise, fall back to IMapper 2.0.
Test: Update camera VTS test passes
Bug: 128013727
Change-Id: I9bb54bbc290f1b90ef593dee9796b22b0dd49671
hidl-generated makefiles are now generated such that bpfmt(file) == file.
Bug: 67417008
Test: enable bpfmt hook
Change-Id: I53e5bf67a0d314e1b10c0ba0c7172a7af358ddcc
hidl-generated makefiles are now generated such that bpfmt(file) == file.
Bug: 67417008
Test: enable bpfmt hook
Change-Id: I1f69d292bc23a7cc293a66110cb02d597e1019ad
Torch API was mandated on legacy libhardware camera module 2.4.
We kept the option of not supporting this API because the first
HIDL legacy wrapper needs to also support libhardware camera
module 1.0 + HAL1.0. Now that HAL 1.0 is no longer supported,
we can reenforce the torch API being supported by camera HAL as
this is critical to power usage of flashlight usecase.
Test: adb shell VtsHalCameraProviderV2_4TargetTest
--hal_service_instance=android.hardware.camera.provider@2.4::ICameraProvider/legacy/0
Bug: 113336515
Change-Id: I0dcf2e7a5cddadcd097caf6913625d8a607065f8
Additionally fix a possible issue with the buffer request index
and variable shadowing.
Bug: 129090247
Test: adb shell
/data/nativetest64/VtsHalCameraProviderV2_4TargetTest/VtsHalCameraProviderV2_4TargetTest
--hal_service_instance=android.hardware.camera.provider@2.4::ICameraProvider/legacy/0
Change-Id: I34ab0285e59233c1b6d276f9167372ef3b0bbd0b
Test to make sure logical multi-camera device support
isStreamCombinationSupported() for 3.5 and above devices.
Test: VtsHalCameraProviderV2_4TargetTest
Bug: 119325664
Change-Id: I734278799f10ed215ceb5dd108ac7f722f7f7925
modified VTS tests functions to work with the Y16 format with the correct dataspace.
Y16 changes are in this patch: 847192
Test: ran and tested on intel depth camera D415 and a regular RGB camera
Change-Id: Ie40347d58d4f72ed2fc9676bdaab2d1dca5dc5bc
Signed-off-by: Emil Jahshan <emil.jahshan@intel.com>
Check with Hal whether stream reconfiguration is required
in case of session parameter updates.
Bug: 122609098
Test: Manual using application,
vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --module VtsHalCameraProviderV2_4Target -l INFO
Change-Id: Ic02525871aa079393b28b2da53764093f95f881d
Add 2.5 implementations, which do not support passthrough mode and
therefore doesn't need the HIDL_Fetch methods or a specially-named
-impl library in the /hw directory. Instead, the service directly
instantiates the necessary service.
Also add VTS tests for the new notification
Test: Verify device state changes are logged by HAL
Test: Camera starts as usual with both 2.4 and 2.5 providers on
walleye. Camera CTS completes.
Test: New VTS tests pass
Bug: 121379978
Change-Id: I0fc99379eb7e01c5b2efb20afb5753bb6ce8b627
To allow for implementation inheritance of @2.4 legacy wrapper and
@2.4 external webcamera HALs in the @2.5 implementations, restructure
the existing default provider to separate the service interface into a
thin shim that calls the implementations.
Test: Camera starts as usual after refactor, VTS tests pass
Bug: 121379978
Change-Id: Id40790ed4fb495577fd2b885c706b2ed7a96d64e
Sometimes, the camera service needs to notify a camera HAL that the
overall device physical state has changed, so that the HAL can
properly remap how it handles logical multicamera devices or similar.
Test: Builds, new VTS tests pass
Bug: 121379978
Change-Id: I0982fdecaf53a0529289d63c08c5a31264ee7ec7
- Add new usage flag to indicate the consumer of the buffer is HEIC
encoder.
- Add new data space to indicate that the BLOB buffer is HEIC encoded.
- Add new BlobId to specify JPEG APPs segments.
Test: testHeic CTS test
Bug: 79465976
Change-Id: Iaa6a1d017223e84fc1c5dd0a9d90d9f09240e827
Add buffer management API support.
Test: VTS to be written. Need Pixel device impl to verify.
Bug: 120986771
Change-Id: Icdbc621f8cd17aa0868d3ac361867c44793a268c
Add necessary metadata tags for supporting dynamic depth
streams.
Includes minor gfx fix which should help eliminate build
errors after HIDL header autogen.
Bug: 109735087
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --module VtsHalCameraProviderV2_4Target -l INFO
Change-Id: Ia476b195095ae7a29bc740174331dfbfdaa6d320
* The sCameraDeviceStatusChange() callback might be fired between
initialize() and setCallback(), which can be easily triggered if there
is an external camera connected at the boot time.
* The external cameras need to be excluded in the getCameraIdList().
Bug: 77833131
Bug: 122800852
Test: Reboot with an external camera is connected, and see the
camera list is corrected probed in
$ android-sh -c 'dumpsys media.camera'
The testing device is Nautilus (Samsung Chromebook Plus).
Change-Id: I5cec6732ce4e26632f1bb5186331b7ce7a94a0b3
VTS gets the name of all the cameras in the machine and check each camera, When traversal to the configuration reference of 1600*1200 camera, the outputPreviewStreams variable does not clear, save the value of the Previous camera
The outputPreviewStreams variable needs to be cleared when check next camera
Bug: 122806546
Test: ConfigureStreamsWithSessionParameters can pass when one of the three cameras was configured with a maximum android.scaler.availableStreamConfiguration size of 1600*1200
Change-Id: Ia4845d43871730e14b5ba1411ce72f8c4bb69042
Merged-In: Ia4845d43871730e14b5ba1411ce72f8c4bb69042
VTS gets the name of all the cameras in the machine and check each camera, When traversal to the configuration reference of 1600*1200 camera, the outputPreviewStreams variable does not clear, save the value of the Previous camera
The outputPreviewStreams variable needs to be cleared when check next camera
Bug: 122806546
Test: ConfigureStreamsWithSessionParameters can pass when one of the three cameras was configured with a maximum android.scaler.availableStreamConfiguration size of 1600*1200
Change-Id: Ia4845d43871730e14b5ba1411ce72f8c4bb69042
Test: On walleye_svelte, reboot device and check that camera HAL is not
running until camera app is opened
Bug: 79374634
Change-Id: Ib9968c899ce8be5a68a28b4decf0a52f96b20ec5
Camera devices 3.5 and later can optionally support
stream combination queries. These use the regular
'StreamConfiguration' structure however in contrast
to normal stream configuration, the query will be
much faster and will not cause any HW/SW side effects.
Additionally it will be possible to run stream
combination queries at any time after the camera
device is open.
Implement stream combination query for the external
camera provider.
Bug: 111593096
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --module VtsHalCameraProviderV2_4Target -l INFO
Change-Id: I59ec936d17dabc89ba49407a750df1cd2e61b145
