HAL ZSL request may be out-of-order compared to normal/reprocess
requests. Allow such case to improve shot lantecy.
Test: Camera CTS, 3P camera app sanity test.
Bug: 120604717
Change-Id: Id994efbe392094cdae694afaa2d159bc9c49d5f0
Also fix a issue for finishConfiguration is unintentionally
delayed till first capture request.
Test: Camera CTS + partner device testing
Bug: 126390310
Change-Id: Ibca740a7160cbf41e01884dbcef8ba51eb4c75f7
- 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
These things are ceaseless: /
code reviews, design docs - /
off-by-one errors making a mess
Test: atest CtsCameraTestCases
Bug: 129561652
Change-Id: I807d7ad4740ffe267053fe5da2080f9ecb45aa72
1. Change Camera3Device logs to ALOGV
2. In Camera3OutputStream, only log before we mark stream state
to STATE_ABANDONED
3. Also changed BUFFER_ERROR log to ALOGV
Test: manually check log of GCA mode switch
Bug: 125415787
Change-Id: Ibd83b7010932a8be25d85573d9c9dce9c394f6bb
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
Bug: 120407707
Test: CTS
Test: Use camera to take pictures / record videos (sanity)
Change-Id: I7b29c337d0e217d2eb6a62e2c75ccc550d795e61
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Fix the long (>1s) dequeueBuffer call when a stream is managed by
Camera3BufferManager and its consumer end discards free buffers.
Test: CTS, no more long dequeBuffer call in GCA mode switch
Bug: 126054873
Change-Id: I03d6526b076796bb44f15cc2c4a092ff3d04fc1d
Return buffers managed by HAL buffer manager in disconnect.
Test: kill HAL process and check for buffer leak in cameraserver
Bug: 126889012
Change-Id: I83173c5eaae13ee11eb3f185e7204a2dd8855b4e
Set bufferSize in @3.4::Stream::bufferSize for JPEG_APP_SEGMENTS stream.
Bug: 124999074
Test: Build
Change-Id: I6f24f4273b0d3d18b1bdbf263fc12ed48e857004
In case the Camera3Device enters a bad state, the
RequestThread can continue to run after disconnect()
completes. This can potentially cause instabilities
because some of the Camera3Device member variables
will become invalid after disconnect() but are still
accessible in code paths triggered by RequestThread.
Avoid using potentially invalid reference by checking
the respective strong pointer.
Bug: 123293729
Test: Manual using application,
Camera CTS
Change-Id: If3305840db89537593370b7f57bccbb257e49cbd
1. Fix off by one error in signalStreamFlush call
2. Make sure signalStreamFlush is called before we toggle request
thread idle (which might cause another thread finishing
waitUntilIdle() and thus start calling configureStreams)
Test: Pixel 3 + camera CTS
Bug: 120986771
Change-Id: Ifd6f77ef628ee200c024c7c6a05bde20937c745d
onBufferReleased is no longer reliable indicator of capture
error due to HAL buffer manager feature. Switch to listen
to error callback from HAL directly.
Test: API1 CTS + Pixel 3
Bug: 123952355
Change-Id: I7362942f19356583ec66f259b01e963a1af3a205
Session parameter changes will by default trigger internal stream
reconfiguration. If possible query Hal whether this sequence
is required for specific parameter values.
Bug: 122609098
Test: Manual using application
Change-Id: I9eaa55b0a552d9753122c16f9470779e2ed8ffec
- Derive HEIC capabilities from camera HAL and media framework.
- Add HeicCompositeStream to encode camera buffers to HEIC buffers.
- Add ExifUtils to overwrite JPEG APP segments and send to media codec.
- Add NDK enums and corresponding format support.
Test: Camera CTS
Bug: 79465976
Change-Id: I0a885e76335f3eba4be0fd42241edb0b7349f284
Add the necessary logic to support dynamic depth metadata.
Bug: 109735087
Test: Manual using application,
Camera CTS
Change-Id: Ic4710872dc596bc718270e1c79d4da53fb850875
Cached 3.5 HIDL session needs to be released
in order to destroy the session implementation
on provider side.
Test: Camera CTS
Bug: 119939541
Change-Id: I8b4c403b7bb9f3ac481e240701b5aaad505fdf2e
The old implementation only toggle idle when waitUnitlDrained
is explicitly called, but there are some cases where
application don't need to call waitUntilDrained but can still
expect the device goes into idle.
Test: CTS on Pixel3 equipped with webcam HAL
Bug: 109829698
Change-Id: I48c26abcc9c2f1263c2360611c935fc317745e59
Support runtime "SessionConfiguration" queries by camera
clients.
Bug: 111593096
Test: adb shell /data/nativetest64/camera_client_test/camera_client_test
--gtest_filter=CameraClientBinderTest.CheckBinderCameraDeviceUser,
Camera CTS
Change-Id: I1505e7bccdce468490b46ad4546e459354a4cda3
- Add dummy CFA pattern for monochrome camera.
- Handle monochrome camera in DngCreator.
- Fix up static and dynamic metadata tags related to monochrome camera
for older version of devices.
Test: Camera CTS
Test: Capture a DNG file and inspect with LightRoom
Bug: 70216652
Change-Id: I68d2b3d77b7f81bdc9e4129c2a8af10a4f18db3b
SignalPipelineDrain will be sent after the request
thread has stopped sending capture requests so
HAL can expect no more capture requests are sent
after they receive this call.
Test: CTS
Bug: 109829698
Change-Id: I6f75c28ff0998a8edc80f9af9ebe727c585ea6e9
mOutputStreams access used to be protected by mLock, but that has
changed due to:
- Treble interface switched from passing stream pointer to
stream index
- The buffer management API runs in HAL callback thread
Test: CTS
Bug: 109829698
Change-Id: I3561b197f46f07d2a15bb4f52b096f36c73a0407
For some resolutions input HeifWriter surfaces have much higher
acquired buffer count compared to the maximum Hal buffer for the
respective use case. From the tests so far shared streaming doesn't
seem to be affected by the imbalance and the splitter is able to
support this case.
Bug: 110161669
Test: Camera CTS
Change-Id: I129221b0f35e45c8b26f27f94910a6edda8d675b
The maximum acquired count of the input buffer queue during surface
sharing should be set considering the total maximum acquired count of
individual registered outputs and also the current acquired count
of the input buffer queue. The reason the two can be different is
due to the fact that individual outputs can acquire and also block
buffers from the input. The latter portion contains all buffers
which are still queued but not acquired. This can happen in case
some output acquires the maximum amount of buffers possible then
stops consuming entirely and the camera client continues to reference
it in subsequent capture requests.
To handle this, track the number of acquired buffers in the input
queue and expand (or contract) the maximum acquired count only if
possible. The maximum shouldn't change otherwise because the blocked
buffers could still be used by the unresponsive output at some
later point in time.
Bug: 117982710
Test: Camera CTS
Change-Id: Ia4e743efdf59cb0c9baaea492f78c37d0f2c95b3
Add a wrapper around calls to IPCThreadState to
account for the fact that remote HIDL calls may use binder function
implementations internally.Therefore, we need to know whether we are on
a binder / hwbinder thread and call the appropriate IPCThreadState /
hardware::IPCThreadState function internally.
Bug: 110364143
Test: GCA
Test: Third party app
Test: camera CTS (no new failures).
Change-Id: Ibad03fafd2ccc53a5352a6df45cf8f641bc7a3bf
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
'disconnectImpl' holds 'mTrackerLock' for its entire scope.
This is not needed and could lead to deadlocks in case the
request thread encounters errors and tries to clean up
any failed requests. In this scenario the request thread will
already hold 'mInflightLock' and then try to acquire
'mTrackerLock' as well. The 'disconnectImpl' context will
acquire 'mTrackerLock' first and at some later point try to
get 'mInflightLock' which will end up in a deadlock.
To avoid this, limit the scope of 'mTrackerLock' within
'disconnectImpl'. The lock purpose is to protect other threads
from accessing invalid 'mStatusTracker' instances and must not
introduce side effects.
Bug: 115784704
Test: Camera CTS, Manual test
Change-Id: I96b039cb454e0c185ecdf0c8072a9494233c1169
Depending on timing a race is possible between two
binder threads that will eventually try to disconnect
the camera device. The first is a regular disconnect call
and the second a binderDied notification in case the
connection terminates before disconnect is able to complete.
Avoid possible instabilities and skip flushing in case the
device is no longer initialized.
Bug: 116514106
Test: Camera CTS
Change-Id: I1a958b2f80d872de89275555e83ac32576cc6792
If HAL overrides stream format, use the overridden format to configure
the buffer queues.
Bug: 113326269
Test: Camera CTS, partner testing
Merged-In: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
Change-Id: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
Refactor code to cache logical camera related info, such that we don't
need to query the camera characteristics multiple times.
Test: Camera CTS
Bug: 79523700
Change-Id: I01733fc9165ec88aadc655491a025627fd622857
In case application sends 2 consecutive setRepeatingBurst, the first
request may be preparing the video stream, whiel the second request
fails the isPreparing check.
Fix this by distinguishing between internal and external prepare. For
internal prepare, allow new requests to come through to the request
thread.
Bug: 114422231
Bug: 109830370
Test: Camera CTS
Change-Id: I55a7271e3924f2cb8cf9c452e934b070a82bc4ca
In extreme cases, HAL needs to wait until all inflight requests
are fulfilled before it can return a buffer, so extend the
getBuffer wait accordingly.
Test: partner testing, smoke test Pixel
Bug: 113660745
Change-Id: I363098004e70b75e11651fe0f1c75efcfda970f4
Decreasing timestamp shouldn't happen in non ZSL or reprocessing case.
When that happens, treat the buffer as error and return to buffer queue
directly.
Test: Camera CTS
Bug: 113670946
Change-Id: I39d3417dd9307d6cc7c90ff357a82604566a9081
Certain devices generate duplicate timestamps for cases like video
recording. So do not treat non-increasing timestamps as fatal for now.
Test: Failed camera CTS on Pixel device
Bug: 113670946
Change-Id: I3708f46111edf031f48f460e4efce9f9c46f174e
Guard against case where timestamp of stream buffers doesn't increase.
Timestamp source is either monotonic or boottime, both of which are
guaranteed to increase.
There are 2 exceptions where timestamp may go back in time:
- For requests where HAL ZSL is enabled, and
- For reprocessing requests
Test: Camera CTS
Bug: 113340974
Change-Id: I0ae9290696d651168150fa5ed7aa13c140a0294f
- Ensure the conversions between pre-correction and active array coordinates
are applied consistenly
- Only some regions were being clamped to ensure they were within the
destination region. Add more clamping, though some outputs still
need to not be clamped, such as face rectangles which may extend outside
the FOV.
- Add simple transform mode since the full transform cannot safely be used
to meet all consistency requirements in Android P
Also update the unit tests to try to check for this corner case and the
simple mode.
Test: adb shell /data/nativetest/cameraservice_tests/cameraservice_test \
--gtest_filter=*Distortion*
Bug: 109766306
Change-Id: Id6f23794d60d5ed9e04b155426741a504487e3d6
Merged-In: Id6f23794d60d5ed9e04b155426741a504487e3d6
(cherry-picked from ee080fed19)
(cherry picked from commit dccebf80ea7e90eedeb914becafc47ca725eb27f)
If HAL overrides stream format, use the overridden format to configure
the buffer queues.
Bug: 113326269
Test: Camera CTS
Change-Id: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
When consumer surface is destroyed, dequeueBuffer may return
DEAD_OBJECT.
We need to treat this condition as ABANDONED so that camera service
stops repeating request. Otherwise, we may run into infinite loop.
Test: Camera CTS
Bug: 111384143
Bug: 111381452
Change-Id: If3348119521e9805085321c7f20abd7cc7f5dd43
Updating of the mDevice sp<> is racy.
This change will cause the Camera3Device object lives until
the client is destructed (which can be a few seconds after
camera app closed and GC kicking in to delete the client)
The benefit is the dumpDevice can remain lock free.
Also fix a problem where we call virtual function disconnect in
Camera3Device destructor.
Test: the double free problem cannot reproduce
Bug: 112639939
Change-Id: I77762db8f59cf33891631d13fc3bdb3830ae08fb
If stream being created is a physical stream, the size check should be
against the physical stream's capability.
Test: Camera CTS
Bug: 111288509
Change-Id: Iad8814562694f16f16d9656ec482b8b21a859c44
Merged-In: Iad8814562694f16f16d9656ec482b8b21a859c44
The (right, bottom) coordinates of any input rectangles are
exclusive.
Bug: 111885753
Test: Camera CTS,
adb shell /data/nativetest64/cameraservice_test/cameraservice_test
--gtest_filter=DistortionMapperTest.*
Change-Id: Ied956bd154256a10fc4c81d27c93b0ba2e33044d
It's possible that surface for a stream goes away after
cameraservice configures HAL stream, either during configure_streams
or when session parameters are updated.
In this case, do not put camera device in an error state.
Test: Camera CTS, GCA
Bug: 111581884
Change-Id: I7efc5aa22bc9b60ffaea23d8dae275f9a2bd026d
Test: mm -j64
Test: runtest -x src/ in cts/tests/camera; no new tests fail
Change-Id: Id7a8516eb92ce7112f0200cfeaba92278541bfa7
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
HFR should send valid setting for the first request inside a batch.
Bug: 111528642
Test: Slowmo on Pixel 3
Change-Id: Id92a9e23d12b7f9dde3acfc70b656ae39bdaee5b
When consumer surface is destroyed, dequeueBuffer may return
DEAD_OBJECT.
We need to treat this condition as ABANDONED so that camera service
stops repeating request. Otherwise, we may run into infinite loop.
Test: Camera CTS
Bug: 111384143
Bug: 111381452
Change-Id: If3348119521e9805085321c7f20abd7cc7f5dd43
Shuzhen Wang
Yin-Chia Yeh
TreeHugger Robot
Eino-Ville Talvala
Emilian Peev
Jayant Chowdhary
Chih-Hung Hsieh
Xin Li
Zhijun He