audio flinger: handle race condition in AudioRecord creation
A rare race condition can cause a failure to create an AudioRecord if
two creation requests are processed concurrently and thread preemption happens
at a specific time within the sequence between audioflinger and
audio policy manager.
This CL implements a retry mechanism on client side when this particular failure
is detected.
Bug: 161656190
Test: Regression tests for audio capture use cases.
Test: CTS tests for AudiRecord
Change-Id: I155ee4899baeec21e10a1141cb9e323cbc8aa23b
(cherry picked from commit d52a28ca2c19db7d10bc6c4639a8bd78e1afd5f1)
diff --git a/services/audiopolicy/managerdefault/AudioPolicyManager.cpp b/services/audiopolicy/managerdefault/AudioPolicyManager.cpp
index c5c13e9..6522016 100644
--- a/services/audiopolicy/managerdefault/AudioPolicyManager.cpp
+++ b/services/audiopolicy/managerdefault/AudioPolicyManager.cpp
@@ -2256,7 +2256,7 @@
sp<AudioInputDescriptor> inputDesc = mInputs.getInputForClient(portId);
if (inputDesc == 0) {
ALOGW("%s no input for client %d", __FUNCTION__, portId);
- return BAD_VALUE;
+ return DEAD_OBJECT;
}
audio_io_handle_t input = inputDesc->mIoHandle;
sp<RecordClientDescriptor> client = inputDesc->getClient(portId);