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>
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>
Bug: 131925326
Test: AImageReaderVendorTest; test using vendor process using
libcamera2ndk_vendor
Change-Id: Ie86ec7f070e985121cdc89367bb0d4b227b41985
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
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>
The physical camera device ID must be present as part
of the capture result extras in case of corresponding
result failure notification.
Bug: 128835627
Test: Camera CTS,
AImageReaderVendorTest
--gtest_filter=AImageReaderVendorTest.LogicalCameraPhysicalStream
Change-Id: I042af8bd85eaadd389b059c2833f352ceb2f40fc
Port physical camera settings support to ndk/vndk.
Test: Related camera VTS and NDK/VNDK tests pass
Bug: 115532726
Change-Id: Ie2d46b4ec041d2cec3c02145fbf06cf70eec5ac3
The support inclues:
- Physical camera specific stream support,
- Physical camera result metadata, and
Test: Newly added NDK CTS test pass
Test: Newly added VNDK test pass
Bug: 120566141
Bug: 115532726
Change-Id: I939b81522ca6c518c0e54ded5d3615f9973a6a65
In case the app doesn't provide sessionParameters, the VNDK should still
allow endConfigure() to be called to the camera service.
Test: Run test app and observe camera streams properly
Bug: 120505813
Change-Id: Ifa72dca61b8e25cd433d2c02c70b1c8e5e097228
Jayant Chowdhary
TreeHugger Robot
Emilian Peev
Shuzhen Wang