For the API level, we may have an API like this setSpeakerOn(bool en) and isSpeakerOn The application switch case may be complicated because...with headphone pluged-in case and playback on speaker: 1. app A use content channel and playing on speaker, another app B use normal, should output on speaker or headphone? I prefer speaker. 2. app A use content/normal and playing on speaker, another app B use higher channel than before, like dialer, which output path do we want to have? receiver? speaker? *headphone? After ended the app B with higher channel, the audio sound can back output on speaker.
============== 3. Handle the application switch case, i.e one application want speaker on with headphone pluged-in, switch to another one, but there is no option for users to switch back to headphone. this object may need to tracking the application usage and recover it. If you have a speakerOn function I assume that you will also have a speakerOff function. Then in those app who wants to control the state of speaker, they should listen to 'visibilitychange' event to know the foreground/background state change(application switch you mean), and then according to that, enable or disable speaker. The only thing I wonder: there may exist one race condition, if App A is brought to background after App B is brought to foreground. When that happens, the speaker(I guess it's global?) will be disabled by App A when it gets notified it's now background after App A enables it. _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
