Alternative for getDevices() before API 23?

[SchmadenSchmuki]

I couldn't find any answers anywhere else on that question so why not ask the experts (feel free to close or delete this issue if it's too annoying).

I wanted to have something like in the aaudio-echo-example, two spinners that list the available in- and outputdevices on the phone. The echo-example uses AudioManagers getDevice() which is not available befor API 23 and I would like to support from API 16.
Is there any method to get information on the available audiodevices before API 23? I would need deviceIds an whether it's in- or outputdevice to set up the stream.

thanks

[dturner]

Sadly not.

You can infer some of this information by using methods like AudioManager.isBluetoothA2dpOn() to determine whether a bluetooth speaker/headphones are connected. You can also use AudioManager.setSpeakerphoneOn() to specifically target the built-in speaker.

[dturner]

Oh and not annoying at all - please ask away :)

[SchmadenSchmuki]

Thanks a lot for the information, saved me some time searching for something that can't be found.
I also think I can get a basic functionality with the mentioned methods which is good news.

[AlejandroHCruz]

Would Oboe handle reconfiguring the audio so it works properly over Bluetooth A2DP or do we have to handle that on our implementation? i.e. restarting the audio manager and getting new parameters such as the new sample rate from the speaker?

[dturner]

In future please open a new issue for a new question.

When Oboe is using AAudio (available on API 26+) it will choose the audio device's native sample rate automatically.

When Oboe is using OpenSL ES you'd need to handle this in your own implementation as by default Oboe will use 48kHz as the default sample rate, which may not be the native sample rate of the bluetooth device. You can query which API Oboe is using by calling AudioStream::getAudioApi().

The reason for this behaviour is that the AudioManager API is only available in Java so you'd need to pass the JNI environment to Oboe so it could query this API itself. Feel free to open a feature request for this as it is something we have discussed and would implement if there was sufficient developer interest.