The application is placed into the idle state. Subsequently, the device enters a sleep state.
- While the device is in sleep, App start background task within the application successfully receives its expirationHandler callback.
- App received the expiration callback and App called the end BGtask
- OS did not released the Assertion.
- Resulting in App getting terminated by the OS for exceeding the BG task
Apple Feedback- FB19192371
App received the expiration callback and App called the end BGtask
So, [...] think there is [...] problem with your app background task management. Walking through the syslog:
Task expiration starts:
15:19:07.728092+0530 <app pid 1019>: [...] Firing background task expiration handlers
15:19:07.728099+0530 <app pid 1019>: [...] On backgroundTaskAssertionQueue, clearing shared assertion
First expiration handler called:
15:19:07.728270+0530 <app pid 1019>: [...] Calling expiration handler for task: <private>
This logging is internal to endBackgroundTask. The first message is DIRECTLY logged when endBackgroundTask starts and is always logged, even if the ID is invalid or reused.
15:19:07.737220+0530 <app pid 1019>: [...] Ending background task with UIBackgroundTaskIdentifier: 222
This logging is the actual process of ending that particular task ID:
15:19:07.737288+0530 <app pid 1019>: [...] Ending task with identifier 222 and description: <private>, _expireHandler: <__NSMallocBlock__: 0x1035a9d10>
15:19:07.737308+0530 <app pid 1019>: [...] Decrementing reference count for assertion <private> (used by background task with identifier 222: <private>)
Second expiration handler called:
15:19:07.738013+0530 <app pid 1019>: [...] Calling expiration handler for task: <private>
...but no logging from endBackgroundTask, indicating you didn't actually end any task.
Finally, this logging:
15:19:07.738083+0530 <app pid 1019>: [...] Background task still not ended after expiration handlers were called: <private>. This app will likely be terminated by the system. Call UIApplication.endBackgroundTask(_:) to avoid this.
...happens when all expiration handlers are called but the list of task ID is not empty (meaning, all tasks were not ended).
Your full logging is redacted; however, I also notice that there is a substantial difference in your own app logging of the first expiration (~20 messages) vs. the second expiration (none).
Ideally, the logging would include the task IDs for creation and expiration (r.158339658), but the data that is there would seem to indicate that you failed to properly end one of your tasks. Note that this is easy to do, with the most common error being:
IMPORTANT: Failing to end a background task is the number one cause of background task problems on iOS. This usually involves some easy-to-overlook error in bookkeeping that results in the app beginning a background task and not ending it. For example, you might have a property that stores your current background task identifier (of type UIBackgroundTaskIdentifier). If you accidentally create a second background task and store it in that property without calling endBackgroundTask on the identifier that’s currently stored there, the app will ‘leak’ a background task, something that will get it killed by the watchdog.
Finally, one comment on the bugs side:
Apple Feedback- FB19192371
There are certain APIs in the system that are so critical to the system’s normal operation that, in practical terms, they are EXTREMELY unlikely to have bugs. Critically, that's NOT because of any particular focus or extraordinary development effort, but simply because ANY "simple" failure has such devastating consequences that the bug simply cannot be "missed". I'd put this API in that category. It's such a critical part of every app and many daemons that even very low probability bugs would be extremely disruptive to the system.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
