* changes:
camera2ndk: ~ACameraCaptureSession shouldn't hold device lock in ACameraDevice_close().
AImage: don't allow ~AImageReader to run before AImages are deleted.
AImageReader: make sure ~AImageReader isn't called with FrameListener::mLock held.
AImageReaderVendorTest: Tolerate failures for ACameraDevice_isSessionConfigurationSupported.
* changes:
cameraserver: Avoiding deadlocks while calling isPublicallyHiddenSecureCamera().
Do not include hidden secure cameras in camera1: getNumberOfCameras
AudioPlayer was only used by the commandline utilities, so move it
out of libstagefright.
Test: build, run
Change-Id: I561cccd323206de7415bd235b72711194080aaea
INIT_CHECK() expands to `if (foo) return bar;`, and `EventTimer`'s
destructor uses a value that's only set if `SetAttribute` is called.
This CL flips the INIT_CHECK/EventTimer lines to match getKeyRequest.
Caught by clang's static analyzer:
frameworks/av/include/media/EventMetric.h:155:7: warning: 2nd function
call argument is an uninitialized value
[clang-analyzer-core.CallAndMessage]
Bug: None
Test: TreeHugger
Change-Id: Ie0c4fb8c99a56082e234475e539c2ec4bc8fd948
JetPlayer.cpp was only used by the JetPlayer JNI code, so move
it to the same library.
Test: atest JetPlayerTest
Change-Id: I14b8241c5eb6c789ebc5d6725db716b9b0f8f31f
Merged-In: I14b8241c5eb6c789ebc5d6725db716b9b0f8f31f
Removing it doesn't have any effect on binary size, but makes it easier
to track dependencies.
Test: build
Change-Id: I0a792e48e781a73b920cb68c0daaa7920f08b8bf
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)
Name changes:
ClearFileSource -> FileSource
ClearMediaHTTP -> MediaHTTP
FileSource -> PlayerServiceFileSource
MediaHTTP -> PlayerServiceMediaHTTP
PlayerServiceXXX are able to handle OMA(forward-lock) files and now
moved to media/libmediaplayerservice/datasource since they only work
on mediaserver process.
Bug: 142567168
Test: build and DrmTest
Change-Id: I9292dba33d149efe17cf566017dcce1710cc8c88
MidiIoWrapper's DataSourceUnwrapper doesn't need to inherit from
DataSourceBase, and removing that inheritance saves a little bit
of space too.
Test: build
Change-Id: I9f560ef57b76b624cf323d75872395a39f65ed1f
This is preparation for having a subclass of DataSourceFactory which
is only used in mediaserver process with OMA (forward-lock) use case.
Test: build
Bug: 142567168
Change-Id: I2a1ab3d1ae89f657a84376d9a95d4e814b545b4f
We call disconnectLocked before stopping CameraDevice's looper, in order to avoid this situation:
1) Its possible that an OnResultReceived callback is received, and posts an
AMessage with sp<ACameraCaptureSession> on CameraDevice's looper.
2) Before the looper message is processsed, ACameraDevice_close() is
called by the client, which results in the looper being stopped and
cleared with device lock held.
3) When the looper is getting cleared, the AMessage containg the
ACameraCaptureSession pointer is destructed leading to
~ACameraCaptureSession running without knowing that the device is
being closed, as a result it tries to hold device lock, resulting in
a deadlock.
Bug: 141603005
Test: CTS native tests
Test: use camera2 vndk client for extended periods of time
Change-Id: Ia0d47fc2975981055cd1f2103c1cbe8d76642fe4
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
With VNDK APEX, the path to VNDK libs is changed from
/system/lib/vndk-VER to /apex/com.android.vndk.vVER/lib.
Bug: 141451661
Test: m && boot (tested with cuttlefish)
Change-Id: Id3a335ad1dfea71fb53ce80b96d550af8ac61760
There were three issues with the implementation
of Audio Playback Capture patches on secondary outputs.
1) Patch tracks were always forced to be ready, even if there were not
enough audio to be played. That led to playing partial buffers if the
source output had smaller (time wise) buffer than the secondary output.
This is fixed by avoiding setting CBLK_FORCEREADY on every buffer push
from the primary output thread.
2) After 1 is fixed, the patch tracks now behave like regular (non fast)
tracks. This means that the track only starts when it is full.
That leads to overrun on startup as the primary and secondary outputs
usually do not have the same write period.
What makes the issue worst is that Remote submix has a fixed buffer in bytes,
so its write period changes depending on sample rate contrary to the
primary HAL which pulls with fixed time periods (usually 20/40ms).
This patch solution is to introduce a ready threshold. The track will be
considered ready to be active if there are more than frames in its buffer.
To avoid changing previous latency behaviour except for APC,
legacy tracks have this threshold set to their buffer size and
non APC patch tracks have it set to 1, similar to setting
CBLK_FORCEREADY.
3) The patch track buffer size calculation of the patch track did not take
into account primary and secondary output could be of different sampling
rate.
This mean that the patch track buffer was usually too small as the
secondary output usually had smaller sampling rate (Live caption
requests 16kHz) than the track (music usually plays in 48kHz).
This made the two problems even worst.
This was easily fixed by scaling the buffer size with each side sample rate.
Bug: 136691300
Test: play audio
adb shell audiorecorder --target /data/file1.raw
# Check that the recorded file has no underrun
Change-Id: Ib2846b2827afd1b953d4a25acb18c7cadf57cd3e
Signed-off-by: Kevin Rocard <krocard@google.com>
As python 2 is beeing deprecated, this CL updates all the tool
scripts to python3.
It also fix some issues revealed by pylint.
Test: lunch audio_configurable target & build
Change-Id: I69a201190c688be3825cbdaa238046367a5d09c7
Signed-off-by: Francois Gaffie <francois.gaffie@renault.com>
If no default device is available from configuration.xml, and if
the engine fallbacks on it anyway, it tries to get its type without checking
the pointer validity.
This CL fix the potential segfault and assert with explicit error message.
Test: build
Change-Id: Icf8d7f5ef998dad6f4033d934b48d408030c7e17
Signed-off-by: François Gaffie <francois.gaffie@renault.com>
To avoid bypassing PATH restrictions, this CL fixes the python
binary dependancy by retrieving the path from the host binaries.
Test: build
Change-Id: Ib3356ee1a69d1a5e5a9f9d22b46e3e70c28fa991
Signed-off-by: François Gaffie <francois.gaffie@renault.com>
Dongwon Kang
Treehugger Robot
Jayant Chowdhary
Marco Nelissen
Yanqiang Fan
George Burgess IV
Manisha Jajoo
Ruchika Ashtankar
Ray Essick
Shivaansh Agrawal
Jooyung Han
Xin Li
Wonsik Kim
Eric Laurent
Kevin Rocard
Francois Gaffie