Composite streams must be able to switch to offline processing
mode. To support them the offline session client must continue
passing all necessary callbacks and events similar to regular
camera clients.
Test: Camera CTS
Bug: 135142453
Change-Id: I498681af16ad072e3df01d0279b4cfe76b48f9ec
Integrate dynamic depth processing as part of
the camera service library.
Dynamic linking is no longer required as legacy
devices with small system partitions are not
supported.
Bug: 132449311
Test:
atest
cts/tests/camera/src/android/hardware/camera2/cts/StillCaptureTest.java#testDynamicDepthCapture
atest
cts/tests/camera/src/android/hardware/camera2/cts/ImageReaderTest.java#testDynamicDepth
atest
cts/tests/camera/src/android/hardware/camera2/cts/ExtendedCameraCharacteristicsTest.java#testDepthOutputCharacteristics
cameraservice_test --gtest_filter=DepthProcessorTest.*
Change-Id: Ie8befc5c0635e3e08c7ad8cac7b056cdf5aa3548
ZoomRatioMapper's member variables are const after construction. As a
result, we don't need mutex to protect updateCaptureRequest and
updateCaptureResult calls.
Also fixed missing zoom ratio mapping initialization for physical
sub-camera.
Test: testZoomRatio CTS
Bug: 130025314
Change-Id: Ibe2ff7cffb13178dcf70fc9e2eb044184e58bcf2
Update codec quality setting at the time of:
- Input pending frame creation if there is no inflight encoding.
- Any pending input frame is done processing.
Note that since there is no way for camera framework to synchronize
quality setting per-frame when encoder runs in surface mode, the update
of quality is on best-effort basis.
Test: vendor testing, and camera CTS
Bug: 140506016
Change-Id: I58ddc9302b1507428ccf42f4c77c6624f1c600ba
- Add NDK API spec for the new zoom API
The new zoom API combines optical and digital zoom, and supports both
zoom-out and zoom-in with more precision.
- Add new NDK API to specify separate zoom ratio ranges for different
bokeh modes.
- Add ZoomRatioMapper in camera service to convert between
control.zoomRation to and from scaler.cropRegion.
Test: Camera CTS/ITS/CtsVerifier/ZoomRatioTest
Bug: 130025314
Change-Id: I4c7d867f840b5720bc73bb0485e8a9a93d2276b5
Functions called by RequestThread::threadLoop must not hold
mInterfaceMutex since the following deadlock scenario may occur:
T1: disconnect() -> holds mInterfaceMutex and waits for RequestThread to
exit
T2: RequestThread::threadLoop()->reconfigureCamera (or any other function) that waits on
mInterfaceMutex
leading to a deadlock
Bug: 143513518
Test: GCA
Test: CTS
Change-Id: I4bd856e5263934a54cd7087a01d35cfe10936196
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
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
Bug: 145617243
Change-Id: Ifac5e852e2a1ac50f5c3f2e047966c59eeb5f1ba
Merged-In: Ifac5e852e2a1ac50f5c3f2e047966c59eeb5f1ba
(cherry picked from commit 0160ddd149)
Currently, we will set -1.0 as the default focal length for external
camera even if camera HAL provides the information. We should respect
the information if it is provided.
Bug: 141517606
Test: cts-tradefed run commandAndExit cts -m CtsCameraTestCases -t
android.hardware.cts.CameraTest#testJpegExif
Change-Id: Iae38ed0243a386187e29c5c4549d92ca24f58d0d
Explicitly signal and unblock the request thread
during device flushes via "mRequestSignal". This can
potentially reduce the time needed to go in to IDLE state.
Bug: 144978201
Test: Camera CTS
Change-Id: Ib212ca481a961252cf744af4b96f3c45865d121e
The internal buffer queue and respective 'mConsumer' may
never get initialized in case the connection and/or
configuration of client shared output surfaces fails.
To avoid possible instabilities check whether the
consumer interface is valid before trying to disconnect.
Bug: 143506890
Test: atest
cts/tests/camera/src/android/hardware/camera2/cts/MultiViewTest.java
Change-Id: Ia533233444fd548ddb52f4fde06212a21bc843bc
Merged-In: Ia533233444fd548ddb52f4fde06212a21bc843bc
Bug: 136595429
Test: atest CtsAppOpsTestCases (now including two new test cases that
open a camera with a null and a non-null feature)
Change-Id: Idfb8f8049dff536525d4f081151c79d980d76c69
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
Merged-In: Iba1c82b087533cb87a32d69f7d6908e2c925b807
(cherry picked from commit 5c103f2962)
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
Merged-In: Ia498f6ddaba588b66cbaeee94fe8bdd7314bb90c
(cherry picked from commit b5986a36b2)
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
Merged-In: I16fd11f5558e525ceae59df00533553e4b4e7589
(cherry picked from commit 3d00ee51a2)
Depending on timing, legacy camera clients that try to
disconnect may observe a random delay while waiting
for the capture sequencer thread to exit from its
respective 'threadLoop'. The delay there can be as much as
'kWaitDuration'.
To improve the average disconnect latency use a separate
and much smaller timeout when managing idle state.
Bug: 143557484
Test: atest cts/tests/camera/src/android/hardware/cts/
Change-Id: I164b3d37182cac776c0064047a5ef5b5a0f8b314
The internal buffer queue and respective 'mConsumer' may
never get initialized in case the connection and/or
configuration of client shared output surfaces fails.
To avoid possible instabilities check whether the
consumer interface is valid before trying to disconnect.
Bug: 143506890
Test: atest
cts/tests/camera/src/android/hardware/camera2/cts/MultiViewTest.java
Change-Id: Ia533233444fd548ddb52f4fde06212a21bc843bc
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: I8562c83478b1fe8fbda7c85f97b995985666918d
Merged-In: I4a697c1eaccc3603007be4a595febea981fbeb64
Change-Id: Ie5508afb126a874f76fbbfc2dd19ef79ae6255e0
(cherry picked from commit fd39db81e4)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
New test verifies that getService is not called during camera service
startup, to make sure it can't get stuck if the camera HAL isn't
initializing properly.
Test: New test passes with new tryGetService code; test fails with
older camera service code.
Change-Id: I67b3fe392e8cc6961c33abf25e961a8e2df7d7b5
"CameraDeviceClient" which keeps all references to active
composite streams may not get immediately destroyed after
client disconnect. This means that all registered output
surfaces in composite streams will continue to have
an active connection. In such scenario camera clients will
not be able to re-use the same surface as long as the older
instances are still alive.
Avoid this behavior by explicitly releasing all remaining
composite streams during "detachDevice". The method must
be called as part of the client disconnect and will
ensure that all surface connections are removed.
Bug: 143212133
Test: Camera CTS
Change-Id: I08710645539b687f046116a88576f05bbcbdbaff
* 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
Emilian Peev
Yin-Chia Yeh
Marco Nelissen
TreeHugger Robot
Wei Lee
Shuzhen Wang
Automerger Merge Worker
Jayant Chowdhary
Michael Gonzalez
Philip P. Moltmann
Hui Yu
Xin Li
Eino-Ville Talvala
Dongwon Kang
Chong Zhang
Ytai Ben-tsvi
Steven Moreland