-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDK causing app to crash when VOIP call received #404
Comments
Could you attach a crash log or along with the SDK verison? We could then symbolicate on our end to see whats crashing. Is your app using |
Thanks for your response, I have fetched a couple relevant crash files and can send them over via e-mail, what's a good e-mail address to contact you at? And we are using registerForTaskWithIdentifier, and we currently have "FinishLaunchingAtStartup" = TRUE on our IntuneMAMSettings plist at the time of the crash |
You could also just attach them here |
Thanks @gastaffo, I've emailed those crash files to you |
About the behavior that occurs when a user sets a pin protection requirement in the app protection policy, when a timeout period is set and that timeout period is exceeded, a pin check is required before the user can access the app. This timeout seems to also block other behavior (i.e. incoming VOIP calls). Within our app when the crash occurs, something is inhibiting some app lifecycle events on startup that prevent us from registering to PushKit. This only occurs when the pin protection requirement timeout has exceeded, and the pin check-in is required. This crash does not happen when a pin protection requirement is not enforced, or if the timeout set has not yet been exceeded. What exactly does the SDK do to the app to suppress this behavior that might be affecting our app lifecycle events? |
Hi @gastaffo, did you have an update regarding the crash logs/question for the scenario described above? Please let me know if there is anything I can provide that would expedite this, we have multiple customers experiencing this issue and would like to get to the root of this as soon as possible. |
Describe the bug:
We are seeing an issue where our app is crashing when VOIP calls are received. The app is crashing due to the
0xbaadca11
error code; the OS is terminating our app for failing to report a CallKit call in response to a PushKit notification (error description here).We only see this issue when the user enables a pin access requirement in their app protection policy, and sets a timeout (i.e. 5 minutes) before a pin check is required. If the user backgrounds or kills the app, and a time duration less than the timeout duration has passed, the issue/crash will not occur when a call is received. However, once the timeout is exceeded and a call is received, the app crashes due to the error described above.
It is my understanding that the SDK performs some action to suppress these calls when this pin access requirement is in place. But this SDK behavior seems to be interfering with our app lifecycle and preventing us from reporting these CallKit calls, resulting in the crash.
How exactly does the SDK suppress these calls, and how exactly are we expected to integrate with this suppression behavior to prevent OS app terminations due to
0xbaadca11
?To Reproduce
Steps to reproduce the behavior:
Expected behavior:
A clear and concise description of what you expected to happen:
Smartphone (please complete the following information):
Intune App SDK for iOS (please complete the following information):
What version of the Intune SDK are you using? Are you using the latest version? - We are using SDK version 18.0.1
What platform is your app based in (native, Xamarin based, Cordova, etc)?
For errors during build, does the app build without Intune SDK integration? - N/A
For errors post build, does the app launch without being Intune SDK integrated? - N/A
Who is the customer? - N/A
Do you see a trend with it only being reproduced on a specific device? - No, reproducible on all devices
Additional context:
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: