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>
We can never be sure whether ~AImageReader() has run to completion or
not in AImage::close(). So we move clean up to another AImageReader
method and make sure that's called when in AImageReader_delete. AImage
now contains an sp<> to AImageReader so we can be sure that its members
wouldn't have been destroyed by ~AImageReader and we can check whether
AImageReader_delete has been called on it.
This also prevents us from deadlocking since AImage_delete could also cause
~AImageReader to run with AImageReader::mLock held in AImage::close().
Bug: 137571625
Bug: 137694217
Test: enroll; auth
Test: cts native AImageReader, camera, graphics tests
Merged-In: If5803cb6fcb6f4800032069872daaeac1cd36ed2
Change-Id: If5803cb6fcb6f4800032069872daaeac1cd36ed2
(cherry picked from commit 9e0302fcc1)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
The following sequence of events is possible:
t1: FrameListener::onFrameAvailable callback is called, mReader is
promoted from wp<> to sp<>, t1 holds mLock.
t2: AImageReader_delete is called, decStrong is called on AImageReader,
but since its refcount isn't 0, ~AImageReader isn't called
t1: onFrameAvailable completes, ~AImageReader is called with mLock
held, ~AImageReader->
setImageListenerLocked->FrameListener::setImageListener->tries
to lock mLock again, t1 deadlocks.
We move the locking mLock to after the promotion of mReader to sp<> so
that it gets destructed before ~AImageReader is called.
The same is done for BufferRemovedListener.
Bug: 136193631
Test: Auth; unlock
Merged-In: I8bb8c7d59f3711fd9fe434159095938eb5db9153
Change-Id: I8bb8c7d59f3711fd9fe434159095938eb5db9153
(cherry picked from commit ebca5b9862)
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Do not consider Assistant capturing with HOTWORD source
when determining lastest active capture client. As assistant
capturing for HOTWORD does not silence other captures, it should not
prevent another client from being selected as the latest active.
Bug: 135806801
Test: Start capture with Recorder app, place in background and trigger
false OK G detection
Change-Id: Ic17bfd70675ef749d6a678d067112b1dbd205746
Merged-In: Ic17bfd70675ef749d6a678d067112b1dbd205746
* changes:
Use PassthruPatchRecord for DIRECT to DIRECT connections
Add PassthruPatchRecord for low latency software patches
Abstract access to HAL stream via Source in RecordThread
Move PlaybackThread::Track::writeFrames to PatchRecord
audioflinger: Add tracing of buffer frames to PatchTrack/Record
libaudioprocessing: Extract vendor-available part of AudioMixer
AudioMixer: Cleanups
libaudioprocessing: Trivial dependency cleanups
When both input and output connected by a software patch
are in 'DIRECT' mode (no framework processing), use
PassthruPatchRecord as it helps to reduce the latency
significantly by avoiding intermediate buffering.
Remove 'std::nothrow' from tracks creation in PatchPanel
for consistency with other code.
Bug: 117564323
Test: with MSD module
Merged-In: I52ec5b02a207548ebc4073c1033e396f444c041c
Change-Id: I52ec5b02a207548ebc4073c1033e396f444c041c
Implement a subclass of PatchRecord that uses PatchTrack's
thread for reading from HAL. This eliminates the need for
buffering that adds latency.
The only modification needed for PatchTrack is to indicate
unlimited amount of available frames to the playback thread.
This is to prevent PatchTrack from being deactivated by
DirectOutputThread due to lack of frames available.
RecordThread believes it reads audio data on its thread,
and manages timestamps as usual. The data that it "reads"
and passes to PassthruPatchRecord is discarded by the latter.
Bug: 117564323
Test: with MSD module
Merged-In: I376656e3c791e91e2196331ecdf2b425697c4e18
Change-Id: I376656e3c791e91e2196331ecdf2b425697c4e18
This allows to replace direct reading from HAL with obtaining
audio data from another source.
It should be possible to encapsulate reading from FastCapture
in the same manner, but it's not required for direct inputs.
Test: make
Merged-In: I3f005583410cc9c5d4b07c127d95e236abb4a85f
Change-Id: I3f005583410cc9c5d4b07c127d95e236abb4a85f
This code logically belongs to PatchRecord because it emulates
obtaining recorded data from a client.
Test: make
Merged-In: Icba4e33d9d0ca57e6ad964aaf3209e7db766f284
Change-Id: Icba4e33d9d0ca57e6ad964aaf3209e7db766f284
Seeing requested / obtained buffer frame counts in trace
helps to identify discontinuities in software patch pipeline.
There is no need to trace requested frame count for PatchRecord
as it always requests as much as possible ("-1" frameCount).
Bug: 117564323
Test: with software patch active,
external/chromium-trace/systrace.py audio
Merged-In: I78400f6cc1d1940b3290fb23bb1aacfbffe042e5
Change-Id: I78400f6cc1d1940b3290fb23bb1aacfbffe042e5
Split AudioMixer into the base part which doesn't rely on
the framework and can be used in vendor code and the derived part
which is intended to be used by Audioflinger.
Test: A/B compare output from test scripts, manual testing on the phone
Merged-In: I24c390f67f20baa8109902099359ca6e34eebcfd
Change-Id: I24c390f67f20baa8109902099359ca6e34eebcfd
- Remove unused dependencies on libnbaio and libnblog;
- Move dependencies on libaudiohal and libsonic to libaudioprocessing
as AudioMixer implementation does not use them.
Test: make
Merged-In: I258a450725bdacb4fcf437b6f86582d51d40e622
Change-Id: I258a450725bdacb4fcf437b6f86582d51d40e622
Since AudioParameter.h is vendor-available, some vendors may
still use the old parameters. Leave the old parameters there
but mark as deprecated.
Bug: 138868195
Test: make
Change-Id: I6d12b7ac360309014a240a321c3cd32b39d8f740
Merged-In: I6d12b7ac360309014a240a321c3cd32b39d8f740
During the transition to Treble, "device connect" / "disconnect"
parameter was erroneously attributed to audio streams. This
issue got fixed in Audio HAL V4.0, but AudioParameter file
was still using incorrect name for the constant.
Test: make
Change-Id: I4056ad9e98af6dadd017d22bc4bde031cac75631
Merged-In: I4056ad9e98af6dadd017d22bc4bde031cac75631
This is obviously a typo.
Found by Clang tautological-constant-out-of-range-compare warning.
Test: presubmit
Bug: 72331526
Change-Id: I2cb217282c524bb9fbae899fa5a731b7575e393a
Add AUDIO_OUTPUT_FLAG_MMAP_NOIRQ flag in the relavant flags to check
for if the relavant profiles are present or not
Bug: 136493985
Test: make
authored-by: Samyak Jain <samyjain@codeaurora.org>
Change-Id: I8b8b9fdfca2bb6e5f824f3b79ac42b7de5545706
Merged-In: I8b8b9fdfca2bb6e5f824f3b79ac42b7de5545706
The error must not be ignored as otherwise the Java layer
thinks that recording has started successfully.
Bug: 136279123
Test: reproduce AudioRecordingConfigurationTest failure on cuttlefish,
check test failure output, the failure must be
"junit.framework.AssertionFailedError: expected:<3> but was:<1>"
Change-Id: I82bc3a43bf679cfb03d4246d07615d3fd4dac409
Merged-In: I82bc3a43bf679cfb03d4246d07615d3fd4dac409
When copy/paste folders from PC (e.g. windows),
there's an extra white space at the end of the folder names.
It cause the mkdir call failed with *Invalid argument* on device.
bug: 139645636
Change-Id: I4f0c017fd086b87180ba014722cdcf4d988e8bc5
The deprecated method AudioManager.isBluetoothA2dpOn() calls
getDeviceConnectionState on APM with an empty address, which
caused HwModuleCollection::getDeviceDescriptor to set an empty
address on the DeviceDescriptor for the currently connected
A2DP device. This method is called by MediaRouter.
When the address was reset, the java listener for audio device
connection monitoring was reporting the connection of an A2DP
device with an empty address, which in turn caused AvrcpManager
to behave as if the audio device connection failed.
If MediaRouter called isBluetoothA2dpOn() before AvrcpManager
received its called for device connection, the error would occur.
Bug: 132416679
Test: call isBluetoothA2dpOn() and check for valid address in dumpsys media.audio_policy
Test: atest AudioServiceHostTest#testInjectForRecord ; atest AudioHostTest ; atest AudioPlaybackCaptureTest
Change-Id: I1370edbbca46657506a990855d06a176f07c54d3
Merged-In: I1370edbbca46657506a990855d06a176f07c54d3
Jayant Chowdhary
Treehugger Robot
Eric Laurent
Marco Nelissen
Mikhail Naganov
Jean-Michel Trivi
Yi Kong
Aniket Kumar Lata
Dean Wheatley
Christopher Ferris
nolyn.lu
Colin Cross