I’m building an internet radio out of an old phone.
Everything works OK the first time, but on Andriod when I quit the application and then start it again, it won’t.
It doesn’t even show the “build with unity” splash.
When I remove the FMOD part, it starts OK the second time.
Running multiple times in the Unity Editor works fine.
Is there something I should “release” on Application Quit?
Other than what I’m doing now? (I tried with and with an explicit CoreSystem.release(), result is the same)
void OnApplicationQuit()
{
// App is being quit - ensure complete cleanup
StopStream();
#if !UNITY_EDITOR
UnityEngine.Debug.Log("FMOD CoreSystem.release()");
RuntimeManager.CoreSystem.release();
#endif
}
Could you please share the FMOD Unity integration version you’re using?
When using the FMOD Unity integration, you shouldn’t need to manually call CoreSystem.release(). The integration manages FMOD’s lifetime, and OnApplicationQuit isn’t always reliable on Android.
Would it be possible to share a Logcat snippet from the second launch?
Hi @li_fmod, Im experiencing exactly the same issue. If I quit the app, it looks like it does quit, and yet the logcat doesnt say it has ever been terminated. There are no error or crash messages coming from the app when quitting. Only “Force Quit” option actually kills the app
The second launch doesn’t have any logs, because the first launch is still active, and it wont launch the activity.
Looking at the profiler in the Android Studio, the process is sleeping, but there are a few active threads running, which most probably dont let the app finally quit, namely - FMOD Studio Update, Studio Socket and Studio.Heartbeat
Is there a way to make FMOD completelly terminate during OnDestroy (if OnApplicationQuit is unreliable)? What’s the proper way to handle termination?
Could you share the exact FMOD Unity integration version? I couldn’t reproduce this issue on 2.03.09.
You generally don’t need to terminate FMOD manually, since when the app closes, Unity calls RuntimeManager.OnDestroy(), which shuts FMOD down in the correct order.
No. The FMOD Unity integration releases only what was actually initialized. If a subsystem was never created, there’s nothing to release.
Even if you don’t use any events/banks, accessing FMODUnity.RuntimeManager.CoreSystem can initialize the RuntimeManager, which in turn creates both the Studio system and the Core system.
Unfortunately, I couldn’t find anything in the log that directly explains the second launch hang,
and I wasn’t able to reproduce on my end with Unity 6000.2.6f2 + FMOD 2.03.09.
Would it be possible to share the project or a minimal repro so I can take a closer look? You can upload it to your profile.
To reproduce my hang you would need one of the newly announced AndroidXR devices, which we are are currently targeting and have a devkit. And the hang seems to be more pronounced on older firmware versions, but it does still happen on the latest.
I havent tried it on a normal android phone, but I suspect the issue to be tied specifically to the new platform. So considering that both OnDestroy and OnApplicationQuit are getting called, which i checked in logcat, so RuntimeManager’s OnDestroy is assumingly does what it should to release everything, what else can I do to force terminate all threads?
The cause of the hang for me seems to be this warning:
[FMOD] EventInstance::flushReleaseQueue : Event instance has programmer sounds pending release, update thread will be blocked until programmer sounds are released.
and it seems to be coming out of the studioSystem.release() call in RuntimeManager.OnDestroy(). It also never comes back out of it, so it just holds the main thread forever. OnDestroy, similarly to OnApplicationQuit doesnt happen reliably, so it explains why the app only hangs sometimes
The “nice/convenient” thing is that my app has two modes.
One acting as the player, streaming the internet radio.
One acting as the remote, controlling the player.
Same app, same firmware, same Android version, same FMOD assets, except the player mode actually uses the FMOD streaming api and the remote mode doesn’t, the app only initializes FMOD when it needs to play a stream for the first time.
When stopping/restarting in player mode it is hanging on both my phones on second start. When in remote control mode it doesn’t hang.
I see the same behaviour on my newer Android 14 phone as on my older Android 8 phone.
Just trying to give all information I have and think might be usefull.
In the Unity Player while making some changes, so after changing code in Visual Studio, switching back to Unity, Unity Editor tries to reload scripts etc., so it probably needs to rebuild:
Yes, RuntimeManager.OnDestroy() already handles the normal FMOD shutdown sequence. There isn’t a supported way to force terminate all threads as far as I’m aware, but you could try calling Studio::System::flushCommands before Unity quits, to let pending destroy callbacks run.
That warning is expected if an event is stopped or released while it still has programmer sounds waiting to be destroyed.
It doesn’t necessarily mean the system is stuck. It just indicates FMOD is waiting for those programmer sounds to finish releasing.
There’s a good explanation of this behavior in this forum thread:
Thank you for sharing the additional context and logs!
It looks like the FMOD system is being closed or released while it’s still suspended, and the Live Update socket thread hasn’t been fully shut down yet.
This might explain why the “player” mode hangs on the second start as the previous FMOD system hasn’t fully exited before Unity starts initializing a new one.
A few things you can try:
Call System::mixerResume before shutdown to make sure FMOD isn’t still suspended when closing.
Disable Live Update in your player build, since the socket listener on port 9264 can stay active if the system didn’t close cleanly.
Yes, the order does matter. If the system is released while suspended or with active streams, FMOD threads may remain running and block the next initialization.
My FMOD Default = Unity Platform build setting already had Live Update disabled. Just to be sure, I also disabled it in the Editor profile, although I asume that is/was not used.
Then I added the system.mixerResume() in my streamer class OnApplicationQuit(), which also didn’t seem to have any effect.
Like you say “looks like it’s still suspended”, I/we don’t have any influence on the order Unity is pausing/destroing/quitting stuff, so neither do I.
I installed your APK on both Android 8 and Android 14 test devices on my side, but unfortunately I wasn’t able to reproduce the second-launch hang so far. The app starts, quits, and relaunches without getting stuck.
On Android, OnApplicationQuit() isn’t guaranteed to run, so OnApplicationPause(true) is generally the more reliable place to stop streams and release programmer sounds.
It won’t force-kill FMOD threads, but it gives the system a better chance to shut down cleanly before Unity tears down the activity. You could try moving your FMOD shutdown logic into OnApplicationPause(true) to see if it makes any difference on your devices.
I don’t know if it is because I changed some stuff around createSound (that now has MODE.CREATESTREAM | MODE.NONBLOCKING) and an mpeg FMOD.CREATESOUNDEXINFO
or something else.
The app on Github didn’t have these changes when you reported you couldn’t reproduce.
I removed the NONBLOCKING again to test and then it hung once ( not 9 out of 10), but only when I restarted quite quick after stopping, so I will accept that that could be some background thread not yet finished releasing stuff.
I will keep monitoring, because I still don’t have a definitive cause/solution
