The iOS CallKit end my call without user action.

By analysis the log, seems the following 3 calls has been ended by system callkit (Not mainly trigger the end call):

I'm not sure I follow the meaning of your log data. How do you know no user action was involved?

Both calls are ending ~1s after the report which is with the range of human action, particularly if some kind of hardware action like pushing the side button of the phone or blocking through a headset's physical button is involved.

@apple Do you have similar report that the iOS CallKit End the call withtour user action?

No, not that I'm aware of.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for your reply. But if the user taps any hardware to trigger an action, the app will receive it then the app will create a CXAction to the CallKit, here the app will print the calling of for this method:

open func request(_ transaction: CXTransaction) async throws

But there is no such log, so we can make sure there is no user action, but directly from the system:

func provider(_ provider: CXProvider, perform action: CXEndCallAction) {

Thanks for your reply. But if the user taps any hardware to trigger an action, the app will receive it.

How are you receiving these events from hardware or from the call screen UI? For example, if you're on the lock screen in a call and the user taps "end call", how is your app receiving that event from the system?

I ask, because the way I'd expect this to behave and the way our sample app behaves is that the system “directly” calls "performEndCallAction:" on your CXProviderDelegate, exactly what you seem to be describing.

Then the app will create a CXAction to the CallKit, here the app will print the calling of this method:

CXCallController.request(CXTransaction) is how your app asks CallKit to perform action on your app’s behavior. For example, Speakerbox uses it to implement its own interface for starting, ending, and muting calls. However, this is only used for implementing the in-app UI. The same actions in the call screen UI will be delivered directly through the provider delegate.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

OK, I saw the difference. But we still can not know the user action type from this method.

func provider(_ provider: CXProvider, perform action: CXEndCallAction)

There is no option like actionType to know it is triggered by the CallKit screen / Hardware / unknown. Then we can know the details.

OK, I saw the difference. But we still can not know the user action type from this method. func provider(_ provider: CXProvider, perform action: CXEndCallAction)

There is no option like actionType to know it is triggered by the CallKit screen / Hardware / unknown. Then we can know the details.

Why do you want to know this? What are you trying to do? We don't provide this kind of detail because applications shouldn't be changing their behavior based on the how the user ended the call.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

The background like:

We have a VoIP app with more call features. Sometimes, we received some feedbacks about "call ened". After checking the log file, it shows there are user actions (eg, from func provider(_ provider: CXProvider, perform action: CXEndCallAction)),

But the user said no user actions. So we doubt if there is a system-level event or error that will end this call. Then the details of the end call reason would be very helpful for debugging.

We have a VoIP app with more call features. Sometimes, we received some feedback about "call ended". After checking the log file, it shows there are user actions (e.g., from func provider(_ provider: CXProvider, perform action: CXEndCallAction)),

If you want to look into this in depth, then the best approach is to get the user to capture a sysdiagnose and use the console log to see if you can determine what's going on. A few notes on that:

• The log doesn't need to be captured "immediately" after the issue. Even logs captured a few hours later are often quite useful.

• It IS critical that the device NOT have been rebooted since the problem occurred. If it has been rebooted, so much log context is lost that the log is generally useless.

You can find instructions for triggering and collecting a sysdiagnose here. Having said that, one comment on this:

But the user said no user actions. So we doubt if there is a system-level event or error that will end this call. Then the details of the end call reason would be very helpful for debugging.

While it's possible there is some kind of issue going on here, it's also common for users to not be entirely aware of EXACTLY how the phone handles every detail of the call flow. For example, many users don't notice that clicking the lock button will hang up a call that's being directly handled by the device (not through a headset)[1], even though that behavior has been part of iOS for essentially "forever" (possible iPhone 1). I've seen cases where users have reported these as app bugs, when what's actually going on is that the user happens to have noticed a behavior they were previously unaware of.

[1] I use this example because I personally experienced it with EXACTLY this behavior. Many years ago, as we were preparing to release Speakerbox, I actually got frustrated because I couldn't "get" to the lock screen UI because every time I locked the screen, the call hung up. I was so annoyed that I was actually testing Phone.app to validate that it was "a bug", only to discover that Phone.app was behaving exactly the same way a full OS release earlier (iOS 9 vs. iOS 10). Even worse, a few days later, I realized that I'd unconsciously ended a call... by clicking the lock button.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware