- 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
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
A race condition is possible during access to status tracker
in 'disonnect' and inflight updates like 'registerInFlight' and
'removeInFlightMapEntryLocked'. To avoid this, access is serialized
using 'mLock'. However 'mLock' is also used in other contexts which
under the right conditions could result in a deadlock. One such instance
could occur during consecutive reprocess requests. The request thread
while holding the request lock will try to obtain a free input buffer.
In case the input stream doesn't have any free buffers left, it will
block on an internal condition and wait. In the meantime if another
capture request gets submitted, then the request itself will block on
the request lock within request thread while holding 'mLock' inside
submit helper. This will not allow incoming input buffer results
to get processed as they could call 'removeInFlightMapEntryLocked' and
try to acquire the already locked 'mLock'. The deadlock will continue
until the input stream timeout expires, which will fail the request.
One way to resolve this is by adding a separate lock which will only be
used for the status tracker access synchronization.
Bug: 79972865
Test: Camera CTS
Change-Id: Ic63f891202ba102f6408ed714c5eef29b41404e3
Shared surface outputs currently re-use the transformation
from the input queue directly. However the inverse display
flag will get reset by the queue logic and needs to be set
again before the incoming buffers are sent to the registered
outputs.
Bug: 110641448
Test: Manual using application,
Camera CTS
Change-Id: I36859eb41ccab8459bbd97bad3ea0b6a8575489c
Zero weight regions have no actual effect. Skip them.
Also clamp the correction result to be within active
array.
Test: GCA smoke test
Bug: 109766306
Change-Id: I24640ffb564f30dcbc14cf8c97f8100c0bad2640
Face rectangles are actually a pair of points, not rects with
(top, left, width, height).
This is very silly but what can you do.
Test: Check metadata output with forced-on distortion correction
Bug: 74434422
Change-Id: I5c0ede9624a198f1dd68328c2dcfa6788ed2d9d9
- Make cameraserver_test test module reachable by build system
- Fix minor compilation error in CameraProviderManagerTest
- Add tests to verify:
- Initialization of DistortionMapper
- Transforms with an identity distortion function
- Round-trip transform ~1e6 points with a large distortion function
- Raw to corrected transform compared against OpenCV undistortPoints,
using python to generate the comparison coordinate lists as a C++
header
Test: atest cameraservice_test
Bug: 79885994
Change-Id: Iae3d6f9de2e6c79dd5cea5ca35ee5100b38441f4
- API1 + HAL3: Enable HIGH_QUALITY correction for still capture use
cases, FAST for others
- HAL3: When distortion correction is enabled, map coordinate metadata from
corrected to original in capture requests, and from original to corrected
in capture results.
Test: Camera CTS
Bug: 79885994
Change-Id: I79e25d278fe69099770c749f42956fc8e878f7cf
This reverts commit b139b178e8.
Reason for revert: This breaks camera-camcorder switch on older devices
Bug: 80227606
Change-Id: Idd63652946537abdebed61ea4acf18b79d513048
Currently we are configuring the number of output
slots in each new shared surface as the sum between the
maxiumum stream buffers and the minimum undequeued buffers
per surface. However the total number of buffers that
will get allocated in the input stream queue increases
with the latter undequeued ammount on each new output.
The delta between these values could result in
insufficient output slots for some outputs that consume
buffers with vastly different speeds combined with a
slow camera producer that exhausts all dequeued slots.
To avoid this set the output slot count the the maximum
supported number by the framework. Allocation is disabled
so this should not increase the number of allocated buffers.
Bug: 80079782
Test: Manual using application,
Camera CTS
Change-Id: I36eed94a169a802f33126b640dd1d95725aec8db
In case camera clients don't pass any session parameters try to
load their initial values depending on the last cached default
request.
Bug: 79989121
Test: Camera CTS
Change-Id: I73dd6b37584f6ae5dc5b9681313eb080ddd53b88
Per API specification the maximum framerate range is the only
value that needs to be considered during constrained camera
sessions. If target fps is part of the session parameters, then
we should only monitor for modifications in the upper range.
Bug: 78494729
Test: Camera CTS
Change-Id: Ic7de406820347f8e58bf3d4fee7750f694372604
The output slot vector will be initialized with the total number of
buffers per output and any buffers that get attached are indexed via
the returned slot value. However there is no guarantee that the slot
will be within the [0, totalNumberOfBuffers) range. The bufffer queue
can return anything from [0, BufferQueue::NUM_BUFFER_SLOTS) and this
can result in invalid memory operations and potential instabilities.
The resolve this validate the slot value and resize the output slot
vector accordingly.
Bug: 74828453
Test: Camera CTS
Change-Id: I20502000a5c278eb9a81600282d1fad98455a2c4
With the change to update slowJpeg flag on the fly, it becomes
possible a jpeg stream is deleted during active streaming.
Test: TestingCamera change still picture size from small to large
Bug: 72261327
Change-Id: Ia01b47926ab03cdfe1e0aa10fcf61ff984ba4e2c
Blocking dequeue calls for async output surfaces seem to be
possible. Refactor the code so that stream splitter doesn't
hold any locks during output surface dequeue calls triggered
by buffer released callbacks.
Bug: 73953239
Test: Camera CTS
Change-Id: Ia2166de73d2b8de7ef4157e81c87f53c8a264c0c
Monitored camera tag dump options should be stored
by camera service and parsed during initialization of
each new camera client.
Bug: 71640311
Test: Camera CTS,
Manual using application
Change-Id: Id464fbaec40395e93969b90abbd07f0a5cd0dc30
Streaming capture requests which include individual physical
device settings should not be blocked.
Bug: 72524845
Test: Camera CTS
Change-Id: Idb3ad9d022d4e2b2ced2558d1746866dbd3842b4
Hal interface stream configuration will iterate over all
available streams both input and output. However the
'outputBufferSizes' vector includes only buffer sizes for
output streams. If we have an input stream, then an invalid
memory access is possible. Resolve this by allocating enough
'outputBufferSizes' entries.
Bug: 72736744
Test: Camera CTS
Change-Id: I6973f1fbf499628437b7523aab6bf13c88015448
Cached 3.3 and 3.4 HIDL session references must be cleared
otherwise the session implementation will not get released
and this could result in resource leaks.
Bug: 72692738
Test: Manual using camera application
Change-Id: I1d4eef43295db837f2fb4380bd84e2e7dfb5b5ef
- 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
Because the request thread went idle before it notified the parent to
reconfigure, the flag to avoid spurious notifications was set too
late; an idle notification would already be sent by then.
Move the flag setting to the beginning of the sequence to correctly
suppress all needed notifications.
Test: No crash in previously affected app; camera CTS continues to pass
Bug: 72392658
Change-Id: Id7d1f66bab455035bbec7b04f7dd4157ad94b773
Needed for two new template enum values for MOTION_TRACKING
Also move query and initialization of minor HIDL version interfaces to
device startup.
Test: Camera CTS continues to pass as before
Bug: 63629224
Change-Id: I2feb3a6875b6216dc8299a997bda7b51640038bb
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
Add physical camera ID in OutputConfiguration so that the application
can optionally set physical camera id for an output stream.
Test: Camera CTS
Bug: 64691172
Change-Id: I5909cd71618cc07ef403c420913eb1c02f1e10f0
Camera clients are allowed to change session parameters during
active session, however some camera devices might not be able
to apply them without additional stream configuration. To resolve
this, detect whether any of the available session parameter changes
in the queued requests and re-configure the camera before trying
to apply it.
Bug: 64450664
Test: Manual, Camera CTS
Change-Id: I005d6b7d6c6b27d4b5bac4b0d0809c7c019af9a4
Dynamic consumers removed by client could still hold one or
several buffer references after streaming stops and the
producer interface gets disconnected. Returning those buffers
in the input queue is not recommended as they can continue to get
accessed at the same time as the camera modifies them. To avoid this
try to detach all previously registered buffers. If the call
fails for some specific buffer, then try to detach it from both the
input queue and the remaining outputs.
Bug: 70223208
Test: Camera CTS
Change-Id: Ie35c7a2360d970ab5c860be7b580140dfb768934
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
If the device support ZSL, drop pending preview buffers to reduce
the chance the rendering preview frames newer than the still frame
during takePicture().
Test: CTS
Bug: 67497723
Change-Id: I5f253a402a6302d31777ad4ca2878ef0d0d1ae44
(cherry picked from commit c75eb9b126b2c6b7fc8f47d8ae4e4ac15f6a176e)
The Camera API needs to support the dynamic attach/detach of extra
output surfaces to a given camera stream.
Bug: 63912484
Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
It is allowed and expected some stream formats to get overriden
by the Hal implementation. In such cases the original format should
be stored and made available to device clients.
Bug: 64571102
Test: Camera CTS
Change-Id: Ic1153390e0c4d194475fbda8c8a13323bd7e73c0
In case a result error is followed by a buffer_error for a particular
request, current logic won't be able to remove the pending request from
the inflight queue.
Moving the skipResultMetadata flag into InFlightRequest struct fixes the
issue.
Test: Camera CTS
Bug: 64840907
Change-Id: Iac44e431f9e9fc38684f8509328c777f9cf5f956
"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
Yin-Chia Yeh
Eino-Ville Talvala
Shuzhen Wang
Emilian Peev
TreeHugger Robot
Chien-Yu Chen
Chih-Hung Hsieh
Yifan Hong
Chia-I Wu
Steven Moreland
Mathias Agopian
Mikhail Naganov
Jinguang Dong
Craig Donner
Zhijun He
Aurimas Liutikas