Description
We're using both flutter_callkit_incoming and callkeep together in our Flutter app (Android & iOS) for VoIP call handling.
The issue is:
When the app is terminated, and the user taps "Accept" from the native call screen (CallKit), the app launches but the call ends immediately.
Sometimes even when the app is in background or foreground, tapping “Accept” causes the call to end instantly, without reaching joinCall.
Expected behavior
The call should proceed into the joinCall() logic and remain connected. The call panel and UI should appear normally.
Code & Flow
We handle FlutterCallkitIncoming.onEvent and manually map Event.actionCallAccept to emit a CallKeepPerformAnswerCallAction, which in turn triggers our callKeep.on(...) handler.
Inside the answerCall handler, we perform:
joinCall(call)
callKeep.setCurrentCallActive(...)
Show Android native call screen if needed
We store call state in a local DB and restore it using restoreCallFromTerminatedState() if needed.
Call Ends Unexpectedly
We confirmed that answerCall() is hit, but in some cases:
The call ends right after joinCall
In logs, we do see [answerCall] setCurrentCallActive Done, and then shortly after [hangup] due to ICE disconnection or no participants
Possible Theories
App lifecycle events (like re-init during startup) may interfere with stream signaling or pluginHandle
onEvent and callKeep.emit() might race against each other or cause duplicated calls to endCall
Native layer may be calling endCall() or rejectCall() too early
joinCall() sometimes fails due to Janus not being ready, which auto-triggers hangup
Environment
flutter_callkit_incoming: flutter_callkit_incoming: ^2.5.2
callkeep: callkeep: ^0.4.1
flutter_webrtc: flutter_webrtc: ^0.13.1+hotfix.1
Platforms: Android (main issue)
VOIP: PushKit (iOS), FCM (Android), Janus WebRTC
Minimal reproduction
It’s hard to consistently reproduce, but it often happens when:
Receive VOIP push while app is terminated
Tap “Accept” from system UI
App launches, logs show joinCall runs → then call ends abruptly
Additional Notes We handle restoration using restoreCallFromTerminatedState() and verify active calls via callKeep.activeCalls().
All state is persisted in local DB and rehydrated on app startup.