Problem: When the screen is locked, an incoming call does not initiate the launch of the Flutter application required for audio and video communication through Jitsi Meet. In the unlocked state, the application functions correctly.
This is a problem with your app that you'll need to address, not an issue with our API or the system’s broader behavior.
The core point is actually here:
The current implementation does not have a mechanism for activating the Flutter engine when receiving a call via CallKit while the screen is locked. Although CallKit UI displays the call acceptance interface and the audio session is configured, the Flutter application remains in a suspended state, making it impossible to connect to the media server. Audio session activated using didActivateAudioSession method.
The CallKit UI isn't an independent system component outside of your app’s control, but is actually an interface element your app is controlling and managing. Case in point, the ONLY reason the incoming call UI ever appears is because your app called "reportNewIncomingCall", telling the system to present the call UI. Similarly, your app itself is not suspended, otherwise basic operations like audio session activation could not occur. Any issues Flutter is having here are because of Flutter's implementation and/or how your app is implemented, not the system.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
