Hi!
We are currently encountering crashes on iOS devices only, 3% of our players encountering it.
It appears that this issue is tied to a specific state: 100% of devices are in background state. Most of crashes are on iOS 18+, near 10% are iOS 16+
The FMOD version is 2.02.19
Thank you in advance!
Unfortunately, I was not able to reproduce the issue with a simple test of back-grounding a Unity app. Was there any more information about what your users where doing while the app was in the background? Changing output device, locking or unlocking and maybe another form of interruption?.
I am not sure of the exact cause of the crash currently.
What is the current behavior of the app when being backgrounded?
If we add debug logs to the callback are you able to see those?
#if (UNITY_IOS || UNITY_TVOS) && !UNITY_EDITOR
[AOT.MonoPInvokeCallback(typeof(Action<bool>))]
private static void HandleInterrupt(bool began)
{
if (Instance.studioSystem.isValid())
{
// Strings bank is always loaded
if (Instance.loadedBanks.Count > 1)
PauseAllEvents(began);
Debug.Log($"In the callback entering background={began}");
if (began)
{
Instance.coreSystem.mixerSuspend();
}
else
{
Instance.coreSystem.mixerResume();
}
}
}
In the callback entering background=True
FMODUnity.RuntimeManager:HandleInterrupt(Boolean)
In the callback entering background=False
FMODUnity.RuntimeManager:HandleInterrupt(Boolean)
This should be handled by FMOD for you without any changes being made to the settings.
If we add debug logs to the callback are you able to see those?
I did the same, and there is no log there. I mean it, the private static void HandleInterrupt(bool began) would just not be called
I made a workaround with unity’s Application.focusChanged += NewFuntionInRuntimeManager and mixerSuspend() / mixerResume() are called now. But it’s a bit ugly
There have been some fixed in recent versions for detecting if the app focus has been changed. Would it be possible to test updating the integration to check if it is correctly logging when entering the background?
Sorry for the long absence, but we were preparing a release update and were hoping to see encouraging results in solving this bug.
Let me remind you what we did to try to fix it:
Updated to version 2.29
Installed our own handler for suspension
Also updated the Unity version minutely
Result: ANR is still there. It’s again “iOS only” and “100% in background state”
Maybe you have some new ideas?
Is it possible the ANR is being falsely flagged by the FMOD system suspending? Have you had reports specifically from users or only from crash software which may be misinterpreting what is happening with FMOD? What is the crash software you are using? With the updates are there any additional logs that you are able to share?
Thank you for assisting in investigating the issue
Have you had reports specifically from users or only from crash software which may be misinterpreting what is happening with FMOD
There is an opinion that this can happen when the application is unloaded from memory by swiping, and a system error message appears at the moment
However, it was not possible to reproduce it within the framework of the bug investigation
Ensure there are no calls to the FMOD system post mixerSuspend()
Remove mixerSuspend() from the HandleInterrupt() or where it may be called in your own suspension handling and relying on the PauseAllEvents()
#if (UNITY_IOS || UNITY_TVOS || UNITY_VISIONOS) && !UNITY_EDITOR
[AOT.MonoPInvokeCallback(typeof(Action<bool>))]
private static void HandleInterrupt(bool began)
{
if (Instance.studioSystem.isValid())
{
// Strings bank is always loaded
if (Instance.loadedBanks.Count > 1)
PauseAllEvents(began);
// if (began)
// {
// Instance.coreSystem.mixerSuspend();
// }
// else
// {
// Instance.coreSystem.mixerResume();
// }
}
}
Note we will lose the performance benefits of mixer suspend, but this should remove the risk of the dead lock being caused.
There also has been a new suspend_resume example added to the iOS API examples which may have some useful information: 'FMOD Programmers API/api/core/examples/suspend_resume.cpp'
