hiennguyen92 / flutter_callkit_incoming

Flutter Callkit Incoming
https://pub.dev/packages/flutter_callkit_incoming
MIT License
178 stars 308 forks source link

When iOS is on lockscreen "slide to answer" doesn't open app. #181

Closed un-hongly closed 10 months ago

un-hongly commented 2 years ago

Hi, I have an issue with the incoming call locked screen when "slide to answer" doesn't open the app instead it just stays on the call screen.

308155136_1869656696563012_5353182638395412309_n

hiennguyen92 commented 2 years ago

Only open app when type video call. Audio call only show callkit framework

un-hongly commented 2 years ago

Only open app when type video call. Audio call only show callkit framework

@hiennguyen92 Thanks you for the fast response :). Actually, It's a video call (type 1). For more information, I tested it on iOS 12.4.8 and I showed it with flutter code FlutterCallkitIncoming.showCallkitIncoming() not swift code.

itsthetaste commented 2 years ago

Setting type=1 and supportsVideo=true in my voip notification makes my app bypass this screen. I also have my audioSessionMode set to videoChat, but doubt that has an impact. My app is only supporting iOS 15+ though, so perhaps apple only introduced the ability to bypass in later versions than what you're testing.

albrave commented 2 years ago

Almost same issue here. it seems totally random. Sometimes it correctly open the app and sometimes no.

The only sure thing is that is happening only on iOS 16 and when I was able to debug during the issue I had this error on the debugger console:

NSOSStatusErrorDomain Session

The notification is set as video (I see the call as a video call) and the callkit logo is correctly implemented.

albrave commented 2 years ago

I don’t know if this could be useful

https://developer.apple.com/forums/thread/712817

federico-amura-kenility commented 2 years ago

any update on this? if my phone its locked, i can asnwer the call but then I get stuck on the lockscreen, the app is not getting opened

colaTW commented 1 year ago

Almost same issue here. it seems totally random. Sometimes it correctly open the app and sometimes no.

The only sure thing is that is happening only on iOS 16 and when I was able to debug during the issue I had this error on the debugger console:

NSOSStatusErrorDomain Session

The notification is set as video (I see the call as a video call) and the callkit logo is correctly implemented.

Have you resolved this issue? If so, please let me know. Thank you.

albrave commented 1 year ago

Hi, I used another callkit https://github.com/voximplant/flutter_callkit In general, as far as I know, there's no solution to detect when the user unlock the screen with faceID or fingerprint BUT that voximplant callkit gives you the possibility to force the app opening through 'fulfill()' native method of the apple callkit. The workaround I used is wait for 4 secs after the user accept the call and open the app through 'fulfill()' method

_provider.performAnswerCallAction = (answerCallAction) async {
      Timer(Duration(seconds: 4), () async {
            await answerCallAction.fulfill();
      });
};
cosnomi commented 1 year ago

I don’t know if this could be useful

https://developer.apple.com/forums/thread/712817


public func provider(_ provider: CXProvider, perform action: CXAnswerCallAction) {
guard let call = self.callManager?.callWithUUID(uuid: action.callUUID) else{
action.fail()
return
}
DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(1200)) {
self.configurAudioSession()
}
self.answerCall = call
checkUnlockedAndFulfill(action: action, counter: 0)
}
private func checkUnlockedAndFulfill(action: CXAnswerCallAction, counter: Int) {
    if UIApplication.shared.isProtectedDataAvailable {
        sendEvent(SwiftFlutterCallkitIncomingPlugin.ACTION_CALL_ACCEPT, self.data?.toJSON())
        DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(5000)) {
            action.fulfill()
        }
} else if counter > 180 { // fail if waiting for more then 3 minutes
    action.fail()
} else {
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
        self.checkUnlockedAndFulfill(action: action, counter: counter + 1)
        }
    }
}

Thanks to albrave, I found that waiting for isProtectedDataAvailable to be true and adding another sleep after that actually worked. However, the solution is unstable; reducing the sleep time from 5000 ms to 1200 ms caused an error. I believe it depends on the processing speed of user devices, which implies that this solution might not work for some devices.