audioflinger: send priority request from a thread
When creating a fast AudioTrack, a request is sent to SchedulingPolicyService
to elevate the requesting thread priority. This generates a binder
call into system_server process and to a JAVA service via JNI.
If the thread from which the track was created is in the system_server
process and does not have the "can call java" attribute, a crash occurs because
the binder optimization reuses the same thread to process the returning binder
call and no JNI env is present.
The fix consists in sending the priority change request from the AudioFlinger
mixer thread, not from the binder thread.
This also reverts the workaround in commit 73431968
Bug 7126707.
Change-Id: I3347adf71ffbb56ed8436506d4357eab693078a3
diff --git a/media/libmedia/AudioTrack.cpp b/media/libmedia/AudioTrack.cpp
index d9d8aee..362d022 100644
--- a/media/libmedia/AudioTrack.cpp
+++ b/media/libmedia/AudioTrack.cpp
@@ -279,8 +279,7 @@
mCbf = cbf;
if (cbf != NULL) {
- //FIXME ignoring threadCanCallJava to work around track recreation issue
- mAudioTrackThread = new AudioTrackThread(*this, true /*threadCanCallJava*/);
+ mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava);
mAudioTrackThread->run("AudioTrack", ANDROID_PRIORITY_AUDIO, 0 /*stack*/);
}