Received termination request from [osservice<com.apple.dasd>:76] on <RBSProcessPredicate <RBSProcessHandlePredicateImpl| app<com.myapp.bundleid() with context <RBSTerminateContext| explanation:BG Kill Demo

Question

Created Jul ’24

Replies 3

Boosts 0

Participants 2

App getting terminated as the app enters background state. No crash logs are generated. I have collected this log from Console(Mac app)by connecting iPhone and sending my app to background.

There is no meaningful reason or code I can get from the logs. Can you please help me with what does 'explanation:BG Kill Demo ' means ?

My app is a VoIP app. App depends on voip apns notifications to receive information about new Voip calls from server.

I am posting the logs collected from console app here.

default 14:29:55.265590-0400 audiomxd -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Sending stop command to com.myapp.bundleid with pid '2933' because client is background suspended and there is no AirPlay video session for it default 14:29:55.265753-0400 dasd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.265908-0400 locationd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.265994-0400 locationd {"msg":"invoking applicationStateChange handler", "StateChangeData":"{\n BKSApplicationStateAppIsFrontmost = 0;\n BKSApplicationStateExtensionKey = 0;\n SBApplicationStateDisplayIDKey = "com.myapp.bundleid";\n SBApplicationStateKey = 2;\n SBApplicationStateProcessIDKey = 2933;\n SBMostElevatedStateForProcessID = 2;\n}"} default 14:29:55.266083-0400 locationd {"msg":"Post Application State Change Notification", "notification":"BackgroundTaskSuspended", "pid":2933, "bundleId":"com.myapp.bundleid"} default 14:29:55.267019-0400 locationd {"msg":"#CLIUA AppMonitor notification", "notification":"BackgroundTaskSuspended", "pid":2933, "bundleId":"com.myapp.bundleid", "ClientKey":"icom.myapp.bundleid:"} default 14:29:55.267061-0400 locationd {"msg":"skip erasing #CLIUA for RunningBoard Process State. Does not exists", "bundleId":"com.myapp.bundleid"} default 14:29:55.267678-0400 watchdogd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.267765-0400 useractivityd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.267934-0400 symptomsd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.267982-0400 wifid Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.268228-0400 UserEventAgent Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.268275-0400 callservicesd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.268338-0400 WirelessRadioManagerd Received state update for 2933 (app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>, running-suspended-NotVisible default 14:29:55.269217-0400 runningboardd Acquiring assertion targeting [app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933] from originator [osservice<com.apple.dasd>:76] with description <RBSAssertionDescriptor| "DAS: Application is docked." ID:33-76-44901 target:2933 attributes:[ <RBSDomainAttribute| domain:"com.apple.dasd" name:"DockApp" sourceEnvironment:"(null)"> ]> default 14:29:55.269572-0400 runningboardd Assertion 33-76-44901 (target:[app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933]) will be created as active default 14:29:55.270431-0400 runningboardd [app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933] Set jetsam priority to 30 [0] flag[1] default 14:29:55.270658-0400 runningboardd Calculated state for app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>: running-suspended (role: None) (endowments: (null)) default 14:29:55.273005-0400 runningboardd Received termination request from [osservice<com.apple.dasd>:76] on <RBSProcessPredicate <RBSProcessHandlePredicateImpl| app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933>> with context <RBSTerminateContext| explanation:BG Kill Demo reportType:None maxTerminationResistance:Interactive> default 14:29:55.274715-0400 runningboardd Executing termination request for: <RBSProcessPredicate <RBSProcessHandlePredicateImpl| app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933>> default 14:29:55.275034-0400 runningboardd [app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933] Terminating with context: <RBSTerminateContext| explanation:BG Kill Demo reportType:None maxTerminationResistance:Interactive> default 14:29:55.275122-0400 runningboardd [app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933] terminate_with_reason() success default 14:29:55.275768-0400 SpringBoard [app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933] Workspace connection invalidated. default 14:29:55.275790-0400 SpringBoard [app<com.myapp.bundleid(AD9F24FF-321B-48U6-895F-723CDA943372)>:2933] Now flagged as pending exit for reason: workspace client connection invalidated default 14:29:55.275815-0400 backboardd Connection removed: IOHIDEventSystemConnection uuid:C2525EA6-A052-480B-B83D-4BD62C29C6EC pid:2933 process:MyApp type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{ HighFrequency = 1; bundleID = "com.myapp.bundleid"; pid = 2933; } state:0x1 events:9 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE default 14:29:55.275988-0400 backboardd Removing client connection <BKHIDClientConnection: 0xd43cd1f40; IOHIDEventSystemConnectionRef: 0xd415d5800; vpid: 2933(v1C3E); taskPort: 0x84D8B; bundleID: com.myapp.bundleid> for client: IOHIDEventSystemConnection uuid:C2525EA6-A052-480B-B83D-4BD62C29C6EC pid:2933 process:MyApp type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{ HighFrequency = 1; bundleID = "com.myapp.bundleid"; pid = 2933; } state:0x1 events:9 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE source:HID default 14:29:55.288098-0400 runningboardd [app<com.myapp.bundleid(AD9F24F321B-48U6C7-895F-723CDA943372)>:2933] termination reported by launchd (15, 0, 9) default 14:29:55.289192-0400 runningboardd Removing process: [app<com.myapp.bundleid(AD9F24F321B-48U6C7-895F-723CDA943372)>:2933] default 14:29:55.289331-0400 runningboardd Removing launch job for: [app<com.myapp.bundleid(AD9F24F321B-48U6C7-895F-723CDA943372)>:2933] default 14:29:55.289582-0400 runningboardd Removed job for [app<com.myapp.bundleid(AD9F24F321B-48U6C7-895F-723CDA943372)>:2933] default 14:29:55.289706-0400 runningboardd Removing assertions for terminated process: [app<com.myapp.bundleid(AD9F24F321B-48U6C7-895F-723CDA943372)>:2933]

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’24

App getting terminated as the app enters background state. No crash logs are generated. I have collected this log from Console(Mac app)by connecting iPhone and sending my app to background.

My immediate concern here is actually this error:

default 14:29:55.265590-0400 audiomxd -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Sending stop command to com.myapp.bundleid with

What is your app actually doing when it entered the background? Do you have a CallKit call active? Does your app have the "audio" background category (as well as "voip"")? It should have both and I've seen leaving "audio" off cause some odd failures. Were you expecting your app to suspend or should it have stayed awake?

Having said that...

There is no meaningful reason or code I can get from the logs. Can you please help me with what does 'explanation:BG Kill Demo ' means ?

Take a look in side "Settings->Developer", then look for a setting called "Fast App Termination", which has this description:

Terminate instead of suspending apps when backgrounded to force apps to be relaunched when they are foregrounded.

I believe you'll find that setting is "On". When Xcode added that developer option, they implemented it by hooking into some existing functionality inside Duet. That's why the kill originate from Duet. The name "BG Kill Demo" just happened to be what they used as the termination reason, I think because they were using it to prove that state was working properly. FYI, this is also why you're not getting a crash log- this wasn't a "crash", it was an intentional termination used to test specific features/functionality.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

voip_ptt_dev OP

Jul ’24

What is your app actually doing when it entered the background? Do you have a CallKit call active? Does your app have the "audio" background category (as well as "voip"")? It should have both and I've seen leaving "audio" off cause some odd failures. Were you expecting your app to suspend or should it have stayed awake?

Yes, my app has ‘audio’, ‘voip’ background mode enabled. The app was not playing audio when the it was pushed to background. The expectation for the app in background is, app may or may not be awake. But when the app is supposed to join a voip call, app receives voip apns notification, which wakes up the app, app connects to our server to fetch audio and play it.

Note: The issue is happening only in a few devices, where we checked, ‘Fast App Termination’ is NOT enabled.

Another info I would like to give is, the app has ‘push to talk’ background mode also enabled. Need your thoughts an app supporting both ‘voip’ and ‘push-to-talk’ background mode enabled.

0

Answer 3

DTS Engineer OP

Apple

Jul ’24

The expectation for the app in background is, app may or may not be awake. But when the app is supposed to join a voip call, app receives voip apns notification, which wakes up the app, app connects to our server to fetch audio and play it.

Just to clarify here, having the "voip" background category does NOT mean that your app won't be terminated in the background. What the system promises is that when the system receives a voip push, that voip push will be delivered to your app. If your app is suspended in the background, then it will be woken up. If it isn't running at all, then the system will launch it into the background and deliver the push. Note that PushToTalk operates in EXACTLY the same way. In both cases, the system does NOT guarantee that your app will remain alive in the background.

Let me jump back to your original statement here:

App getting terminated as the app enters background state. No crash logs are generated. I have collected this log from Console(Mac app)by connecting iPhone and sending my app to background.

The behavior here is "interesting", in the sense that it's unusual and I don't have an immediate explanation for the behavior. HOWEVER, if this behavior is having ANY effect on your apps ability to function "normally", then that is a bug in your app that you need to correct. It is both normal and expected behavior for voip and PTT apps to be terminated in the background. Your app should expect that as part of it's normal usage flow and be able to handle it without issue.

On this point:

Note: The issue is happening only in a few devices, where we checked, ‘Fast App Termination’ is NOT enabled.

Expanding on my earlier answer, the "BG Kill Demo" termination is a testing/debug "hook" in the system that was specifically created to implement exactly the behavior you're seeing (basically, "terminate the app as soon as it suspend in the background so it's easy to test things like state restoration"). The setting I mentioned is the only clear trigger I found, but it's possible I've overlooked something. Regardless, the next step I'd take here is to focus on the device configuration itself, as I'm fairly sure that "something" has been missed. A few more things to look at:

Has this ever occurred on a device that does NOT have "Development" enabled?
If you disable development mode, does the problem still occur?

Another info I would like to give is, the app has ‘push to talk’ background mode also enabled. Need your thoughts an app supporting both ‘voip’ and ‘push-to-talk’ background mode enabled.

In terms of "basic" support, this should work fine. As far as the system is concerned, an active PTT communication (playback or transmission) is actually just a slightly different type of CallKit call, managed by callservicesd just like any other CallKit call. I don't recall exactly what happens when a CallKit call occurs in the middle of a transmission, but this was an issue the framework was designed to handle and the behavior should be "reasonable". Similarly, you'll need to decide what should happen when tranmission/calls collide in your own handling process, but you also have enough tools/options that you should be able to make it work the way you want.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0