libmediandk brings in many unneeded dependencies which results in
an abnormal increase in vss. AImageReader_getHGBPFromHandle has been
moved to libmediautils.
Test: mm -j64
Test: showmap <pid of cameraserver> vss before change: 50628
Test: showmap <pid of cameraserver> vss after change: 31256
Change-Id: I4de95d08ae514c252a1e01f3b03e0021c821b72a
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
using transaction id directly is not recommended
so remove permission check in onTransact() and add it into notifySystemEvent()
Bug: 119525871
Test: m -j
Change-Id: I0f2feb5204876fa9b56b9cdb096f25d2226025ec
Merged-In: I0f2feb5204876fa9b56b9cdb096f25d2226025ec
This is to handle lazy hal, where cameraserver doesn't know HAL goes
away.
Test: Observe that the between QS Torch Tile and Camera App is correct.
Bug: 79374634
Change-Id: I2f802b1c409ba3581f0fcacfc0ac5f6059391139
using transaction id directly is not recommended
so remove permission check in onTransact() and add it into notifySystemEvent()
Bug: 119525871
Test: m -j
Change-Id: I0f2feb5204876fa9b56b9cdb096f25d2226025ec
The old implementation only toggle idle when waitUnitlDrained
is explicitly called, but there are some cases where
application don't need to call waitUntilDrained but can still
expect the device goes into idle.
Test: CTS on Pixel3 equipped with webcam HAL
Bug: 109829698
Change-Id: I48c26abcc9c2f1263c2360611c935fc317745e59
Support runtime "SessionConfiguration" queries by camera
clients.
Bug: 111593096
Test: adb shell /data/nativetest64/camera_client_test/camera_client_test
--gtest_filter=CameraClientBinderTest.CheckBinderCameraDeviceUser,
Camera CTS
Change-Id: I1505e7bccdce468490b46ad4546e459354a4cda3
- Add dummy CFA pattern for monochrome camera.
- Handle monochrome camera in DngCreator.
- Fix up static and dynamic metadata tags related to monochrome camera
for older version of devices.
Test: Camera CTS
Test: Capture a DNG file and inspect with LightRoom
Bug: 70216652
Change-Id: I68d2b3d77b7f81bdc9e4129c2a8af10a4f18db3b
SignalPipelineDrain will be sent after the request
thread has stopped sending capture requests so
HAL can expect no more capture requests are sent
after they receive this call.
Test: CTS
Bug: 109829698
Change-Id: I6f75c28ff0998a8edc80f9af9ebe727c585ea6e9
mOutputStreams access used to be protected by mLock, but that has
changed due to:
- Treble interface switched from passing stream pointer to
stream index
- The buffer management API runs in HAL callback thread
Test: CTS
Bug: 109829698
Change-Id: I3561b197f46f07d2a15bb4f52b096f36c73a0407
For some resolutions input HeifWriter surfaces have much higher
acquired buffer count compared to the maximum Hal buffer for the
respective use case. From the tests so far shared streaming doesn't
seem to be affected by the imbalance and the splitter is able to
support this case.
Bug: 110161669
Test: Camera CTS
Change-Id: I129221b0f35e45c8b26f27f94910a6edda8d675b
In case HAL process crashes, addStates() should still send torch state
callback to the app if observer is registered.
Test: Kill HAL process and observe Flashlight icon in quicksettings
Test: Camera CTS
Bug: 117949686
Change-Id: Icee1891ef3993ebb0e7eed2dc281db8cd6106e84
Currently we always sync using the latest request id
before standard capture. The purpose is to avoid
sending triggers and 3A mode settings out of sync to
Hal. However during regular capture the precapture
trigger is not always used so we should be able to
skip the device sync in this case. This can enable
capture requests to arrive in Hal with one preview
frame earlier.
Bug: 79682338
Test: Camera CTS
Change-Id: I9ea0b03968266d5c8f1e187358f13a21d394ff90
In case the camera device supports ZSL, avoid dropping
preview buffers while video recording is active. Preview
must not get interrupted in this case.
Bug: 117640175
Test: Manual using application, Camera CTS
Change-Id: I9021b4c46428e008298ddef0a86972640b0afa41
Merged-In: I9021b4c46428e008298ddef0a86972640b0afa41
(cherry picked from commit 6c79c9aa7f)
The legacy camera shim layer currently uses various heuristics
in order to determine valid supported preview/video/snapshot
sizes and formats. This makes the code complex and in some
cases the result is not optimal in terms of power and
performance. If the camera supports recommended stream
configurations, then use the suggested stream
configurations to generate the above supported lists.
Bug: 64029608
Test: Camera CTS
Change-Id: I6ed1d50b3d1a854421f3d119be2e32211e8a4c35
The maximum acquired count of the input buffer queue during surface
sharing should be set considering the total maximum acquired count of
individual registered outputs and also the current acquired count
of the input buffer queue. The reason the two can be different is
due to the fact that individual outputs can acquire and also block
buffers from the input. The latter portion contains all buffers
which are still queued but not acquired. This can happen in case
some output acquires the maximum amount of buffers possible then
stops consuming entirely and the camera client continues to reference
it in subsequent capture requests.
To handle this, track the number of acquired buffers in the input
queue and expand (or contract) the maximum acquired count only if
possible. The maximum shouldn't change otherwise because the blocked
buffers could still be used by the unresponsive output at some
later point in time.
Bug: 117982710
Test: Camera CTS
Change-Id: Ia4e743efdf59cb0c9baaea492f78c37d0f2c95b3
In case the camera device supports ZSL, avoid dropping
preview buffers while video recording is active. Preview
must not get interrupted in this case.
Bug: 117640175
Test: Manual using application, Camera CTS
Change-Id: I9021b4c46428e008298ddef0a86972640b0afa41
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