Check and return buffers to just deleted streams.
Also disallow deleteStream when camera runs into error to
simplify the stream lifecycle when error happens.
Test: CTS, manual tests
Bug: 63863140
Change-Id: I476737442041aebd393ec05998969d959cda0228
The producer end can disconnect at any time which
will trigger the freeing of the input buffer. If
any input buffers are outstanding and being processed
by the camera device freeing them can cause stability
issues.
Bug: 63682712
Test: Manual using application.
Change-Id: I25da97786d75e82b1b13dce34953de597bea9b2e
The size of ae regions may be zero by rounding error.
But it should be at least 1 if metering area size is not zero.
This problem causes CTS fail for
android.hardware.cts.CameraTest#testMeteringAreas on
the device which has the active array width less than 3556
if the preview size is 1920x1080.
Bug: 63795820
Test: ran Camera CTS
Change-Id: Ie3995e40aedba193393df8fd05d95f740a25ef3d
- Calculate expected duration based on request settings instead
of using a fixed timeout for shutdown
- Ensure the timeouts are always at least 5 seconds anyway
Test: Camera CTS passes with a long-exposure device
Bug: 38212789
Change-Id: I6b154710314cdc84b223f1a9f39fead9262ce27b
Fix below use after free issues:
==4947==ERROR: AddressSanitizer: heap-use-after-free on address
0xec61f434 at pc 0xf1954c18 bp 0xed3ff6f0 sp 0xed3ff6e8
READ of size 4 at 0xec61f434 thread T12 (C3Dev-1-ReqQueu)
#0 0xf1954c17 in _ZN7android7camera313Camera3Stream23removeOutstandingBufferERK21camera3_stream_buffer
frameworks/av/services/camera/libcameraservice/device3/Camera3Stream.cpp:508
#1 0xf1954c17 in _ZN7android7camera313Camera3Stream12returnBufferERK21camera3_stream_bufferx
frameworks/av/services/camera/libcameraservice/device3/Camera3Stream.cpp:543
#2 0xf193c663 in _ZN7android13Camera3Device13RequestThread21cleanUpFailedRequestsEb
frameworks/av/services/camera/libcameraservice/device3/Camera3Device.cpp:4131
#3 0xf193db5b in _ZN7android13Camera3Device13RequestThread10threadLoopEv
frameworks/av/services/camera/libcameraservice/device3/Camera3Device.cpp:3854
#4 0xf1562f35 in _ZN7android6Thread11_threadLoopEPv system/core/libutils/Threads.cpp:747
#5 0xf0ee6947 in _ZL15__pthread_startPv bionic/libc/bionic/pthread_create.cpp:214
#6 0xf0eba381 in __start_thread bionic/libc/bionic/clone.cpp:47
0xec61f434 is located 68 bytes inside of 136-byte region [0xec61f3f0,0xec61f478)
freed by thread T0 here:
#7 0xf1a64963 in _ZdlPvSt11align_val_tRKSt9nothrow_t [asan_rtl]
#8 0xf155df09 in _ZNK7android7RefBase9decStrongEPKv system/core/libutils/RefBase.cpp:435
#9 0xf19693ab in _ZN7android7camera319Camera3OutputStream22BufferReleasedListener16onBufferReleasedEv
frameworks/av/services/camera/libcameraservice/device3/Camera3OutputStream.cpp:720
#3 0x1ff56dfb (<unknown module>)
Bug: 62218367
Change-Id: Ib03415f73a1e3c283520af752904b1bcc40bff28
Make sure the callback object won't be freed in the middle
of callback execution.
Test: CTS + stress test
Bug: 63683767
Change-Id: I6fb1b754cadb3d499c1c246687d2f60d444d00bb
- Remove hand-written ICameraServiceProxy C++ impl; use the AIDL-
generated version instead
- Send client package name and camera facing with the camera state
notices
Test: Verify by logging that information sent to proxy is correct;
no camera CTS regressions.
Bug: 32449509
Change-Id: I7a305b76b4f1d5c08b7938108bd73c95986508e0
When abortCaptures is called, the request queue is cleared; as part of that,
any requests with input buffers trigger the removal and return of one input
buffer from the input stream.
However, if the HAL currently is processing some number of reprocess
requests, the stream's max buffer limit may have been reached, in
which case getInputBuffer will block until the HAL returns an input
buffer. This stalls flushing (and calling of capture_request) for
some time, and seems to cause problems for the HAL during the flush.
So instead, don't respect the HAL's max buffer limit when all we're
doing is throwing work away.
Test: CTS, manual testing
Bug: 62420820
Change-Id: I72d8cdaf67fb3cc6876a03cee9e0021d95cecdfe
Request thread may race with disconnect call when device is
disconnected in error condition. Acquire mLock when camera
device is updating status tracker to prevent that race
(status tracker being freed and then updated).
In other places where status tracker is updated, there is
a promoted sp to guarantee status tracker remain alive during
the call.
Test: CTS, manual camera testing
Bug: 62420820
Change-Id: Id894b5d3482c64125c114f79dbe746c56048fcbe
When camera HAL dies and cameraserver is still alive, make sure
we update camera status after HAL re-register itself.
Test: kill hal process and run camera app, CTS
Bug: 63058983
Change-Id: Iba7e6cbebb674994c905f7feb1776acc479b612f
Output buffer error notifications during result processing shouldn't
impact the metadata result. As per API contract the result is still
valid and we should wait for it to arrive.
Bug: 62485653
Test: Manual using application,
Complete Camera/Camera2 CTS.
Change-Id: I58de1b7c48d10e25a71a1ffb709e66e619a6bdcf
Yin-Chia Yeh
TreeHugger Robot
Nobuo, Ishii X
Emilian Peev
Eino-Ville Talvala
Shuzhen Wang
Chih-hung Hsieh