Hi FMOD team,
We’re experiencing a frustrating Android audio issue and would appreciate your guidance.
Background:
We had a critical “0 input devices” bug on Android (especially Samsung/Xiaomi) where FMOD wouldn’t detect microphones on first launch—a restart would fix it, but this broke our game’s core functionality. We resolved it by forcing `FMOD.OUTPUTTYPE.OPENSL` on Android, which worked well.
Current Problem:
Recently, we’ve been seeing increasing `SIGSEGV` crashes in `libfmod.so` (`[split_config.arm64_v8a.apk!libfmod.so]`), driving our Android crash rate to unacceptable levels across multiple Android versions. Updating to the latest FMOD version didn’t help, and our implementation appears correct.
Our Hypothesis:
We suspect these crashes might be related to forcing `OUTPUTTYPE.OPENSL` on newer Android versions (13+), where OpenSL ES is deprecated/less stable.
Proposed Solution:
We’re considering conditionally using OpenSL only on Android 12 (SDK 32) and lower, letting newer versions use the default AAudio. However, we’re concerned the “0 input devices” bug will return on Android 13+ devices.
Questions:
1. Could forcing `OUTPUTTYPE.OPENSL` be causing these `SIGSEGV` crashes on newer Android versions?
2. Is there a better approach to handle the “0 input devices” issue without forcing OpenSL?
3. Any other suggestions we should try?
Honest Feedback:
Using FMOD in our Android+iOS Unity game has been challenging, from crashes to mic issues. As a small indie team, we’ve spent significant time troubleshooting audio instead of focusing on gameplay. 
If starting over, we’d likely consider default Unity audio or Wwise. That said, we’d prefer to make FMOD work if possible.
Thanks for any insights you can provide!
Sorry to hear you’ve been having so many issues with audio input on Android. What version of the FMOD Unity integration are you currently on? We’ve made some changes to AAudio device enumeration in the last few versions of FMOD, in particular this change in 2.03.08 sounds like it could potentially help with the “0 input devices” bug:
Core API - Android - All AAudio devices now enumerated regardless of whether specific devices permissions have been granted.
With that bug, if devices were enumerated before the user had a chance to grant the audio input permission (i.e, on first launch) then FMOD would report 0 input devices. With the new change we still try to get the device, but log a warning instead of aborting device enumeration altogether.
If you are able to repro the 0 input devices bug then I’d be interested in seeing if getting the latest FMOD integration helps at all.
Otherwise, if you can please tell me what version of the FMOD integration you are using, I can send you some android debug symbols so you can get a usable callstack from your crash reporter, and we can take a look at what’s going wrong there.
Hi Jeff, thank you for getting back to me on this.
It’s interesting you brought up 2.03.08 and the potential fix for the “0 input devices” issue; During the time we had this bug in the summer, we were actually still on 2.03.05 (until we updated to 2.03.09 in October) → so yes, it could be that this problem is now fixed and we can switch to AAudio without issues. I want to highlight though that we also tried resetting the audio pipeline after the permission was granted, with no success (seemed like only an app reboot could solve it); let’s see!
With the next release we are going to 2.03.10, and I will switch to AAudio for Android 13 and above. In your experience, does it make sense to stick with OpenSL for older devices?
Debug symbols would be appreciated 
@jeff_fmod on one of our test devices (Xiaomo Poco X6 5G, Android 15), with FMOD 2.03.10 and AAudio, we again have this issue that MIC input didn’t work the first time (no devices) and it requires one or more restarts apparently to get it to work
Thanks for giving that a shot- good to eliminate that as a factor at least.
I have uploaded the symbols for 2.03.10 to your FMOD Profile, can you please link them to your segfault and see if you can get a usable call stack?
Can you also please tick Enable API Error Logging, set your Logging Level to “Log”, and upload the output of your game’s log after getting 0 input devices?
Thank you Jeff, will try. I suppose I can use those symbols as well to find out more about the crashes we are getting on Android with OpenSL? Because I will revert back to always using OpenSL now, the 0 input devices bug is too severe to go back to that (was quite common); but of course unfortunately none of my test devices do that…
Yes, you should be able to upload the symbols to your crash reporter and get more meaningful call stacks for any new crashes that come along, which will hopefully shed more light on the libfmod.so crashes you are seeing.