* changes:
cameraserver: Avoiding deadlocks while calling isPublicallyHiddenSecureCamera().
Do not include hidden secure cameras in camera1: getNumberOfCameras
During testHeicExif, the codec output buffer timestamp may rarely arrive
after the first codec output tiles arrive.
Test: vendor testing
Bug: 141169323
Change-Id: Iba1c82b087533cb87a32d69f7d6908e2c925b807
During reprocess usecases, the Camera HAL may return JPEG Appsegment
frames out of order. This leads to a scenario where
mAppSegmentConsumer->lockNextBuffer may not refer to the currently muxed
frame.
To work around this, the number of lockable appsegment buffers has been
increased.
Test: Vendor testing
Bug: 141169323
Change-Id: Ia498f6ddaba588b66cbaeee94fe8bdd7314bb90c
In order for muxer to start writing any track, the format returned from
onFormatChanged must first be available. By waiting for first output
tile callback, we are guaranteed to have received onFormatChanged, which
means a valid format is available for muxer to use.
This change also makes it such that no multiple muxers are inflight, avoiding
dequeueBuffer failure because right now we only support maximum dequeued
buffer count to be 1.
Add more verbose logs for ease of debugging.
Test: Vendor testing
Bug: 141169323
Change-Id: I16fd11f5558e525ceae59df00533553e4b4e7589
The following scenario can occur:
T1 serving Client A's disconnect() call:
T2 : serving Client B's connect() call
T2 : CameraProviderManager::openSession() locks mInterfaceMutex and waits on open() HAL
interface call
T1: updateStatus() locks mStatusListenerMutex
T1: CameraProviderManager::isPublicallyHiddenSecureCamera() waits
on mInterfaceMutex
T2: while waiting on open(), gets a torchModeStatus() callback from the camera HAL
T2: onStatusChanged()
T2: broadcastTorchModeStatus() which waits on mStatusListenerMutex
As a result there's a possible circular hold and wait between T1 and T2.
We cache isPublicallyHiddenSecureCamera in CameraState. That doesn't completely
avoid having to hold mInterfaceLock while calling isPublicallyHiddenSecureCamera() in CameraService
(cache updates), instead it reduces it. We instead need to hold mCameraStates lock which has a
smaller scope.
Bug: 141756275
Test: CTS
Test: GCA (sanity)
Merged-In: I4a697c1eaccc3603007be4a595febea981fbeb64
Change-Id: Ie5508afb126a874f76fbbfc2dd19ef79ae6255e0
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Apps cannot connect to hidden secure cameras. Do not include them in the
number of cameras reported by camera1 api.
Bug: 141247926
Test: Without CL -> mark all cameras as hidden secure cameras;
atest FastBasicsTest.java#testCamera1 fails
With CL -> mark all cameras as hidden secure cameras;
atest FastBasicsTest.java#testCamera1 passes
Test: camera CTS
Merged-In: I9d1721fd5e94fa7f692c3da52aa667ae9247d368
Change-Id: I229a336bed6b2695e16c1457cb8f74c26b07f7e8
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit cf93540965)
When initially starting up, use tryGetService instead of getService to
avoid blocking camera service start in cases where the camera HAL is stuck.
Test: atest cameraservice_test && atest CameraManagerTest, with and without
lazy camera HAL
Change-Id: I2ad5c542e77e748902cfb49f90a55620b29ad4cd
The following scenario can occur:
T1 serving Client A's disconnect() call:
T2 : serving Client B's connect() call
T2 : CameraProviderManager::openSession() locks mInterfaceMutex and waits on open() HAL
interface call
T1: updateStatus() locks mStatusListenerMutex
T1: CameraProviderManager::isPublicallyHiddenSecureCamera() / getSystemCameraKind() waits
on mInterfaceMutex
T2: while waiting on open(), gets a torchModeStatus() callback from the camera HAL
T2: onStatusChanged()
T2: broadcastTorchModeStatus() which waits on mStatusListenerMutex
As a result there's a possible circular hold and wait between T1 and T2.
We cache the system camera kind in CameraState. That doesn't completely
avoid having to hold mInterfaceLock while calling getSystemCameraKind in
CameraService (cache updates), instead it reduces it. We instead need to
hold mCameraStates lock which has a smaller scope.
Bug: 141756275
Test: CTS
Test: GCA (sanity)
Change-Id: I4a697c1eaccc3603007be4a595febea981fbeb64
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
The depth jpeg result and image timestamps must always match.
Set the depth jpeg output surface timestamp accordingly before
returning the resulting output buffer.
Bug: 142011420
Test: atest
cts/tests/camera/src/android/hardware/camera2/cts/StillCaptureTest.java#testDynamicDepthCapture
Change-Id: I2d70367d3cc60014d24cc138e4ca882b2111e161
Make a copy of output format in NDK and camera's heic encoder.
(MediaCodec.java JNI is already making a copy, so copy out of
MediaCodec.cpp to avoid unnecessary dup)
bug:141140020
Change-Id: I8afb1e48b73f0fb2fa584bdee2b93985b48a5e91
(cherry picked from commit 860eff192e)
The cameraservice is only registered to service manager after onFirstRef
is returned. To reduce the probability of getBinderService() call
returning null, move pingCameraServiceProxy to end of onFirstRef().
Also add debug messages in onFirstRef and main() for better diagnoses.
Test: Camera CTS
Bug: 140414594
Change-Id: I52defd1c138ade57ebc5181c42aff30921fbeaeb
Apps cannot connect to hidden secure cameras. Do not include them in the
number of cameras reported by camera1 api.
Bug: 141247926
Test: Without CL -> mark all cameras as hidden secure cameras;
atest FastBasicsTest.java#testCamera1 fails
With CL -> mark all cameras as hidden secure cameras;
atest FastBasicsTest.java#testCamera1 passes
Test: camera CTS
Merged-In: I9d1721fd5e94fa7f692c3da52aa667ae9247d368
Change-Id: I229a336bed6b2695e16c1457cb8f74c26b07f7e8
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
In camera1 api
- getNumberOfCameras won't count hidden secure cameras.
- getNumberOfCameras will return public non system cameras or public
cameras depending on whether the client has SYSTEM_CAMERA and CAMERA
permissions or not.
- getCameraInfo checks for SYSTEM_CAMERA and CAMERA permissions in case
the info is requested for a system camera.
Bug: 140243224
Test: Harcode all cameras as SYSTEM_ONLY_CAMERA; cts camera1 tests
get 0 on calling getNumberOfCameras() without using
adoptShellPermissionIdentity().
Test: Harcode all cameras as SYSTEM_ONLY_CAMERA; cts camera1 tests
get a finite number on calling getNumberOfCameras() when
adoptShellPermissionIdentity() is used.
Test: Harcode all cameras as HIDDEN_CAMERA; cts camera1 tests
get 0 when calling getNumberOfCameras.
Change-Id: I9d1721fd5e94fa7f692c3da52aa667ae9247d368
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Make a copy of output format in NDK and camera's heic encoder.
(MediaCodec.java JNI is already making a copy, so copy out of
MediaCodec.cpp to avoid unnecessary dup)
bug:141140020
Change-Id: I8afb1e48b73f0fb2fa584bdee2b93985b48a5e91
This change renames the IMemory raw pointer accessors to
unsecure*() to make it apparent to coders and code reviewers
that the returned buffer may potentially be shared with
untrusted processes, who may, after the fact, attempt to
read and/or modify the contents. This may lead to hard to
find security bugs and hopefully the rename makes it harder
to forget.
The change also attempts to fix all the callsites to make
everything build correctly, but in the processes, wherever the
callsite code was not obviously secure, I added a TODO requesting
the owners to either document why it's secure or to change the
code. Apologies in advance to the owners if there are some false
positives here - I don't have enough context to reason about all
the different callsites.
Test: Completely syntactic change. Made sure code still builds.
Change-Id: I5fb99aa797c488406083178a6b05355d98710d3b
Application may first call ImageWriter.queueInputImage without sending any capture
request before reconfiguring capture session using the same ImageWriter.
In this case, the stale buffers still exist in the buffer qeueue, and
ImageWriter.queueInputImage may stuck at waiting for free slots in the
new capture session.
Clear up all such queued buffers in the input buffer queue during stream
reconfiguration.
Test: Run testMandatoryReprocessConfigurations 300 times
Test: testQueueImageWithoutRequest
Bug: 138729150
Change-Id: Ie102dd018983bbd972f7c647d8c86c976a44e754
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I6cc85a91afb603e31b85090917f9f3b59d82a4d1
Camera preview stop only waits until the
current capture request is sent to Hal and
then immediately flushes the device.
Depending on timing and the pending request
queue size within CameraHal the current camera
client parameters may get flushed before
they are able to reach the end of the
processing pipeline.
Avoid this by waiting for the current request
id to appear in the incoming results.
Bug: 139330668
Test: Camera CTS, manual using application
Change-Id: I18de85557e8e76bfbe6d69b1eb2a5c36ed64e803
Use onBuffersDiscarded callback from buffer queue to invalidate the
buffer caches in cameraserver process.
Test: Run testDiscardFreeBuffers, and use trace to profile memory
Bug: 136677409
Change-Id: Ifac5e852e2a1ac50f5c3f2e047966c59eeb5f1ba
Only set FRAME_RATE to grid counts in case grid is used. In case grid is
not used (for example, in HEIC encoder case), set it to a predefined
value.
Test: Vendor testing
Bug: 140249376
Change-Id: I6b32bd435aa38f05004710ba667807ca841e4a5e
The previous logic was wrong(!) where DATASPACE_UNKNOWN shouldn't be
used as an initializtion condition.
Test: CTS and vendor testing
Bug: 139820060
Change-Id: I6b59d40ff796d48fe1804b45c189004f1ecc8c18
Bug: 133508924
Bug: 138135733
android.permission.CAMERA and android.permission.SYSTEM_CAMERA are both
required by a client process to access system only cameras.
Test: Advertise the back camera as system only;
1) don't give Camera2 SYSTEM_CAMERA permissions,
Camera2 can't connect to the back camera
2) give Camera2 SYSTEM_CAMERA permissions, Camera2 successfully
connects.
3) 3P app can't connect to any camera if all cameras are
advertised as SYSTEM_ONLY_CAMERAs.
Test: CTS CameraDeviceTest, CameraManagerTest
Change-Id: I0309462f962d9c8c92564ef6781b2aae1485a933
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
The HAL is allowed to notify RESULT_ERROR for physical sub-cameras.
Fix the condition check to allow absent physical metadata in such case.
Test: Partner testing and camera CTS
Bug: 138727686
Change-Id: I411a64d6fec2e06bc60a82fade65a02caab0ceca
Also remove the expected argument in addProviderLocked method as
we now can query from device manifest for instance names.
Test: manually modify Pixel3 manifest to test, CTS
Bug: 136010319
Merged-In: Ib57fd84ad8f22aac2a82920e03148cff2592daae
Change-Id: Ib57fd84ad8f22aac2a82920e03148cff2592daae
Replace the item MIME type with value supported
by the dynamic depth specification.
Bug: 138399780
Test: runtest -x
cts/tests/camera/src/android/hardware/camera2/cts/ImageReaderTest.java
-m testDynamicDepth
Change-Id: Ib51dd69e6de7da3269eccfa6b671fe95a269b4d6
This is to reduce application confusion when switching between back and
front cameras.
Test: Observe dumpsys on a phone with NIR camera device
Bug: 133141567
Change-Id: I0c11b99fc3a0304d54562548d109df8c56ba1db1
unlinkToDeath is no longer required, (this change in behavior is to
avoid leaks) so holding onto ActivityManager here (still calling
unlinkToDeath to avoid a log, but may for instance remove all
unlinkToDeath calls in the future).
Exempt-From-Owner-Approval: approval received on AOSP CL, only
whitespace difference here.
Bug: 134576445
Test: boot
Change-Id: I273f77aac2b80ba9be70197cc3842f83a11bbd1c
Original logic was comparing an overridden format int, switch
to use a const original format.
Test: partner device, Pixel 3 CTS
Bug: 136456900
Change-Id: I03d6e190770ee05e40446c417e323f546fdc2689
Also remove the expected argument in addProviderLocked method as
we now can query from device manifest for instance names.
Test: manually modify Pixel3 manifest to test, CTS
Bug: 136010319
Change-Id: Ib57fd84ad8f22aac2a82920e03148cff2592daae
By checking the expected duration for all inflight requests to
finish and only log when it takes more than a threshold (5 secs)
to process all inflight requests and the list is long.
Test: manual testing
Bug: 135927862
Change-Id: Iaa2c593f1e69f63b1da7d35d73c696de3510cd2c
Make sure 'jpeg_destroy_compress()' is always called
before leaving 'encodeGrayscaleJpeg()'.
Additionally fix misspelling of 'intrinsic'.
Bug: 135622974
Test: atest
cts/tests/camera/src/android/hardware/camera2/cts/StillCaptureTest.java#testDynamicDepth
--generate-baseline=12
Change-Id: I55c1f86881ba05aac6aac6981df5fcb276c9d4da
With the new dataSpace/format override logic, during
finishConfiguration, we shouldn't check mDataSpaceOverride flag anymore
because now mDataSpaceOverride will be true for reconfigure.
Instead, we should check if the new override is the same as old
override.
Test: testPrepare on HAL device with dataSpace override
Bug: 134800141
Change-Id: I1ddc258100dfd7e3c2cc86f9e476d8d52c710e3f
Since vendor native clients don't have package names, appOps reporting
would be inaccurate for them. In order to avoid that, we stop appOps
reporting for vendor clients.
Bug: 132718220
Test: AImageReaderVendorTest, use hal client for cameraserver, GCA(sanity)
Change-Id: Ie6f80e8ab530aa755df57f8d25d9f1a15a20d7f7
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Starting from HAL device version 3.5, the format and dataSpace for
IMPLEMENTATION_DEFINED pixel format uses original instead of overridden
values.
This makes HAL interface behavior consistent in that HAL doesn't need to
distinguish between first-time configureStreams and subsequent
reconfigure.
Test: Camera CTS and partner testing
Bug: 131864007
Change-Id: Ie5fdc7e9b6c11c1c96a069262b9458455855bcef
This patch fixes several issues:
* Change the timing the acquire fence FD is closed: we used to
close the FD when the buffer is returned from HAL. This patch
changes that to after the request is sent to HAL (or failed
to send to HAL)
* Cleanup inflight buffer map if the request fails to be sent to
HAL
* With the CL, the acquire fence FDs are now closed by
- HalInterface::processBatchCaptureRequests if the HIDL
processCaptureRequests call succeeds and HAL is running
in binderized mode (for passthrough mode the FD is owned
by HAL if the HIDL call succeeds)
- Camera3Device::cleanupFailedRequests otherwise
Test: Camera CTS tests
Bug: 132594861
Change-Id: I5f67ae9e7b8008738bd9a24246d754a6a3669b0c
We no longer have code path running non-HIDL interface.
This cleanup also simplifies some logic needed for fixing
b/132594861
Bug: 132594861
Test: Camera CTS
Change-Id: If15ea359a1a59c5a8e7a59818ce4db8120000bc4
Depth samples with low confidence can skew the
near/far values and impact the range inverse coding.
Avoid using such samples when searching for the near
and far points and clamp their values if necessary.
Bug: 132248813
Test: Camera CTS
Change-Id: I7dc134b50e46c664f9fc8750b9b9b37c416c9afe
Add below logical camera support to dumpsys:
- Physical camera id to stream info.
- Physical camera request/result metadata.
- Physical camera metadata in tag monitor.
Also fixed an issue of missing vendor tags in physical metadata.
Test: Run physical streams and observe dumpsys
Bug: 111940580
Change-Id: I02889b213ff5e7ec29506c0483ef40de9d107ccb
Override the oom_adj scores of vendor clients from to PERCEPTIBLE_APP_ADJ.
Override the process state of vendor clients to to PROCESS_STATE_PERSISTENT_UI.
This is in order for app processes to take priority over vendor clients.
For example, this could help in the case of the default camera app and
face auth contending for resources from the lock screen.
Bug: 132117718
Test: manual test on lockscreen, try to double press and open camera app
while a vendor client is connected to a contending camera device.
Change-Id: Ie5fabb59c876cb02eb706f3dda8f748c69e3c063
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
HAL ZSL request may be out-of-order compared to normal/reprocess
requests. Allow such case to improve shot lantecy.
Test: Camera CTS, 3P camera app sanity test.
Bug: 120604717
Change-Id: Id994efbe392094cdae694afaa2d159bc9c49d5f0
Also fix a issue for finishConfiguration is unintentionally
delayed till first capture request.
Test: Camera CTS + partner device testing
Bug: 126390310
Change-Id: Ibca740a7160cbf41e01884dbcef8ba51eb4c75f7
The clear function of vector will release memory,
so mBins will use overflow.
Test: enable asan for cameraserver
Bug: 131103281
Change-Id: Iaaa353332d7ac3992f018aa667fb8ef20a810f20
Signed-off-by: zhangshuxiao <zhangshuxiao@xiaomi.com>
- RAW capability can exist for multi-camera even if physical cameras are
of different sizes/capabilities.
- FOV for all processes streams must be the same regardless of logical
or physical streams.
- All metadata tags related to pixelArray/preCorrectionActiveArray/activeArray
needs to be mapped properly by the camera HAL.
- Do distortion correction mapping for physical subcamera as well.
Test: Build and read docs, camera CTS, ITS.
Bug: 118906351
Bug: 126220135
Change-Id: I29a61fc3a603561c1d74dc2261600ce4cd3d34cd
These things are ceaseless: /
code reviews, design docs - /
off-by-one errors making a mess
Test: atest CtsCameraTestCases
Bug: 129561652
Change-Id: I807d7ad4740ffe267053fe5da2080f9ecb45aa72
To improve camera launch performance, cache the proxy service
interface. System tracing indicates fetching the interface can take
up to 8-10 ms during real camera opens, which is a percent or two
of total camera startup time.
Test: atest CameraCtsTestCases
Bug: 130173970
Change-Id: Icdf5218b04f608b897dcbf2085f971b04a913f3b
For Camera1-HAL3 shim, the camera ID filtering logic is revised to
handle case of multiple logical cameras facing the same direction,
and are backed by same/different set of physical camera IDs.
Example 1 (all facing back):
ID1 = ID3 + ID4
ID2 = ID5 + ID6
Example 2 (all facing back):
ID5 = ID1 + ID2
ID6 = ID3 + ID4
In both examples, only ID1 will be advertised to camera1 app.
Test: Check cameras on devices with multiple logical cameras
Test: Camera CTS
Bug: 113705942
Change-Id: I76f370938b3311bbe7adcac8eddf8b6cf08e4571
1. Change Camera3Device logs to ALOGV
2. In Camera3OutputStream, only log before we mark stream state
to STATE_ABANDONED
3. Also changed BUFFER_ERROR log to ALOGV
Test: manually check log of GCA mode switch
Bug: 125415787
Change-Id: Ibd83b7010932a8be25d85573d9c9dce9c394f6bb
The physical camera device ID must be present as part
of the capture result extras in case of corresponding
result failure notification.
Bug: 128835627
Test: Camera CTS,
AImageReaderVendorTest
--gtest_filter=AImageReaderVendorTest.LogicalCameraPhysicalStream
Change-Id: I042af8bd85eaadd389b059c2833f352ceb2f40fc
Bug: 120407707
Test: CTS
Test: Use camera to take pictures / record videos (sanity)
Change-Id: I7b29c337d0e217d2eb6a62e2c75ccc550d795e61
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Additionally initializey the stream id to invalid negative
value in case the Hal tries to verify it during stream
combination queries.
Bug: 128450197
Test: Camera CTS
Change-Id: Ife058e22ef72ee84be82799ed397ca49cd8ea99f
Lazy loading of sound files can speed up camera startup more than 60ms,
it gives users a great experience. Many apps do not playSound when camera
open or they may use their own audio files. so we load audio files as needed.
Bug: 128432959
Test: install wechat app,open camera,use systrace to see the uiThread wait time.
Change-Id: I3b3697cf9d0d919b88276f6d8e7fdd84578f4fcd
Fix the long (>1s) dequeueBuffer call when a stream is managed by
Camera3BufferManager and its consumer end discards free buffers.
Test: CTS, no more long dequeBuffer call in GCA mode switch
Bug: 126054873
Change-Id: I03d6526b076796bb44f15cc2c4a092ff3d04fc1d
Camera service listeners must be able to receive
information about camera access permission changes.
Bug: 121379978
Test: Camera CTS
Change-Id: I2e13fdd35a267901a3caa0e0ce78ab1cea83e7ab
Return buffers managed by HAL buffer manager in disconnect.
Test: kill HAL process and check for buffer leak in cameraserver
Bug: 126889012
Change-Id: I83173c5eaae13ee11eb3f185e7204a2dd8855b4e
Set bufferSize in @3.4::Stream::bufferSize for JPEG_APP_SEGMENTS stream.
Bug: 124999074
Test: Build
Change-Id: I6f24f4273b0d3d18b1bdbf263fc12ed48e857004
Bug: 125464062
Test: GCA (sanity)
Test: Connect to a camera device using a HAL process, change the device user and connect again;
connection is successful
Change-Id: Ia25b961baa396fd383d089e400c6d877b9875955
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Use libyuv's optimized CopyRow function to improve performance of YUV
tiling.
Bug: 124781199
Test: Camera CTS
Test: TestingCamera2 smoke test
Change-Id: I6af6678099655b7e35ddaccf7cd9aa817ec64a9c
Depth and confidence maps require physical rotation in
case the source color image has similar physical rotation.
The EXIF orientation value will be kept consistent and
set to 0 in case of physical rotation.
Bug: 123699590
Test: Manual using application,
adb shell /data/nativetest64/cameraservice_test/cameraservice_test
--gtest_filter=DepthProcessorTest.*
Change-Id: I5cdd41c89368a1841d53f2195790aa1b55258495
Depth and confidence maps should always use the same
EXIF orientation as the main color image.
Bug: 123699590
Test: Manual using application,
Camera CTS,
adb shell /data/nativetest64/cameraservice_test/cameraservice_test
--gtest_filter=DepthProcessorTest.*
Change-Id: I0d887798e8717cdff81aba10d595dc3ccfe99197
In case the Camera3Device enters a bad state, the
RequestThread can continue to run after disconnect()
completes. This can potentially cause instabilities
because some of the Camera3Device member variables
will become invalid after disconnect() but are still
accessible in code paths triggered by RequestThread.
Avoid using potentially invalid reference by checking
the respective strong pointer.
Bug: 123293729
Test: Manual using application,
Camera CTS
Change-Id: If3305840db89537593370b7f57bccbb257e49cbd
Use static and dynamic metadata to override Exif tags.
Also added back a missing ATRACE_ASYNC_ENDs statement.
Test: Camera CTS
Test: ERROR_BUFFER of internal streams is propagated to app
Test: ERROR_RESULT only results in EXIF not being overridden
Bug: 124066183
Change-Id: Id2c69c6bee04ae724ff5f190b2dd96d0159700c9