"mHal3Device" is no longer used, the associated code is currently
dead.
Legacy code inside "CameraHardwareInterface" is also
no longer used.
Bug: 35215313
Test: Camera CTS
Change-Id: I6ee33fc289e3b42af543d9027c7d76efc8d73b0b
Try to cover all methods that acquire locks, so that it's easier to
tell what function might be holding one and slowing down others
Test: Manual use of camera app
Bug: 63950311
Change-Id: Ib81b348bd274598a422c0138d9ebbad65aeff922
* Use const reference type for loop index variables to avoid unnecessary copy.
Bug: 30413223
Test: build with WITH_TIDY=1
Change-Id: I79969be18569c5bb1ea29ee18ae89a3f9d55ce9c
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
- 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
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
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
This change attempts to free buffers managerd by
BufferManager more aggresively to reduce memory pressure.
Also fix a small buffer accounting issue: check detachBuffer
actually returns a non-null buffer.
Test: keep taking single shot in GCA, CTS
Bug: 38483630
Change-Id: I6c64d1dc2244cec4f1300bbf3992f66f2167eed2
- BufferQueue consumer may detach buffers, and BufferManager isn't
aware. Hook up onBufferRemoved callback so that BufferManager's internal
handoutBuffer and attachedBuffer counts can be updated when a buffer
is detached.
- Deleted some code that's not exercised any more.
Test: Camera CTS and burst capture.
Bug: 38238747
Change-Id: I6861da6e013fe5609907f807639c5d691c0c3af9
Buffers that didn't get a chance to be processed
might still hold valid acquire fences. Check and
close those if necessary.
Bug: 38229510
Test: Manual using application
Change-Id: I8e823a655cc30ed966e277ace090e96c64ba1c8c
Check for transaction errors in all calls to the HIDL interface;
return DEAD_OBJECT consistently if a transaction error occurs.
Test: Camera CTS does not regress; killing camera HAL does not kill camera service.
Bug: 37748853
Change-Id: Iab3ad08376e164db340f8f29c3cfc7fdf261cc00
CameraModule is already part of the HIDL wrapper and
is no longer needed in the service code.
Add extra logic in camera provder manager for identifying
camera API1 compatible devices.
Bug: 34392075
Test: Complete Camera CTS
Change-Id: I64a49e9091557c88859872d0c599c5be378db8b5
RAW boost value will be inserted by HIDL wrapper. The logic
needs to move there.
Bug: 34392075
Test: runtest -x
cts/tests/camera/src/android/hardware/camera2/cts/DngCreatorTest.java
Change-Id: I7d4321d728eba11b5ec1345536bb669d70f3cffc
Camera device related code should be agnostic w.r.t.
device version as much as possible. Specifically the
following requirements must hold true:
- Since support for devices 3.0&3.1 is deprecated
"ANDROID_QUIRKS_USE_PARTIAL_RESULT" is no longer considered.
- "ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS" is always
used instead of the deprecated "ANDROID_SCALER_AVAILABLE_JPEG_SIZES".
- Buffer manager for camera streams is used for dynamic buffer
allocation.
- "flush" is always used instead of waiting for buffers to drain.
- Similar to "flush" stream "tearDown" is always available.
- Dead code handling buffer registration is removed.
Bug: 34392075
Test: Manual using camera application
Change-Id: If1b215f785ba61c6991fdf163d4eb18733690471
Bufer handle hashing and comparison currently uses the buffer
'Int' section along with the Fd section. However the values there
can dynamically change after the buffer gets allocated which will
introduce side-effects in the buffer id map.
Bug: 37257356
Test: Complete Camera/Camera2 CTS
Change-Id: I2cf09ced69f155285dae67b3a2502e6b87f7d9cc
Allow shifted metadata when the buffer is allocated by
hwbinder (which might allocate buffers to 4 bytes boundary
on 32-bits CPU)
Test: compile, GCA working
Bug: 37095012
Change-Id: I404b73ac3b460f5ff03cb64001c24f7a05b91396
Different vendors could have different vendor tags.
A global vendor tag cache will store all available
vendor tag descriptors from different providers.
The cache will then be shared with each camera client.
Camera metadata will use specific vendor ids stored
in the metadata buffer to identify the correct vendor
tag provider.
Bug: 34275821
Test: adb shell /data/nativetest/cameraservice_test/cameraservice_test
--gtest_filter=CameraProviderManagerTest.MultipleVendorTagTest
Complete Camera/Camera2 CTS tests
Change-Id: I2262128f21a0167504f018230624e2a89786c467
To cleanup caches of obsolete buffers.
This CL addressed the input stream bit, the output
stream hook will be a followup CL.
Also cleanup some dead API in CameraDeviceBase.h
Test: fix CTS ReprocessCaptureTest
Bug: 34461678
Change-Id: I801cd81c29becaa45630ed0a5c2dab8df1278a6a
Make it possible for clients to clear the internal inflight queue
as part of error result notifications. For this to work all pending
buffers must be returned previously with the exception of the
result metadata.
Bug: 35652756
Test: Complete Camera/Camera2 CTS without any regressions.
Change-Id: I9d8a6b63364fd254311cda2f8c836b99ee05cacb
Otherwise some bits aren't where they're supposed to be.
Also stop using HW_CAMERA_ZSL; we need to only set HW_CAMERA_READ, and it's
confusing to set a producer flag on the consumer usage side.
Test: Camera CTS passes
Bug: 35215313
Change-Id: I23e6e60bf875fe9d8f2d7a1f805d2ef854c16b97
Method 'indexOfKey' will return 'NAME_NOT_FOUND' error
status in case it doesn't find any values matching the
given key. Checking for anything other than this error
code could lead to instabilities.
Bug: 35925482
Test: Manual using application
Change-Id: Ie72eb29776b27a6d485f6e42ee7e62c62795ca9e
(cherry picked from commit 4219c290e5)
With Camera HAL sending empty metadata for HFR batching, service
shouldn't check matching timestamp for empty metadata.
Test: Manually test high speed recording
Bug: 35775704
Change-Id: I68f3c16ea9a91f15c70e406540764b02cb6951e1
For High Speed Recording, only send the shutter and result for the last
request in the batch, and count on the application process to derive
other results in the batch.
This reduces the binder transaction between the two processes, and saves
power.
Test: Manually test high speed recording with GCA, and CTS
Bug: 35775704
Change-Id: I3e1b4c1db3d1d1044400d825e2affa4461362b39
When Camera2Client uses Camera3Device, it operates with lazy stream
configuration (in which streams are configured only once a capture
request is going to actually be sent). In this path, the operating
mode may never get set to a valid mode, and thus always fail
stream configuration.
Ensure that all paths calling into configureStreamsLocked set the
appropriate operating mode.
Test: Actually no camera CTS regressions this time, honest!
Bug: 34853980
Change-Id: I6e1855206f6d76cca5ff8348555b26bd7b868843
Instead of a true/false switch for high-speed mode, use an integer
enum instead and define the two existing modes, plus the start
of a vendor mode space.
For all non-high-speed modes, use the normal configuration path,
but pass the operating mode to the HAL.
Test: New CTS test passes
Bug: 34853980
Change-Id: I9dc2b2a2164e9779f079a30e936c4117bcf96efe
- Merge notifyRequestedSurfaces into getBufferLocked, so that during
getBufferLocked, the stream splitter gets to know which outputs the
current request is on.
- Reserve buffer slot in the output queue during getBufferLocked instead
of during onFrameAvailable. So if there is no slot/buffer available, no
new request is sent to HAL. This aligns with current cameraservice logic.
Do not hold the lock while calling attachBuffer to output queue because
it could block for a slow consumer.
- Instead of setting the consumer buffer count of input buffer queue to
maximum of all shared outputs, set it to sum of them. By doing this,
In the case of a slow consumer, other consumers sharing the same stream
won't be impacted.
- Handle the case where onBufferReleased not being fired for buffer
replaced by attachBuffer/queueBuffer.
- Add function to check the return value of onFrameAvailable so that
when output is abandoned, the error code is propagated back to
queueBuffer.
Test: Camera CTS, and CTS with StreamSplitter enabled for all
implementation defined use cases.
Bug: 33777818
Change-Id: I863f501d5283bbe70c71e66b4d37d690484b90fa
HALs are prohibited from using framework binder, and there is
no equivalent scheduling policy service in hwbinder. Thus, in order
to match priorities of FastCapture / Mixer threads with their
counterparts in the HAL, it is needed to request the priority boost
from audioflinger on behalf of the HAL.
Test done to verify the priority was correctly set.
Bug: 34131400
Change-Id: If8b6b031c0fcba771fae901a5b8e7da89b3a1570
Test: check priority match between audioflinger's and hal's threads
Currently this path relies entirely on the deprecated bi-directional
streams. This needs to be re-worked and the functionality should
only use input&ouput streams. In this case the dedicated
'Camera3ZslStream' module becomes mostly obsolete. Some of the logic
for buffer comparison will still be needed and can be moved to ZSL
processor entirely.
The processor module will now use two streams, one input stream and
one ZSL output stream, which will produce the queue data. Both of
them will be configured to use the supported sensor array size and
private format. Scaling from the sensor resolution to the final user
requested size will happen during the re-process pass once image
capture gets triggered.
BUG: 34131351
Test: Manual via TestingCamera, 'CameraTest' API1 test cases
Change-Id: I7c87b7e7f89815e01a7cb5ce39d9c561c58562df
For output streams, increment frame count and update timestamp when a
filled buffer is queued to the output buffer queue.
For input streams, increment frame count and update timestamp when a
buffer is acquired from the input buffer queue.
Test: Manual inspection of adb shell dumpsys media.camera while
running DevCamera
Change-Id: I8dc1d134baf5ad467e169f3ba6ffe0d1486df9dc
Get camera service dump working again in the Treble path, and clean
up the formatting a bit
- Switch to dprintf instead of write() for most dump calls
- Add clearer headers for each section
- Add static metadata details to CameraProviderManager dump
Test: adb shell dumpsys media.camera with Treble both enabled and disabled
Bug: 32991422
Change-Id: Ie1d431b68649777bfe84fbb1be0687dd02e671af
For Async buffer queue, if a pending buffer is overwritten by an
incoming buffer, onBufferReleased callback isn't called. But the stream
splitter depends on the onBufferReleased to return buffer to input.
Fix the problem by checking the bufferReplaced flag in
QueueBufferOutput.
Test: Camera CTS
Bug: 33777818
Change-Id: I270c7bae7873797ae9b050782828b5a124d3eff9
- Refactor the OutputConfiguration to contain isDeferred and isShared
flag, and not contain NULL surface.
- Unify the handling of deferred surface and shared surface.
Test: Camera CTS, and manual testing of GoogleCamera use cases
Bug: 33777818
Change-Id: I5dd3472f0f2133699b0e9fbdd8ba456956222746
* changes:
Camera: wait for remote camera provider
Camera: setup vendor tag in binderized mode
Camera: treble: close acquire_fence
Camera: pass bufferId to HIDL interface
This is to make the behavior agnostic to passthrough/binderized
mode.
Test: running API2 CTS
Bug: 30985004
Change-Id: I48ce307f8566ff0a2a5b35763e1a37733e6ed9a0
This gives each buffer a unique ID and save some time sending
buffer_handle_t to HAL process.
Bug: 30985004
Change-Id: Idf0d3edde94e1331cadb271dce3e4bed8bfb8c14
- Enhance OutputConfiguration to contain multiple surfaces for one
underlying stream.
- Create Camera3SharedOutputStream to handle streams with multiple
surfaces.
- Create Camera3StreamSplitter to handle buffer flows between camera and
multiple consumers.
Test: cts, and manually test camera preview/snapshot/recording
Bug: 33777818
Change-Id: Ia010c3cc9d9b4bd5b9ea03cc42fe4e0a0d8033f1
- Use string for device ID in Camera3Device
- Remove camera3_device_t parameter from Camera3Stream::finishConfiguration
- Disables ability for the stream to register buffers
- This means device HALv3.0 and v3.1 are no longer supported
- Add HIDL support to Camera3Device:
- Add HalInterface class to abstract whether legacy or HIDL HAL is in use
- TODO
- CameraHardwareInterface
- Switch to using HIDL definitions instead of camera3.h definitions in
main body of code
Test: Compiles
Bug: 30985004
Bug: 32991422
Change-Id: I9c3c0f7b7ea5d1d74e14b1d882779e3b9445da69
- Add CameraProviderManager
- Enumerates individual camera provider HAL instances, as well
as the devices they provide
- Handles dynamic provider and device appearance/disappearance
- Maps device names to public API namespace
- Add unit tests for CameraProviderManager
- Add logic to enable new HIDL path
- Switch various bits of service internals to use string camera IDs,
though leaving most camera1-facing bits using int IDs, since that's
what the old API uses.
- Update CameraService to use CameraProviderManager instead of
the legacy camera HAL
- Update clients to pass through provider manager to devices instead
of just camera module
- Still TODO:
- Update Camera3Device to use new HIDL interface
- Update CameraHardwareInterface to use new HIDL interface
- Update dump()
- Update vendor tag handling
Test: New unit tests pass, camera CTS passes with Treble disabled
Bug: 30985004
Bug: 32991422
Change-Id: I7ac41f13b9501d5e53256e28c0465ec70aa3980e
There is thread safety problem for mTriggerMap in
Camera3Device::RequestThread::clear(). For correctness,
acquire mTriggerMutex before mTriggermap.clear().
Test: 1. Configure power saving mode to 2 seconds by
modification software;
2. using pyhon or monkey to turn on the screen every 4
second;
3. device doesn't crash any more on loop test.
Change-Id: I2f04e21dae3a9879d6cebfefb9d9c191ef3f4df4
Allocators now require a layer count, but in these cases we can
assume that a single layer is sufficient, since that's what they
effectively do now.
Bug: 31686534
Test: manual
Change-Id: Ic22f56f8dbbf5bca01ad21421d12faac95783de7
In case request fails for a burst, previous not-yet-submitted
requests that are put into mInFlightMap are never taken out.
This causes waitUntilDrained error.
Bug: 32466355
Change-Id: Icd28d465dca3f850938c13058c916efc477b0d2b
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
The synchronous consumers (e.g. ImageReader) may be very slow when the
clients have computational intensive image processings. When system
load is high, these processing will be even much slower. This could
starve the producer side and then cause dequeue/attach buffer block
indefinitely. If clients intends to close the capture session, right
after a capture request is submitted, the waitUntil drain could be
blocked indefinitely if the capture request dequeue buffer call is
blocked indefinitely, as the request thread will never become idle until
the last dequeue buffer is done and the request is sent.This indefinite
getBuffer() blocking could easily trigger the waitUntilDrained 5s timeout
thus put the camera device into error state although there is nothing
bad happening in the HAL.
Introducing the timeout will avoid such bad situation. When consumer is
slow, there will be no new request being sent to HAL, as there is really
no new buffer available.
Bug:30404840
Change-Id: Ibf08d2745911203bce6f31130800707f36d7f985
* Add explicit keyword to conversion constructors.
Bug: 28341362
* Use const reference type for read-only parameters.
Bug: 30407689
* Use const reference type to avoid unnecessary copy.
Bug: 30413862
Test: build with WITH_TIDY=1
Change-Id: I71d3008da843ba5f1df1a73a320fb2af6ceffa16
Merged-In: I71d3008da843ba5f1df1a73a320fb2af6ceffa16
The synchronous consumers (e.g. ImageReader) may be very slow when the
clients have computational intensive image processings. When system
load is high, these processing will be even much slower. This could
starve the producer side and then cause dequeue/attach buffer block
indefinitely. If clients intends to close the capture session, right
after a capture request is submitted, the waitUntil drain could be
blocked indefinitely if the capture request dequeue buffer call is
blocked indefinitely, as the request thread will never become idle until
the last dequeue buffer is done and the request is sent.This indefinite
getBuffer() blocking could easily trigger the waitUntilDrained 5s timeout
thus put the camera device into error state although there is nothing
bad happening in the HAL.
Introducing the timeout will avoid such bad situation. When consumer is
slow, there will be no new request being sent to HAL, as there is really
no new buffer available.
Bug:30404840
Change-Id: Ibf08d2745911203bce6f31130800707f36d7f985
To mitigate the request thread CPU starvation for system highly loaded
situation.
Bug: 30357698
Bug: 28313712
Change-Id: Ied30103ce7245e139580219cce99d743b657307e
Currently we only wait for the request queue to be idle, and for
all outstanding buffers to be returned to their queues and their
fences triggered.
But we also need to wait for result metadata to arrive for all
in-flight requests. This is simplest to check for by monitoring
entries in the in-flight map and signaling idle/active to the
status tracker when the map becomes empty/nonempty.
Bug: 30282459
Change-Id: I34275b0fdb4f279783291d300707ac21a6aa5249
Add new -m dumpsys option to cameraservice dump for monitoring
changes in selected metadata values in requests and results.
This option takes a comma-separated list of metadata keys, or the
shortcut value "3a", which expands to all the "android.control" tags.
In subsequent dumpsys calls, the last 100 changes to the tags being
monitored are listed.
The monitoring must be turned on once the camera device is running.
Bug:
Change-Id: If8938b30611ccafa86c2c4a06e57fc72680f827b
If a stream was abandoned (consumer died), the stream teardown would
terminate early. Update teardown conditions to complete even for the
abandoned state.
One consequence of this is that the buffer manager never received an
unregister call for the stream, leading it to error out when trying to
remove buffers from it.
Also switch to STATE_ABANDONED in case of an error detaching a buffer,
instead of the error state.
Bug: 29778464
Change-Id: I44de69773e8bbf9ebe83207498d6ee0674ed91bf
- Maintain separate count of attached buffers
- Only attach when new buffers need to be allocated
- Only detach when a buffer needs to be freed
- Fix missing notification initializations
- Remove warning that's always logged
Bug: 28695173
Change-Id: I38e997fa1e69c2b8743e43eed31a6a08a6f9cd7a
If stream configuration fails, do not set the device status to
STATUS_ERROR except when HAL returns a fatal error. This allows
the application to try another configuration after one fails.
Bug: 29248970
Change-Id: Iffa4b734c13b79a7da95be994a6317002627d771
am: aedd66764b
* commit 'aedd66764b713c5e56e911f45a43a1a44d3dee70':
Camera3Device: Prepare video stream for high speed
Change-Id: Ib65b905a7179c47569013c15b37c21eae14df555
am: 86823e4d1f
* commit '86823e4d1fc81fabdf4baf95d7635768bb9677ba':
Camera3Device: Prepare video stream for high speed
Change-Id: I4072fc088da23c3bd6ff2a952f2303e596f319e0
am: 86823e4d1f
* commit '86823e4d1fc81fabdf4baf95d7635768bb9677ba':
Camera3Device: Prepare video stream for high speed
Change-Id: Ia81057ad033d89a3e705c1d9ee661bd365853f19
Prepare video stream for high speed recording on the first video
request to avoid buffer allocation after video recording starts.
Bug: 28246165
Change-Id: Iaf41c6b779e5b689f568453d99a9058c8aec3881
Since we only do this once per session, it has trivial overhead,
and it's important that any permission denials are actually properly
detected.
Bug: 28246165
Change-Id: Id4c23db6e3b7ab5f7755b3f55ddd589cbdbde8af
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
Keep a list of outstanding buffers in Camera3Stream so that
it won't return invalid buffers or the same buffers twice back
to the buffer queue.
Bug: 27894484
Change-Id: I9f96629b4f531778433c2e1ec32a142f2040832b
Erasing iterator invalidates it, so it's not safe to continue using it.
Besides, there should only be one buffer to erase anyway.
Bug: 27878949
Change-Id: I00e9845fa953c26e117e40112b9f35fc781c5dcf
Camera api1 doesn't have error notification if JPEG buffer is dropped.
Add retry logic to try again if such error happens.
Bug: 27074407
Change-Id: I646566c6ee5a064896b5a433d8e1797140f0d257
- Switch clients of camera devices to use new dataspace values
- For older HALs, map to legacy dataspace values
Bug: 27344373
Change-Id: Icabc345025383f987ef4472cd26182a580dc8b3c
Change Camera3Device to send partial results as soon as a
partial result is received from HAL so that 3A partial results
are not bundled.
Change FrameProcess to wait until all 3A states are received before
notify the client about 3A changes.
Bug: 17320166
Change-Id: I31a3e42081430ff4f7a482c4b2f1db272b8b2e4a
It's possible that the dump is called during the device shutdown
process, where the buffer manager could be already torn down. Add
null check before calling the dump function.
Bug: 27500853
Change-Id: I179eb7ac1e81be2c196833b2c88488cd59fe2cc5
- 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
If buffer consumers assume different clock domain compared to the camera
output, camera3 device uses the offset between the clock domains to convert
the timestamp.
Bug: 27153476
Change-Id: Iaae33281411cb27b639e87b0dad957d640182898
This reduces the chance of allocation during stream steady state.
It helps the cases where one stream is active, and other streams may
randomly request some buffers.
Change-Id: I3f29001a45e223dd2e7929452c4a2ac81a1213f2
Not all HAL3.2 devices implemented dynamic buffer registeration.
This CL excludes the HAL3.2 devices from the buffer manager
supported devices.
Bug: 26955436
Change-Id: I5bc2eec0a4db2f5ab85f7677ed7b367c13ce67aa
The dynamic buffer count water mark starts from zero, and grows when the max of
hand-out buffer counts grow, until reach to the max allowed total buffer count.
For the case where the clients almost always uses less number of buffers than
the max allowed total buffer count, the dynamic buffer count water mark will
remain low, and the memory footprint will be smaller.
Change-Id: I305f40232f4740d3e9bedf14ee9b76a81e29e244
When a buffer is cancelled, it is considered as a free buffer and need to be
returned to buffer manamager for buffer reuse. This will also make the prepare
work.
Also fix the buffer removal bug.
Bug: 25088440
Change-Id: I0e3da44c76008406ee19541366da7a962c355949
Certain consumers such as Hardware Composer and AudioSource
use MONOTONIC timestamp, which causes time misalignment if
camera timestamp is in BOOTTIME.
Do not set buffer time stamp for such streams and let
BufferQueue handle it.
Bug: 22214409
Bug: 26762232
Change-Id: Id1c4b85a181e39827e8f27949a199165bbd445f9
* Add camera buffer manager for buffer allocation and sharing management across
multiple streams. Only gralloc v0 implementation is done, v1 implementation is
pending. With this, the max mem footprint for multiple streams in the same
stream set will be the max buffer count x max buffer size.
* API1 client will still use the old bufferQueue code path, buffer manager
is only targeting at API2 clients.
* Prepare and teardown should work with buffer manager.
* Some existing code typo fix and cleanup (to fix the compiling warnings).
Bug: 25088440
Change-Id: I68b246faa43080302acd02a8e976384bd3e26a23
HALv2 only ever shipped with Nexus 10, and has been fully superceded by
HALv3. Remove it to allow for various code simplifications and cleanup.
- Remove Camera2Device
- Remove various special-case codepaths for supporting Camera2Device
- Remove CameraDeviceFactory, since it only creates Camera3Devices now
- Remove BurstCapture and associated CaptureSequence/Parameters code
- Remove old ZslProcessor and simplify ZslProcessor hierarchy to be
just ZslProcessor3, which is renamed to just ZslProcessor
- Add service-init-time check for unsupported device versions
- Fix assorted compiler warnings, some old, some new
- Remove references to HALv2 when possible
Bug: 25866588
Change-Id: Ia1063264d315f9b742ec5cdd0483539310894f5e
Based on periods of the request thread and audio threads with
SCHED_FIFO policy, 1 is a more reasonable priority for HFR
request thread.
Bug: 24427480
Change-Id: I91f0066a0e114fc83abcc6a604ecbaa72c6a34e8
Bookkeeping reprocess shutters separately so regular and reprocess
shutters together don't need to come in order.
Bug: 24497512
Change-Id: I4aaf22045131e9e2e26bf163f7df9ff4c5cd6259
- Move SchedulingPolicyService from audioservice to mediautils
- When starting up a high speed stream config, set request queue thread
to SCHED_FIFO using SchedulingPolicyService
Bug: 24227252
Change-Id: I224b59142bd111caf563779f55cddd62385b9bac
Signal buffer returned even after it failed so the thread waiting
for it can wake up sooner.
Bug: 23981045
Change-Id: Iccbcc7ece2e0f6204da9c54f2bdd96ff6843a8f5
Make the Vector of next requests a RequestThread member variable
to avoid memory allocation in every threadloop.
Bug: 23360060
Change-Id: I4f33e5c49f0f4deb1f9f45bada0909da748849e4
Refactor request threadLoop to three parts: waiting for next
batch of requests, preparing HAL requests and output buffers for
next batch of requests, and submitting the batch of requests to
HAL.
Set the batch size to the size of the request list if it's a video
recording request in a high speed video configuration.
Add a flush lock so that HAL's flush() won't be called while
submitting a batch of requests.
Bug: 23360060
Change-Id: Icd395b1f955a9b336eec6fa5aff6b17741ce08c7
The HAL device shutdown will likely need to wait on various events and
queues to drain, and holding the mutex will prevent, for example, error
notifications from being processed. This can lead to deadlocks.
Bug: 23501571
Change-Id: I873ac23ef30545adf533e7839445448573ab5048
Relax InFlightMap size check for high speed configurations to
allow more pending capture requests.
Bug: 23162274
Change-Id: I955fe9a0754f0daed001f4a2b34ccb50f2465a11
Potential deadlock conditions this addresses, include:
- Not waking up waiting threads for several situations where
the status had been updated.
- Not waking up all waiting thread when status had been updated
(only one thread was awoken due to use of signal).
- Threads clear status transitions before other waiting threads
have a chance to examine them.
Bug: 22448586
Change-Id: I53ba669d333a83d2bfa1ca3170d34acc6d8fe6e3
Pass whether AE lock is available when creating the request thread
because when the request thread was created, its parent's info
was not set yet.
Bug: 20494782
Change-Id: I11ed3f99c473955c437e81f3e1d704c15a9ca1a4
If high speed mode changed, HAL needs to reconfigure the streams
even when the stream configurations don't change.
Bug: 21900311
Change-Id: I76aee456b3b6d8c8f599a1638dcd38d75553a235
Also switch use of ANativeWindow to Surface, to get to the
getConsumerName() method where necessary.
Surface can always be cast to ANativeWindow, but not the other way
around, so it's a better option anyway.
Change-Id: Ie5c2d30821c1a754f9e382699ff50b4b328288b3
Since configureStreams is only called by CameraDeviceClient,
the operation mode could default-initialize to CONSTRAINED_HIGH_SPEED
for API1 operation.
Change-Id: Ide71af07ca3925db8e450d00def1daeb44d8046a
- Support new set video format/dataspace command in camera service
- HALv3: Select gralloc usage flags based on format
- HALv1: Pass format command directly to HAL layer
- Use format/dataspace command in CameraSource
- Switch all API1 recording to use metadata mode
- Switch all >= HALv2 API1 recording to use kMetadataBufferTypeANWBuffer
Bug: 13222807
Change-Id: I2e609b92c65792611bb1dab09e0c41c363ebbc42
Get an input buffer right after camera service takes one
reprocess capture request from the request queue to prevent
the input buffers getting out of order.
When aborting pending reprocess requests in the request queue, also
abort the same amount of input buffers.
Bug: 21028914
Change-Id: I7cfacecb4c24509f59c983abd587db5a403237bd
There's a narrow window in which a capture request is neither in the
request queue or handed off to the HAL, which can be expanded to some
size if buffers have to be allocated. During this window, the
prepare() method will not correctly notice that a stream should be
considered in use.
Add a member to contain the current request being processed, and check
against it in prepare as well.
Change-Id: I3a198d617f5feee0a3332af4b4439f24eda28ea3
- Mutexes _might_ be a good idea
- Don't be surprised by behavior that's expected
- Use the existing logging macros
Bug: 20537148
Change-Id: Ie62985a786d7e6645b4e4fe019dd98b02891a1f7
Allow mixing regular and reprocess requests in a capture burst. Also
call abandon() when deleting an input stream.
Bug: 20537735
Change-Id: If8c7781038173ab21c73f5ddc32f53793cf86fd9
The prepare call asynchronously pre-allocates buffers for a given
output stream, and then fires the onPrepared callback.
Not implemented for Camera2Device or used in Camera2Client.
Change-Id: I1cccdfff846dd6985133c591dbdceed823929ade
According to spec, HAL will set release_fence to acquire_fence
when error happened (usually during flush call). Camera service
should not refer to the acquireFence anyhow since per spec HAL
needs to set it to -1 if acquireFence has been waited on.
Change-Id: I809355d0c8c71f78f657e37d19221fd1f5bdc90b
Switches all uses of IGraphicBufferConsumer::BufferItem (and
BufferQueue::BufferItem) to the BufferItem in libgui. Depends on
frameworks/native I699ed0a6837076867ca756b28d1ffb2238f7a0d9.
Change-Id: I187b3a7d05196b6289596afac8fb9a9d4aebff76
- Remove unused arguments from ICameraDeviceUser::createStream
- Add dataSpace as a stream parameter, plumb it through everything
Change-Id: I608cafe694785d1c512276e71b2016f8ac3b0ccb
Implement flashlight for HAL v1 devices and remove
CameraHardwareInterface's dependency on CameraService to avoid
circular dependency.
Bug: 2682206
Change-Id: Id5bbccef085b607a6189763fd7fbe2e3f26868c8
Wrap camera module returned from HAL so get_camera_info returns
static_camera_characteristics processed by framework, which
generates keys added after HAL3.2 is released.
Change-Id: Ief423a1571cf06c7ef80b98b403a33969baf95f6
Assuming the jpeg header can take up to 256KB, make sure we always
allocate enough size for the image data.
Bug: 18962703
Change-Id: I08eb3d198d12f71f3ab7266324e80fe7410bdc89
Move the code to remove in-flight requests from processCaptureResult
to a separate function so it can be called when the framework
receives a result or a shutter event. An in-flight request will only
be removed when both results and the shutter event arrive in the
case of a successful request.
Also send out results only after the shutter event receives.
Bug: 18135776
Change-Id: I340db1a495c711b0913784d43fd0f144871e4420
For per-frame error notifications, camera3.h requirements state that all the
buffer handles for a failed frame capture must be returned via
process_capture_result() call(s). Hence, Camera3Device needs to ensure that
the frame entry is not deleted from mInFlightMap until all buffers for that
frame have been returned by HAL.
Bug: 17757940
Change-Id: I2579ca7980d2fd67d53abc530e2706538f7d3d3a
Update ZSL processing tags according the still capture template
Also cache the request template to avoid extra cost of querying
into HAL every time.
Bug: 17463102
Change-Id: I2eeffefb0a4131c99a85dd3e4484cc6f0f025efa
After ZSL queue is cleared, don't add capture result to ZSL queue
if its corresponding buffer has been cleared.
Bug: 17185356
Change-Id: Iddac39ab09b2560e2ce9390895927217c1736d5a
When recording fails to start due to stream configuration failed,
try configure stream again by setting jpeg stream to video size.
Bug: 16162133
Change-Id: Ib20271e787ae07719ce419f0b15c7f86434f7ebb
A workaround for a camera device HAL v3.2 or older specification hole - it's
not acceptable to configure_streams with 0 output streams. However, we allow for
this at the public API level, to allow an application to release all output streams.
So in this case, create a dummy stream that doesn't actually do anything as a placeholder.
Bug: 17220694
Change-Id: Ib25242ffc2c9f2b2f619fd5fe6d652266579da85
- Add more error codes to the binder camera2 callbacks
- Translate HAL errors to callback errors
- When flushing, report failures for queued requests
- Treat stream config failure as nonfatal
- Send request errors when buffers aren't available for captures
Bug: 15524101
Bug: 14448494
Bug: 11272459
Bug: 17160301
Change-Id: I81aa54e805a9cce1cb8a6a9374549daa7666deb2
This check doesn't work with ZSL use case. Since the ZSL is both an input and
output stream, When an input buffer is acquired, checking the handout buffer
count for that stream could trigger false alarm when all the output buffers
are sent to hal, instead, we should wait for an output buffer to return.
Bug: 17188380
Change-Id: I7eb166eb49d2f063189d993195ef389d2cf4f2b4
This makes the configuration more eager (no more waiting until the first
request) and also allows any errors to immediately be sent back to the
client.
Bug: 16629195
Change-Id: I0c365bc8f760466916dcc089217a43c43f9f4c9d
- Only one place calculating the jpeg size-the device layer, Camera2Device and
Camera3Device.
- Remove size argument for CameraDeviceBase and cleanup related code.
Bug: 14327010
Change-Id: I45d2ab4859ee0cc9273e579254f0569108c748f1
- Refactor where availability listeners are called to centralize behavior,
ensuring that all client creation/destruction invokes the listeners
- Clean up some of the client hierarchy
- Filter error codes from key HAL calls to ensure proper reporting
Bug: 16514157
Bug: 16483222
Change-Id: I59875a865b6a508b47423946c78862da8df34cd1
Also override the disconnectLocked method in Camera3ZslStream to make sure the
Camera3ZslStream specific buffer queue is cleaned up properly.
Also revert 0be123df18, as it was not the right
fix.
Change-Id: I89bdcb2e206379ae1f2602421e7fdbcde9a31399
- Enable the normal partial result path for HAL3.2, the quirk is only used
for the HAL version lower than HAL3.2. The partial quirks is no longer supported
for HAL3.2 or higher versions.
- Add CameraDeviceBase getDeviceVersion API.
- Fix some build warnings
Change-Id: I7a1b03d4d5fd5258d2addfba4368bee2ba691337
This is to WAR the case where HAL sends non-NULL input_buffer in capture
result even capture framework doesn't send input buffer in the request.
It's very likely the input_buffer is uninitialized, and we shouldn't
use it. Log a warning for such case as well.
Bug: 16115675
Bug: 16117312
Change-Id: Ib299b45fbfe084059a9f546ded239c8094b039e2
- Return input buffer in capture result. Per hal3.2 spec, we should return the
input buffer in process capture result rather than immediately after process
capture request.
- Make the depths of mZslQueue and mFrameList the same. It doesn't make sense
mFrameList depth is larger than mZslQueue depth.
- Set the depths of mZslQueue and mFrameList based on pipelineMaxDepth.
- Clear result queue while clearing zsl buffer queue.
- Hook up camera3 buffer listener with ZslProcessor3, make sure that adding the
same listener multiple times has no effect.
- Remove flush call in pushToReprocess, it is a guaranteed deadlock once
camera3 buffer listener is hooked up.
Change-Id: I285155ab4241e827145855d628f8e98b881c01d5
The following two tags are deprecated from HAL 3.2:
ANDROID_CONTROL_AF_TRIGGER_ID
ANDROID_CONTROL_AE_PRECAPTURE_ID
Trigger IDs are now internal to camera service.
Change-Id: Iaebd62ecb0905a811fa37fe7850e0221c38a0006
Starting from device version 3.2, the following tags:
ANDROID_SCALER_AVAILABLE_FORMATS
ANDROID_SCALER_AVAILABLE_JPEG_MIN_DURATIONS
ANDROID_SCALER_AVAILABLE_JPEG_SIZES
ANDROID_SCALER_AVAILABLE_PROCESSED_MIN_DURATIONS
ANDROID_SCALER_AVAILABLE_PROCESSED_SIZES
ANDROID_SCALER_AVAILABLE_RAW_MIN_DURATIONS
ANDROID_SCALER_AVAILABLE_RAW_SIZES
are deprecated and replaced by:
ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS
Change-Id: Iadc34af0ea985a16a25759d7a9a3eb4845c486fd
The max jpeg buffer size was always the android.jpeg.maxSize, regardless of
the actual jpeg capture size. This creates a huge memory waste especially
for smaller size jpeg capture. Now the max jpeg buffer is linearly scaled based
on the resolution.
Bug: 14288983
Change-Id: I8a971b8e2f4fc7fec0154547bdb688579af71a47
HAL calls into Camera3Device functions like processCaptureResult during flush
call. When Camera3Device runs into error state during flush call,
processCaptureResult calls setErrorState(), which leads to deadlock.
Change-Id: I35a03f6eb4b77f914097917cb37de98663de365f
* clear mStreamingRequestList in flush
* fix frame number checker in notify and processCaptureResult
Bug: 14166437
Change-Id: I022421080d05138f9068c1b9b85d83bd613b04fb
Camera3Stream shouldn't error out when the max number of buffers are already
dequeued. It should block until next buffer returned from camera device.
Bug: 11595505
Change-Id: If65a70c29cb04219e14ded0744059c0ab783444b
Set mNeedConfig after creating ZSL stream, camera device
will reconfigure for the case when only ZSL stream
is changed.
Change-Id: Ib592817f81125969824a1280349f77973116f375
* Instead of tracking CameraMetadata only, now we track both
CameraMetadata and CaptureResultExtras, which is not part of
the HAL metadata. This will enable the correct callback of
onCaptureStarted and onResultReceived given burst requests.
* Get last frame number in reply when submitting requests,
canceling requests, and flushing device. For repeating requests,
this frame number is the last frame number of the previous
request. For non-repeating requests, this frame number is the
expected last frame number of the current request. The goal
is provide frame number to Java side in order to trigger
onCaptureSequenceCompleted correctly.
* Fix notifyError so that onDeviceError can be called correctly.
Bug: 10749500
Change-Id: I2f3dda6c530090055d4a2ff9f0f087bbbe8d9257
Use 'setprop camera.dev.register_stream 1' to skip the fatal NULL check
- This property will be removed before shipping L
Bug: 13301331
Bug: 13435680
Change-Id: I16aacd7b22e0a10b34f6fb8501be0256170a8cd5
Flush shouldn't call waitUntilDrained directly, as they are all API calls
with mLock and mInterfaceLock held. Move the waitUntilDrained implementation
into waitUntilDrainedLocked to solve this issue.
Change-Id: Id7d931091d5c11e12204790841097433515446db
Emilian Peev
Eino-Ville Talvala
Chih-Hung Hsieh
Yin-Chia Yeh
TreeHugger Robot
Shuzhen Wang
Yifan Hong
Chia-I Wu
Steven Moreland
Mathias Agopian
Mikhail Naganov
Jinguang Dong
Craig Donner
Zhijun He
Chien-Yu Chen
Aurimas Liutikas
Ruben Brunk
Dan Stoza
Ruchit Sharma
Igor Murashkin
Jianing Wei
Yuvraj Pasi
Vineeta Srivastava
Colin Cross