Thank you for taking the time to report the following comment to the administrator of this site.
Please complete this short form and click the submit button to process your report.
As I understand it, Bluetooth profiles are implemented for all potential “users” and “actions”, thus we have profiles for file transfer, headsets, audio distribution, etc. (The profiles we provide are described in these docs.)
The profiles define the path from the Bluetooth daemon to the device’s hardware. In that sense, profiles would not have knowledge of the underlying radio capabilities---that would be the responsibility of the daemon. We require licensees to write their own Bluetooth hardware daemons in order to force them to handle all of the dependencies for whatever hardware they choose. Thus, I think the proper answer to this question is that the profiles we provide are built according to Bluez specs, and that the profile we provide does support a2dp. It is the daemon’s responsibility to cope if the hardware doesn’t support a2dp, perhaps by falling back to a lower audio quality transport method.
It occurs to me that you may be asking the question because you are working on software that depends on a2dp (audio distribution) and want to know what will happen if that feature does not exist on a given device. I think the logical thing to do in that case is to test
It is noteworthy that the underlying hardware is only one point at which a feature must be supported. In the case of a2dp, the headset must also be fully compliant with Bluetooth 2.0+edr. One other potential wrinkle is SCMS-T digital rights management, which precludes using a2dp (according to Wikipedia).
I hope this answers your question! If not, please let me know and I will research further.
