The logic in IOProfile::devicesSupportEncodedFormats()
was only checking if the first device in the list of supported devices
was supporting currently selected A2DP encoding format.
But if more than one devices match the queried types, we need to check
all devices in case one of them supports the selected encoding format.
Bug: 147789166
Test: repro steps in the bug.
Change-Id: I704c5c6278eed524f15e7b73cec68a24f04d3a8c
SharedRefBase now encapsulates heap allocation in order to guard against
some types of double-ownership.
Bug: 149249948
Test: TH
Change-Id: Ida943c895225331a853e4c8da54454d60b17000a
Add meteric to show the difference between drm
playback of protected vs unprotected content.
We log onQueueInputBuffer errors.
Bug: 138862395
Test: adb shell dumpsys media.metrics | grep -i InputBuffer
Change-Id: I26aae706267956b6f944955877347747e573e3c8
Methods like reconfigureCamera called by the RequestThread internally
call methods which might expect to have mInterfaceLock locked
(eg: configureStreamsLocked).
Also, function calls which expect to be serialized w.r.t
reconfigureCamera can cause reported camera status to be inconsistent
w.r.t the expected status.
For example the following situation might occur
through CameraTest.java#testVideoSnapshot :
For certain video sizes that would fail to configure the camera
startRecordingL
camera reconfiguration is triggered -> reconfigureCamera() starts
waitUntilDrained -> gets interleaved with reconfigureCamera()
reconfigureCamera() completes
Here the status of the camera device is active instead of CONFIGURED.
updateRecording
createStream() called expects the camera to not be in an ACTIVE
state since updateProcessorStream cannot handle stream
configuration failure gracefully when the device is streaming.
However since waitUntilDrained did not complete after
reconfigureCamera the camera status is STATUS_ACTIVE.
As a result, we should hold mInterfaceMutex while
calling these methods. To avoid deadlocks (b/143513518), we can have the thread
calling disconnect, relinquish mInterfaceMutex right before it starts
waiting on RequestThread to exit. It can re-acquire it when
RequestThread finishes.
Bug: 147313521
Test: atest CameraTest.java#testVideoSnapshot on pixel2 passes
Test: camera CTS
Test: GCA (sanity)
Change-Id: I384f62bc9936d9691dfe9c13ff743e3d07f2ed55
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
am skip reason: Change-Id Id67dc9e793ee886e4cc49370d800c7f3580df313 with SHA-1 9c930d0cac is in history
Change-Id: I9495b79433ed85e141d8b413c0c86aba66513550
am skip reason: Change-Id Icdfe5a823ba02eb7bd8c41f0fa503c9922d8f348 with SHA-1 ea51ad6e1d is in history
Change-Id: I4b1aaa3714d99c12739fba8076318b151b2e629c
Make the list of keys in allowedKey to match the
statsd_handlers[] in iface_statsd.cpp for dumpsys
to display mediadrm and Widevine metrics.
Bug: 149246413
Test: adb shell dumpsys media.metrics | grep -i drm
Test: adb shell dumpsys media.metrics | grep -i widevine
Change-Id: I7811eb3a4228a906bb3dbc615ce42d1947082a07
This change fixes the CTS failure in AudioPlaybackCaptureTest caused
by ag/10111312 and ag/10111311.
It contains the following fixes/changes:
- Mix match for playback capture of USAGE_VOICE_COMMUNICATION now
also respects a new flag (AudioMix's mVoiceCommunicationCaptureAllowed)
which is set by AudioService only if the caller explicitly asked
to capture USAGE_VOICE_COMMUNICATION and have the
CAPTURE_VOICE_COMMUNICATION_OUTPUT.
- A permission check on the native side in case
mVoiceCommunicationCaptureAllowed is set.
- Code cleanup, mainly in AudioPolicy.h and AudioPolicy.cpp.
This change is accompanied by ag/10242955 on the Java side.
Bug: 148559127
Test: manual
Test: atest PlaybackCaptureTest (with the version prior to ag/10220852)
Test: atest com.google.android.gts.audio.AudioHostTest
Change-Id: I8ae6249f4da1de35e962c838d91f690eb906570e