ensures that the @include'd policy files (code_coverage, crash_dump)
used by mainlined media processes are carried within the respective
APEX files. Parent policy files now @include the copy held within
the apex.
Bug: 147914640
Test: built/booted/examined filesystem
Change-Id: I34213fbc93ca51696b6a5a3c60bfd3ffa7ce6764
This was accidentally removed when converting MediaExtractorService
to AIDL, but is needed for large MediaBuffers
Bug: 147152626
Bug: 147835592
Test: CTS, manual test app
Change-Id: I403968efa4319f316aa2ba5c0d7db71a0781b883
This avoids unnecessary copying of camera metadata which can get
expensive in cases of large camera metadata blobs.
Bug: 71727540
Test: GCA (sanity)
Test: Add CallStack::logStack() in CameraMetadata's move asignment
operator -> see that it gets called for every insertResultLocked.
Change-Id: I6c75c7ce5267126916c865b028e5f7c7f50b763b
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
cameraserver should re-cache concurrent camera id combinations when it
receives cameraDeviceStatusChange callbacks from the camera provider in
case new concurrent camera id combinations have appeared / old ones have
gone away.
Bug: 148995918
Test: atest ConcurrentCameraTest.java
Change-Id: Ic433495d2dcf98d00cb247f434ad6c798ea17c54
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
The access to call audio (record and play) will be granted only to the app associated with Dialer role, who also includes a new system permission.
Test: Compilation and manual tests
Bug: 135197853
Change-Id: I65ca823c235d4d3420630837427103783ad1d1b0
This code has null checks with intervening unconditional dereferences of
the potentially-null variable.
It's not clear that `mOutput` can ever be null to begin with. If it can
be, we have a few dereferences to guard. :)
Caught by the static analyzer:
frameworks/av/services/audioflinger/Threads.cpp:2671:19: warning: Called
C++ object pointer is null [clang-analyzer-core.CallAndMessage]
frameworks/av/services/audioflinger/Threads.cpp:2852:9: warning: Called
C++ object pointer is null [clang-analyzer-core.CallAndMessage]
Bug: None
Test: TreeHugger
Change-Id: I456581204718390088998a1fe2514dff63f6578f
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
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>
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
In case of using Device Port Gain to control the volume, the logic
of setVolumeIndexForAttributes for device type check has been bypassed.
However, in case of unmuting, the volume will be applied to all streams
with requested device then will be set for AUDIO_DEVICE_OUT_DEFAULT_FOR_VOLUME
which is a convention used in case of no volume for device has been set
previously.
As this logic is bypassed, in case of HwGain, the final gain applied will
be the one for AUDIO_DEVICE_OUT_DEFAULT_FOR_VOLUME, which may be completely
different from the gain of current device.
This CL fixes this by factorizing the device check logic for both SW/HW gains.
Test: build & play music & Vol - until mute then volume +. No gap expected.
Change-Id: I24c57df84496e404c05c92f08f907131ef79cf3a
Signed-off-by: François Gaffie <francois.gaffie@renault.com>
When a volume curve is not found for a volume group
associated to a system strategy, use AUDIO_STREAM_PATCH
instead of AUDIO_STREAM_MUSIC as default config.
Bug:148588565
Test: play music and check volume
Change-Id: Ib3fb2a1b7b5f3118bf16a3cc9d8e578fa0431645
Merged-In: Ib3fb2a1b7b5f3118bf16a3cc9d8e578fa0431645
This CL fixes regression introduced in aosp/1213724
The regression happened when offloaded music is played, volume
is reduced, next song is requested then the volume is switching
to full scale.
It is linked to a "ghost volume source" without stream types that
is considered as a music stream before volume is set in AudioFlinger.
The music volume was overwritten by this volume source.
This CL fixes only the ghost volume source by preventing to add twice
the internal volumes sources linked to AUDIO_STREAM_PATCH and
AUDIO_STREAM_REROUTING.
The clean fix consists in aligning AudioFlinger on volume sources
rather than stream types.
Bug: 148588565
Test: plays offloaded music, reduce volume to min.
Then press next song.
No volume gap expected.
Change-Id: I0bb3b5ca1f13ba23351bcd658acf8d7f52555929
Merged-In: I0bb3b5ca1f13ba23351bcd658acf8d7f52555929
Signed-off-by: François Gaffie <francois.gaffie@renault.com>
The assistant new stream CL has broken the strategies without
stream types. The attributes are not populated anymore preventing
to retrieve the volume group from attributes.
Bug: 136121584
Test: run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioProductStrategyTest
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioVolumeGroupTest
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioVolumeGroupChangeHandlerTest
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testPermissionsForVolumePerAttributes
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testGetAndValidateProductStrategies
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testGetAndValidateVolumeGroups
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testSetGetVolumePerAttributesWithInvalidAttributes
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testSetGetVolumePerAttributes
run cts-dev -m CtsMediaTestCase --test android.media.cts.AudioManagerTest#testVolumeGroupCallback
Change-Id: I15a14e4cf85e6c4bbf09db24bb33b4b9fb9cab54
Merged-In: I15a14e4cf85e6c4bbf09db24bb33b4b9fb9cab54
Signed-off-by: François Gaffie <francois.gaffie@renault.com>
Communicate current audio mode owner UID to native service
when changing audio mode via setPhoneState.
This will be used by call audio capture restriction rules.
Bug: 148368476
Test: manual phone call tests
Change-Id: Icf6f168bb431b5232f6127877c40789c0c537bde
Due to security constraints, platform profilers that do remote stack
unwinding need the target process' cooperation. This is implemented via
a bionic signal handler.
On debug builds, media extractor can end up being targeted by such
system-wide profiling, which can crash the process due to
seccomp/minijail (specifically, due to sendmsg that is used for sending
file descriptors over a unix socket).
Tested: synced updated binary to crosshatch-userdebug, confirmed that
sending signal 36 with si_val 1 doesn't crash mediaextractor.
Bug: 149328505
Change-Id: Idf34e08edf99a82c72146aebeb5e46e5cf5af2f3
Jayant Chowdhary
Ray Essick
Marco Nelissen
Ricardo Correa
TreeHugger Robot
George Burgess IV
Eric Laurent
Edwin Wong
Automerger Merge Worker
Ryan Savitski
Nadav Bar
François Gaffie
Robert Shih
Andy Hung