Android AudioManager.setMode（MODE_NORMAL）失败

Question

I have 2 VoIP apps I'm developing that need to work together; one is a softphone app (App A) that uses various audio modes as expected ie RINGTONE, IN_COMMUNICATION, etc. The other app (App B) needs audio mode NORMAL. I try to make sure they play nice with each other so when softphone App A completes a call, it returns the audio mode to NORMAL. Likewise, if App B needs to operate in the middle of something App A may be doing, it saves the audio mode it found and restores that when complete.

For example, for an inbound call, App A might change audio modes like so:

1. MODE_RINGTONE when call comes in
2. MODE_IN_COMMUNICATION when call is connected
3. MODE_NORMAL after call is terminated

If App B needs to do something while a call is connected (step 2 above) it will

1. save MODE_IN_COMMUNICATION
2. set MODE_NORMAL
3. do what it needs to do
4. restore MODE_IN_COMMUNICAITON

Both apps get the Android AudioManager using their application context.

The problem I have, and that I don't understand, is that once App B goes through the above steps, App A fails in its attempt to return the audio mode to NORMAL after the call is terminated.

myAudioManagerReference.setMode(AudioManager.MODE_NORMAL);
if (myAudioManagerReference.getMode() != AudioManager.MODE_NORMAL)
  Log.w(CLASSTAG, "failure to set audio mode to MODE_NORMAL);

Is it possible for my App B to have some sort of lock on the AudioManager mode? Or to have changed the permissions for App A such that it cannot change mode back to NORMAL? I have found that once I exit from App B, then App A can successfully change the mode to NORMAL.

Answer 1

This looks like it MAY very well be a firmware issue. I'm seeing suspicious logs from the ALSA driver on this device (an industrial mobile device) that looks like the driver could be using the wrong PID at times to make audio mode changes. I've also NOT been able to recreate the same problem on any other device, including some from the same manufacturer.

Unfortunately, I don't yet have confirmation from the manufacturer (and ALSA driver writer) that this is the case.