nytimes/ios-360-videos

iOS 10 CoreAudio Crash

jaredsinclair opened this issue · 7 comments

STR

On a device running iOS 10 (must be an actual device, not the simulator), the following STR consistently lead to a crash:

  • Navigate the host application until a 360 video is visible.
  • Leaving the app in the foreground, lock the device with the lock button. Do not send the app to the background via the home button.
  • CRASH.
  • Unlock the device again and you'll be greeted by the iOS home screen because the application has exited prematurely.

Variations

This occurs whether or not the video is still playing or has been paused prior to the moment the lock button is pressed. It occurs whether or not the AVPlayer, its associated video node, or the entire SKScene have been paused.

Workaround

The only thing I have found that prevents the crash is to add background audio to the app's list of allowed background modes.

Crash Details

The crash is caused by an uncaught exception thrown by CoreAudio:

Terminating app due to uncaught exception 'com.apple.coreaudio.avfaudio', reason: 'error 561015905'

That error code maps to AVAudioSessionErrorCodeCannotStartPlaying:

This error type can occur if the app’s Information property list does not permit audio use, or if the app is in the background and using a category which does not allow background audio.

This crash does not affect standard videos, so my assumption is that there is something about SceneKit's usage of AVPlayer/CoreAudio which leads to the crash.

Resolution

I've exhausted everything I can think to try. I think we have four options:

  1. Petition Apple to address the issue with a radar, and hope for the best.
  2. Enable background audio, at least temporarily.
  3. 1 and 2.
  4. Do nothing and hope it goes away before iOS 10 GM.

Given those options, I think option 3 (ie. 1 and 2) is the right choice. We'll have to test aggressively whether the background audio change affects any of the app's current behavior around video playback.

We should also add a note to this repository's documentation, so future users of the library will be aware of this limitation (remember, we plan to OSS this repo).

Update To make matters worse, the background audio solution isn't deterministic. It only works in the newsreader application. It does not prevent the crash in the NYTVideo sample application. My guess is that there are race conditions in the newsreader (perhaps administrative tasks that are spawned when the app is resigning active) that alter the time window during which the bug occurs. This is pure conjecture. The point is that the background audio solution might not work for the newsreader app when compiler optimizations are enabled, or on all devices, or in all circumstances.

from the error docs:

or if the app is in the background and using a category which does not allow background audio.

is it possible that Newsreader does some mucking-about with our audio category that the example app doesn't? This might be worth checking into, @jaredsinclair.

Update September 15, 2016 - I've retested this using the GM release of iOS 10 and Xcode 8, and the issue appears to have been resolved on Apple's end.

Update September 19, 2016 – I was mistaken. This issue has not yet been resolved. I was testing incorrectly. The bug can only be reproduced by locking the device, not by sending the app to the background. The crash still occurs on iOS 10 GM.

Here's a link to a sample project that we can send to Apple along with a radar: https://www.dropbox.com/s/kxop5jdlyk9sch5/Core%20Audio%20Crash.zip?dl=0