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>
Also make the timeout sleeping more granular, so that the wait
won't always be 300ms in case the initial checks fail.
Test: Camera CTS passes
Bug: 110840510
Change-Id: I3f0d09913b10526dd27cecca50c111712da82846
Merged-In: I3f0d09913b10526dd27cecca50c111712da82846
There is a race between the UID turning active and activity
being resume. The proper fix is very risky, so we temporary add
some polling which should hapen pretty rarely anyway as the race
is hard to hit.
Test: camera works fine
cts-tradefed run cts-dev -m CtsCameraTestCases
bug:77827041
Change-Id: I1768d00dc08e6e49cec0099f0a29b7889f9affad
Merged-In: I1768d00dc08e6e49cec0099f0a29b7889f9affad
'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
Camera characteristics for camera clients that don't
hold the camera permission must not contain any
metadata that explicitly requires this permission.
Vendor tags must be absent in this case as well.
Bug: 112160024
Test: Manual using application,
adb shell /data/nativetest64/camera_client_test/camera_client_test
--gtest_filter=CameraCharacteristicsPermission.TestCameraPermission
Camera CTS
Change-Id: I4e34c6ef7bd4315327ca78084fa3dcc175fc8098
Support 3_5 HAL device version for querying physical camera
characteristics.
Test: Camera CTS on Pixel devices
Bug: 79523700
Change-Id: I804cdb5dc75553d6b6f9fb42187a76bd69168179
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)
A non-API1 compatible camera might still has flash
unit and supports setTorchMode.
Test: partner testing
Change-Id: Ic8974afea13318624f35d17af4c4c238ee3fbf85
If HAL overrides stream format, use the overridden format to configure
the buffer queues.
Bug: 113326269
Test: Camera CTS
Change-Id: I6b198e8ebfeaeafbda530722d995a12f88f0b35a
This test was added to TEST_MAPPING but it needs to be packaged
properly in order to be utilized by TEST_MAPPING.
Bug: None
Test: TH Run
Change-Id: I86d885ef12c5725211ca1fc3123ddb10311f7372
- Add cameraservice_test to presubmit TEST_MAPPING
- Fix broken CameraProviderManager test
Test: Fixed test passes; 'atest' in frameworks/av/services/camera/libcameraservice
runs the expected test
Change-Id: Ia1ceaf526884325d56f0e273f89220fdb33493dd
Improve performance during device detach by flushing all
camera requests.
Bug: 80402005
Test: Camera CTS
Change-Id: I3a6864575b1533c77b5478c2390a908892700f6e
Merged-In: I3a6864575b1533c77b5478c2390a908892700f6e
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
Also make the timeout sleeping more granular, so that the wait
won't always be 300ms in case the initial checks fail.
Test: Camera CTS passes
Bug: 110840510
Change-Id: I3f0d09913b10526dd27cecca50c111712da82846
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
This would allow other client modules defined in Android.bp to include
libcameraservice as a dependency.
Bug: 110364143
Test: mm -j64
Change-Id: Ia3be563e4fbb27155d6a46278931ca689b8cf8fd
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
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
When shutter sound is ON, even if application calls takePicture
without CAMERA_MSG_SHUTTER, the camera service should still play
shutter sound.
Also remove the code using ro.camera.sound.forced since it's
not used any more.
Test: 3rd party app on device with enforced shutter sound
Bug: 111995040
Change-Id: I0d2e888b7f17eff5e5bff8d0f3ec3da7f7ad97b7
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
When HAL supports openLegacy, same camera id can be added more than
once.
Because we now use vector to store API1 compatible camera ids, make
sure no duplicate strings are added.
Test: Vendor camera app using openLegacy, Camera CTS
Bug: 110815837
Bug: 111963599
Change-Id: I327744e102cc75929ebcdf51661f9f4ec7f3acf9
Merged-In: I327744e102cc75929ebcdf51661f9f4ec7f3acf9
(cherry picked from commit 975a39e906)
(cherry picked from commit 258fa2669e)
When HAL supports openLegacy, same camera id can be added more than
once.
Because we now use vector to store API1 compatible camera ids, make
sure no duplicate strings are added.
Test: Vendor camera app using openLegacy, Camera CTS
Bug: 110815837
Bug: 111963599
Change-Id: I327744e102cc75929ebcdf51661f9f4ec7f3acf9
(cherry picked from commit 975a39e906)
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
Improve performance during device detach by flushing all
camera requests.
Bug: 80402005
Test: Camera CTS
Change-Id: I3a6864575b1533c77b5478c2390a908892700f6e
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
- 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
Because onDeviceStatusChanged is reenterable, in the case of camera
provider process crash, the following race condition could happen:
1. Camera provider crashes, onDeviceStatusChanged is called with
NOT_PRESENT. camera service calls disconnect to disconnect from
CameraDevice.
2. Camera provider comes back online, and onDeviceStatusChanged is
called to change the state back to PRESENT.
3. disconnect returns, and the camera state is deleted, resulting in
cameraservice to be in bad state.
This change synchronizes onRegistration and removeProvider to avoid
aforementioned race condition.
Test: Camera CTS
Test: Add delay in removeProvider and kill provider process while camera
is running.
Bug: 110837617
Change-Id: I472f1bfebf770d8eb0b2d7eb5f4a0fa26566bdea
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
When HAL supports openLegacy, same camera id can be added more than
once.
Because we now use vector to store API1 compatible camera ids, make
sure no duplicate strings are added.
Test: Vendor camera app using openLegacy, Camera CTS
Bug: 110815837
Change-Id: I327744e102cc75929ebcdf51661f9f4ec7f3acf9
This is consistent with the default focal length set by the API1-HAL3
shim.
Test: Camera CTS, FOV test for CtsVerifier
Bug: 110445633
Change-Id: I4ecfb32c7cecdd9c56e04b25cf4d92a86122b2cb
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
Clients using the legacy API translation layer will
default to face priority scene in case this mode is
supported by the camera device.
Bug: 110259811
Test: Manual using application,
Camera CTS
Change-Id: I370f222c73ea6e133bb6cb334ced2e33a26bb8c5
FrameProcessor will always gather the complete 3A
state before notifying clients. This could introduce
unnecessary delays for camera devices that support
partial results. To avoid this check the pending 3A
state for each algorithm individually and notify about
state changes as soon as possible.
Bug: 110058858
Test: Manual using application,
Camera CTS
Change-Id: Ie197b2adcd884f1296f621f62cef8d53c9dc99c1
There is a race between the UID turning active and activity
being resume. The proper fix is very risky, so we temporary add
some polling which should hapen pretty rarely anyway as the race
is hard to hit.
Test: camera works fine
cts-tradefed run cts-dev -m CtsCameraTestCases
bug:77827041
Change-Id: I1768d00dc08e6e49cec0099f0a29b7889f9affad
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
ZSL frames were getting completely discarded in case of fixed
focus camera sensors. This can have performance impact for
legacy camera clients.
Bug: 80482772
Test: Manual using application,
Camera CTS
Change-Id: Ic98c8624226e960cffdcbfcee0b3e34adaf720fb
A lot of API1 apps don't handle logical/physical cameras well.
For each [logical, physical1, phiscal2] id combo, only advertise the
first ids in the HAL id list.
Test: Camera CTS
Bug: 80075565
Change-Id: I1e300a8e13eff2bfef0a6a157a56717a7b73976c
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 camera id in CameraService needs to be consistent with the ones in
conflicting device strings.
Strip the simple form camera id from the fully-qualified id.
Test: Camera CTS
Bug: 78277539
Change-Id: I081f36eaba4a0a3dc9ba3323eb386833566c15ba
The conflicting device names are fully qualified, but the current
camera id isn't. Make them consistent.
Test: Camera CTS
Bug: 78277539
Change-Id: I1baf8d39b95bb475ad6a25f2eae7d409efe5d239
'add-/removeStates()' can modify the torch status map
without holding the necessary 'mTorchStatusMutex'. Any
such modification could theoretically access or
contribute to an inconsistent state of the torch status
map. To avoid any possible data race conditions, always
try to acquire 'mTorchStatusMutex' first.
Bug: 77531948
Test: Camera CTS
Change-Id: Ic135d450d4d32224964eabceb24718e03a439fc3
MediaPlayer::setDataSource() doesn't fail with a non-existing file. So
we should check the result of MediaPlayer::prepare() as well.
Note that MediaPlayer::disconnect() is called instead of deleting
MediaPlayer directly because the latter causes crash of CameraService.
MediaPlayer::disconnect() is called even in
CameraService::releaseSound().
Bug: 74376839
Test: tested an app using CameraService
Change-Id: Idf68837a55d14ad47dbbedff0256269bd90f9dfd
Since the camera service is not killed when the system service dies,
it needs to handle detecting the death and re-registering for
UidPolicy updates when the system service has restarted.
When no activity manager is available, don't limit access by UID
status.
Use calls from the CameraServiceProxy service in system service to
trigger re-registration of UidPolicy in case of system service death.
Test: adb shell stop; adb shell start; verify camera service allows
camera use. No camera CTS regressions.
Bug: 74230547
Change-Id: I8ff6b1e88117cc99b9b85e4069a947ff99236e1d
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
Some of the flex pixel formats are software-only and are not
available in HIDL interfaces. Camera service does not expect to see
them.
Bug: 70526789
Test: builds
Change-Id: I70b6ddd8e9214a12cc18ba7456ef1b06a2339cf6
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
API1 compatible camera devices shouldn't be filtered based on
their provider type. Devices must advertise their support by
enabling the backward compatiblity flag in their static camera
capabilities.
Bug: 73738052
Test: Camera CTS
Change-Id: I2b3d80051e89b3a8908d636a1156a32e89b7c4f1
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
IPCThreadState::self()->getCallingPid() is not reliable
in asynchronous callback (in this case binderDied)
Bug: 70946731
Change-Id: Id90d26ddad8ddf51564baa7bd642e3e4eb535182
The client API level should be part of the service proxy
notifications.
Bug: 68653614
Test: Manual using application
Change-Id: Id8a9fb51a8ba91795283c846b55a9343cf8505df
- Cleanup legacy camera_module_t callbacks
- Order API1 compatible cameras by their ID: numeric strings first
- Dynamically updating number of cameras when device is
added/removed
- Make sure the following methods are always called without holding
mServiceLock
- onDeviceStatusChange
- updateStatus
- addStates/removeStates
- Centralized all addState/removeState calls in onDeviceStatusChange
- Passing api1CameraId (number) and cameraDeviceId (string) to various
client classes.
- Allow FOV information to not present for external camera
- Update API1 preview/video size logic to exclude < ~30fps sizes
Bug: 64874137
Change-Id: Ied6b7141fdad30e3d1c3fcacc5b69ca350fdeb24
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
RGBA camera outputs must be overriden to
IMPLEMENTATION_DEFINED format only in case their usage
suggests that the consumer is HW and the SW read flags
are clear.
Bug: 35317944
Test: Camera CTS
Change-Id: I99c6903301b2364ee5b686800950f3898ec973a4
Surface sharing must be enabled for all pixel formats
supported by the camera.
Bug:73135123
Test: Camera CTS
Change-Id: I804a881461a2dc19ad4901b319919df1488be422
* Swap definition of fpsRange and fpsSingle to present correct value.
Without this patch, setPreviewFpsRange() and setPreviewFrameRate()
methods may not work correctly.
Test: partner testing
Bug 73020119
Change-Id: I7a504bb698985489e0bee595db62c99bc2c4db64
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
An individual physical capture request should only be allowed in
case a respective attached capture output target with the specific
physical device is also present.
Bug: 72524603
Test: Camera CTS
Change-Id: I09502e7a15d3ea0a00e935bf222cc9b61cdaca6f
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
Bug: 64195575
Test: tested reading media files from /product/media/audio after moving
files from /system/media/audio to /product/media/audio
Change-Id: Ib5cf79181962ba2b0a70980b44dd7608410c3855
- 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
Currently the camera subsystem is trying to store all cameras, that
have ever been registered with it by camera HALs. This makes it
easier for the framework, but with hotpluggable cameras it makes
little sense, because for this HALs also have to store all cameras,
that have ever been plugged in and with every new plug in event
identify, whether this is a new camera or a known one. An easier and
cleaner approach is to remove cameras upon unplug. This patch
implements that.
Change-Id: Ie38cad59449386351518655e723e3f826a2ec826
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
If a UID is idle (being in the background for more than
cartain amount of time) it should not be able to use the
camera. If the UID becomes idle we generate an eror and
close the cameras for this UID. If an app in an idle UID
tries to use the camera we immediately generate an error.
Since apps already should handle these errors it is safe
to apply this policy to all apps to protect user privacy.
Test: Pass - cts-tradefed run cts -m CtsCameraTestCases
Added - CameraTest#testCameraAccessForIdleUid
Bug: 63938985
Change-Id: Ic0111d7c651b3d84c644b9f3d30e24133544f4fa
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
The Camera subsystem maintains lists of camera and torch states, that
are updated during Camera Provider enumeration. These lists have to
be updated at runtime when a camera is plugged in or unplugged too.
Reuse the same code for both cases.
Also fix a bogus PRESENT callback in stopCameraOps.
Change-Id: I9028a3b25d8d983441e89d52a354bed61e3f8976
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
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
Merged-In: I5f253a402a6302d31777ad4ca2878ef0d0d1ae44
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)
This reverts commit debd04d3df.
The new Clang prebuilt contains fix for the issue, this workaround is no longer necessary.
Bug: 38349491
Change-Id: Ia45f6bf3a151e35460b60ea7e087fc00a80084ab
The Camera API needs to support the dynamic attach/detach of extra
output surfaces to a given camera stream.
Bug: 63912484
Change-Id: I18809aea31f78fb9e125bd18b58951ade4fad3c5
If enableZsl is enabled in still capture template, disable ZSL in
the framework and use device level ZSL instead.
Test: CTS
Bug: 64117056
Change-Id: Ia7f7e3b0212419a12bc1ccb3f708f527b8a0b12c
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
Merged-In: Iba7e6cbebb674994c905f7feb1776acc479b612f
Change-Id: Iba7e6cbebb674994c905f7feb1776acc479b612f
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, 65432229
Change-Id: Id894b5d3482c64125c114f79dbe746c56048fcbe
Merged-In: Id894b5d3482c64125c114f79dbe746c56048fcbe
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
Due to https://bugs.llvm.org/show_bug.cgi?id=34365, the static analyzer
complains about use of copied `sp`s. In this case, the copy is entirely
unnecessary, since we're just going to destroy the copied-from sp
anyway.
Speed things up a bit + appease the analyzer by moving instead.
Bug: 27101951
Test: mma. Static analyzer no longer complains.
Change-Id: I148212e418cb3f8728383db92b564523525b633a
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
No length field after SOI, just jump it.
Change-Id: Ie49bf5230cbeafe17be2c9caac679b5fec08fc13
Signed-off-by: fang hui <hui.fang@nxp.com>
(cherry picked from commit 5bdf8e6f428893c2470c99b2bd9dd029bfe9decc)
"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
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
* Owners are selected from top CL approvals or owners.
They will be suggested to review/approve future CLs.
* OWNERS files are recognized by the new find-owners plugin, see .md files in
https://gerrit.googlesource.com/plugins/find-owners/+/master/src/main/resources/Documentation/
Test: build/make/tools/checkowners.py -c -v OWNERS
Change-Id: I7c848855a2d7a0d7f33123ea4ef5c2d03977b495
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
Providers could have devices with same id but different
API versions. The total number of API1 compatible devices
needs to consider only the unique ids in this case.
Bug: 38237265
Test: Manual using application
Change-Id: I5a31c3cd28f00e8af3029213711505e4075a61b2
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
Camera service should enumarate newly added
camera providers.
Bug: 37592461
Test: Manual using camera application
Change-Id: I4c886b99127d23148c70ce1e1e773cb8393d91b4
android.hidl.base@1.0 and android.hidl.manager@1.0 are built into libhidltransport.
Test: links
Bug: 33276472
Change-Id: I1e33404a582a3707e0990634467c1fc7430c23a2
(cherry picked from commit 240b83a455)
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
Make sure we don't keep any stale available callback buffer
references after recording stops. This can lead to resource
leaks.
Bug: 36478361
Test: Complete Camera/Camera2 CTS tests
Change-Id: I9f72b784ba3ae1cf9f9b16064a13b7ba8a1d0394
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
There could be race in application where finalizeOutputconfigurations
doesn't include any new surface. Do not fail in this case.
Test: CameraStressTest#testBackCameraSwitchPreview
Bug: 36811459
Bug: 35137641
Change-Id: Ic185e6d8bfcb8af5b81a33fbbd2fd4e49cc647ce
If the minimum duration of JPEG is less than the frame duration derived
from maximum fps, enable slowJpeg mode so that JPEG doesn't slow down
preview.
Cap the default max fps to 30 so that the switch between different
sensor modes can be minimized while still allowing the app to go higher
than 30fps.
Test: Camera1 CTS
Bug: 36692074
Change-Id: If4d367ac587c0f4d3620ca2d25063c5a12ebfceb
Appending to a source with valid vendor id from a metadata without
vendor id should be supported.
Bug: 37198452
Test: CameraProviderManagerTest.MultipleVendorTagTest
Change-Id: Ic0b160216386fcfe1aa57b7e4a363b405459b3d0
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
Mark immediate zoom as not supported in case the camera has
maximum digial zoom close to 1. This will avoid corner
cases wehere we can have 'NUM_ZOOM_STEPS' all equal to 1.
Bug: 33093106
Test: Complete CameraTest CTS package
runtest -x cts/tests/camera/src/android/hardware/cts/
Change-Id: I039276385de74192375f36b1504dd89cb8ae0c52
AE/AWB lock availability is present in the camera static metadata.
Check whether they are supported before advertising them in Camera
Parameters.
Bug: 33091727
Test: Complete CameraTest CTS
runtest -x cts/tests/camera/src/android/hardware/cts/
Change-Id: I9a8cc8ffcc28b6b476904c3c011ab0ec65b162c9
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)
Do not guard against mismatching usage flag and data space for
IMPLEMENTATION_DEFINED formats, so that different formats can share
the same stream if HAL support is available.
Test: Camera CTS
Bug: 33777818
Change-Id: I62a1f458c06ae417c9a2c407d433319a1158fdcc
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
- Register and handle camera provider deaths
- Check for transport errors on all provider calls
- Clean up provider callback locking
Test: No camera CTS regressions
Bug: 35096594
Bug: 35441122
Change-Id: I08117f38f5201368a28093debdbcae67a68a4e7
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
Some interactions between camera service and hwservicemanager require
multiple threads to execute without deadlocks, such as calling
getService() from within an onRegistered() callback.
Increase thread count to 3 to accomodate.
Also switch the order of listener registration and legacy provider
addition back to what it was originally.
Test: No deadlock when camera service is restarted
Bug: 35096594
Change-Id: I6def961d5765958fef284c0a1820e903abc851ef
- 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
The current sequence of registering for provider notifications
and trying to add a legacy provider could introduce a race
condition leading to a deadlock. The "onRegistration" callback
will try to acquire "mInterfaceMutex" which is still held during
the execution of "addProvider" for legacy. However "addProvider"
could get suspended waiting on the HIDL provider interface. If this
happens and the same thread that unblocks the service query tries
to notify the provider manager, then we will end up in a deadlock.
To avoid this, the initialization sequence can be modified a bit.
First add the legacy provider and then register for notifications.
Bug: 35096594
Test: Manual using stop/start of cameraserver
Change-Id: Ia381ae6bf567525cabd3f51246a192ddac37b7f8
A lot of media makefiles didn’t specify libui or
libgui but included headers from these libraries
directly.
It works because these headers are on the global
include path. With this change, though, rect.h
is not anymore (albeit exported from libui).
Test: built and booted device
Bug: 35164655
Change-Id: I72e8f0b7bd25c6a67eedc17afe52c4c484a147fe
If the application calls finalizeOutputConfiguration without adding new
surface, as long as there is at least one surface in the
OutputConfiguration, do not throw exception.
Add logic to not allow finalizeOutputConfigurations twice on a
particular stream.
Test: testDeferredSurfaces cts and GoogleCameraApp manual test.
Bug: 35137641
Change-Id: I96061231e9b884e73c92520e7f2c021db32fa731