Camera clients must be aware of any configured streams
that can support offline processing mode.
A few corner cases that need to be considered:
- Composite streams can support offline mode only
when all internal streams support it as well.
- Streams that use the internal camera buffer manager
will not have support for offline mode.
- Shared streams are also unsupported in offline mode.
Bug: 135142453
Test: Camera CTS
Change-Id: Idde826a6fb18a8907850e87cfe593de7cb1c5f4a
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>
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
The error code passed to the camera2 ndk while calling the
ACameraDevice_ErrorStateCallback was the AIDL errorCode passed through
the ICameraDeviceCallbacks::onDeviceError() callback. These error codes
do not map directly, to the ones promised through the ndk in
NdkCameraDevice.h. These need to be fixed to appropriate ndk error code mappings.
Bug: 117833501
Test: GCA (sanity)
Test: CTS Native camera2 tests (sanity)
Change-Id: I65a80e4f2be5a3317a008bf0a71578e31fb45d62
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
To fix the warning in RefBase destructor.
Test: NDK CTS tests, and ARCore measure app.
Bug: 112775599
Change-Id: Ia448ac6d7e6c17699c16d287f65fc2826c9d7578
- Add physical camera metadata in capture result.
- Adjust capture_result book-keeping for physical capture result.
- Adapt to new version of ICameraDeviceCallback.
- Batch physical metadata with logical metadata within one
process_capture_result call.
Test: testLogicalCameraTest CTS test
Bug: 64691172
Change-Id: I63fd343770cbb6183b7c6e4566c698f69801a8e8
Capture requests could include settings for different physical
cameras. Camera service should always check whether such
extended requests refer to valid physical devices and process
them accordingly.
Fix some stability issues in the camera native tests.
Test: Basic camera sanity using camera application,
camera_client_test, Camera CTS
Bug: 64691172
Change-Id: I68b81e983dd0b7caebfa03e4f0cf283f2a91dc7a
The initial values of the session-wide capture parameters
should be passed along the stream list during stream
configuration. This could yield performance gains depending
on the Hal implementation and support.
Bug: 64450664
Test: Camera CTS
Change-Id: I2b0ec8916f027e7f34f81dc414c3ca649807e925
The Camera API needs to support the dynamic attach/detach of extra
output surfaces to a given camera stream.
Bug: 63912484
Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
1. Fix AMessage contains last reference to session
issue
2. Fix disconnectLocked waits on dead session issue
Test: add some sleeps to make deadlock scenarios pops in CTS
and then run CTS 100 times.
Bug: 67965633
Change-Id: If0ab9e33de12969dcb5f1d10e96f47f13024f399
onCaptureQueueEmpty is called when the non-repeating request queue in
cameraservice becomes empty. Application can use this callback as a
trigger for a new request.
Test: testMultipleCapture in PerformanceTest.java
Bug: 29006447
Change-Id: Id21afd74381e0b70f924c6026025c91a8ffd5ee0
Stop repeating request if any of its output stream is abandoned.
Add a callback to notify the repeating request has been stopped
with frame number of the last frame.
Update NDK with the new callback and behavior.
Bug: 21270879
Change-Id: I3553775c7807a77104aa1650609480ca3321310c
- Codegen update: some of hidden metadata keys should not be
disclosed in NDK.
- Also added capture result frame number plumbing.
Bug: 27102995
Change-Id: Ia238f95a4da726330205c53fc5d3f1f63d7553a1
- Also fix error logging template inconsistency
- Also add a few error handling cases into camera2 NDK
to deal with previously-ignored error codes
Bug: 27149500
Change-Id: I8f1f4c72252dd48d652f24b595b642199f20c327
Emilian Peev
Jayant Chowdhary
TreeHugger Robot
Shuzhen Wang
Chih-Hung Hsieh
Yin-Chia Yeh
Chien-Yu Chen
Eino-Ville Talvala