We call disconnectLocked before stopping CameraDevice's looper, in order to avoid this situation:
1) Its possible that an OnResultReceived callback is received, and posts an
AMessage with sp<ACameraCaptureSession> on CameraDevice's looper.
2) Before the looper message is processsed, ACameraDevice_close() is
called by the client, which results in the looper being stopped and
cleared with device lock held.
3) When the looper is getting cleared, the AMessage containg the
ACameraCaptureSession pointer is destructed leading to
~ACameraCaptureSession running without knowing that the device is
being closed, as a result it tries to hold device lock, resulting in
a deadlock.
Bug: 141603005
Test: CTS native tests
Test: use camera2 vndk client for extended periods of time
Change-Id: Ia0d47fc2975981055cd1f2103c1cbe8d76642fe4
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
The cameraservice is only registered to service manager after onFirstRef
is returned. To reduce the probability of getBinderService() call
returning null, move pingCameraServiceProxy to end of onFirstRef().
Also add debug messages in onFirstRef and main() for better diagnoses.
Test: Camera CTS
Bug: 140414594
Change-Id: I52defd1c138ade57ebc5181c42aff30921fbeaeb
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I6cc85a91afb603e31b85090917f9f3b59d82a4d1
It's possible that the following sequence happens:
1) hwbinder / binder thread T1: onResultReceived() starts -> promotes wp<CameraDevice> to sp<>;
2) Some other app thread T2 : ACameraDevice_close() -> delete ACameraDevice -> doesn't result in
CameraDevice's destructor running since mCameraDevice has another live
reference, app destroys some object O1.
3) T3 (callback looper thread): callback is received since looper is still running which accesses
dead app object O1 -> results in undefined behavior.
4) T1: onResultReceived completes and CameraDevice is destructed
We need to stop CameraDevice's looper thread (that waits for all callbacks queued to complete) in
~ACameraDevice() so we receive no callbacks after ACameraDevice is closed.
Bug: 135641415
Test: CTS native tests: no new failures
Test: AImageReaderVendorTest; enroll; while(1) auth;
Change-Id: Ia24de753f6ee409d941fff39616f09df2164880a
Merged-In: Ia24de753f6ee409d941fff39616f09df2164880a
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit 174084011c)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
It's possible that the following sequence happens:
1) hwbinder / binder thread T1: onResultReceived() starts -> promotes wp<CameraDevice> to sp<>;
2) Some other app thread T2 : ACameraDevice_close() -> delete ACameraDevice -> doesn't result in
CameraDevice's destructor running since mCameraDevice has another live
reference, app destroys some object O1.
3) T3 (callback looper thread): callback is received since looper is still running which accesses
dead app object O1 -> results in undefined behavior.
4) T1: onResultReceived completes and CameraDevice is destructed
We need to stop CameraDevice's looper thread (that waits for all callbacks queued to complete) in
~ACameraDevice() so we receive no callbacks after ACameraDevice is closed.
Bug: 135641415
Test: CTS native tests: no new failures
Test: AImageReaderVendorTest; enroll; while(1) auth;
Change-Id: Ia24de753f6ee409d941fff39616f09df2164880a
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
libhidltransport symbols are being moved into libhidlbase in order to
optimize linking/memory usage. libhidltransport will no longer be
required in the future (however removing references to it will come
separately).
Bug: 134961554
Test: boot
Change-Id: Ie8b9b03a53ae1f5672ce2565550768b4bcd321ee
In order for the build system to track updates to the header files
during incremental builds, always specify the src files using the same
path as the package for C++ compilations.
Bug: 112114177
Test: m
Change-Id: I5fb25124a26f190c462e2e60fc75a88d48643c10
Bug: 131925326
Test: AImageReaderVendorTest; test using vendor process using
libcamera2ndk_vendor
Change-Id: Ie86ec7f070e985121cdc89367bb0d4b227b41985
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
In some situations, clients of the vndk might need to be able to query
tags at runtime, based on tag names. For example, when client hals are
de-coupled from the camera HAL.
Bug: 131093919
Test: AImageReaderVendorTest
Test: Modify AImageReaderVendorTest to retrieve vendor tags given their
names, using ACameraMetadata_getTagFromName
Change-Id: I1cdec5b154037185e99d29be2c6890e4fdc4a32a
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Allow resolutions larger or equal to 24 megapixels to stream at 10fps to
meet BURST_CAPTURE requirement.
Test: Build
Bug: 129693371
Change-Id: I8f53b6a6f725e11d9deb1505d9d63d142e971006
Its possible that the device is closing, however, it hasn't stopped its
looper yet. In that case, if we receive a callback, we'll receive a null ACameraDevice. Cache the
camera id during CallbackHandler's construction instead, like the ndk does.
Bug: 130910407
Test: AImageReaderVendorTest
Change-Id: Ia7cd40ff1ce4fe52abb5528c68e3557523a5367d
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
- RAW capability can exist for multi-camera even if physical cameras are
of different sizes/capabilities.
- FOV for all processes streams must be the same regardless of logical
or physical streams.
- All metadata tags related to pixelArray/preCorrectionActiveArray/activeArray
needs to be mapped properly by the camera HAL.
- Do distortion correction mapping for physical subcamera as well.
Test: Build and read docs, camera CTS, ITS.
Bug: 118906351
Bug: 126220135
Change-Id: I29a61fc3a603561c1d74dc2261600ce4cd3d34cd
Bug: 129979644
Test: Fake SECURE_IMAGE_DATA by updating camera characteristics in
cameraserver; Retrieve capabilities in AImageReader test and
confirm that SECURE_IMAGE_DATA is supported
Test: AImageReaderVendorTest
Change-Id: Ia105969ce1df52408e6b7663a658d89f47cd90c2
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Test: check html output of: frameworks/native/doc/make website
(with a tweak in Doxyfile to add "__ANDROID__API__=24" to
PREDEFINED)
Bug: 120916880
Change-Id: Idf93a13b9bbe2974fa4256de1f3ca67b7eee1bb6
Jayant Chowdhary
Xin Li
Marco Nelissen
Shuzhen Wang
TreeHugger Robot
Steven Moreland
Andrew Chant
Dan Willemsen
Zhijun He
Eino-Ville Talvala
Yin-Chia Yeh