
My conclusion is that the hands-free devices is inteded to be used when there's a two-way audio communication happening, but otherwise, use the main playback device. By having one application play audio from one playback device and another application playing from the other, the hands-free device also disables the main device.Attempting to capture audio from the bluetooth microphone (which is also labeled "hands-free") disables the main playback device, but not the hands-free playback device.


The reason why the A2DP device gets disabled when two-way communications is required is probably again related to processing power requirements. HSP has remained the minimalist implementation, to be used when every milliwatt-second of battery capacity needs to be used efficiently, and as a fallback to be used if the more advanced protocols aren't compatible. Since then, HFP has been expanded with optional better-quality sound codecs, as newer high-efficiency processors have made it easier to implement more complicated protocols and sound codecs in low-power devices. This was important for wireless Bluetooth hands-free devices, which usually had, and still have, an extremely limited amount of battery power available because of limitations of physical size.

Both of them, and in particular the HSP profile, are designed to minimize the processing power requirements. Both of them are older than A2DP, and were initially designed to pass telephone-quality sound (2-directional mono sound, limited frequency response, optimized for speech only). The "Hands-free" device corresponds, respectively, to either the "Hands-Free Profile" (HFP) or "Headset Profile" (HSP). It is optimized for transferring 2-channel stereo sound with good quality in one direction only. The "Stereo" device is technically known in Bluetooth jargon as "Advanced Audio Distribution Profile", or with an acronym A2DP.
