FYI, my answers below are in terms of CallKit because “Phone.app” is actually a CallKit client app (like any other voip app), using the same broad implementation patterns and behavior. More to the point, the broader system can’t really differentiate between CallKit client and everything here applies to all CallKit apps, not just Phone.app.
- Is there a supported public API that lets this app wake or execute when a cellular call connects while the iPhone is locked?
No.
- Can microphone injection support this use case without keeping the app in the foreground?
I'm not sure as, to be honest, this is the first time I've actually seen this particular API. What's your audio session configuration? If it's one of the recording variants, then the answer is "no". We disabled all background recording session activation late in iOS 12, aside from CallKit and (a few years later) the PushToTalk framework. If you're able to use a playback audio session, then you might be able to activate a mixable audio session, but the problem would still be how your app would wake up to do so.
If supported, what audio-session configuration
See above.
and background execution mechanism should be used?
I don't see any mechanism that would do what you want.
Is there any supported public API that gives a third-party iOS app access to the remote caller’s audio during a native cellular call, with the appropriate user consent?
No. One thing to understand here is that there's a significant difference between the user experience CallKit (and, by extension, Phone.app) present and what’s actually happening "under the hood". From an interface perspective, CallKit creates the appearance of a unified architecture that directly manages some sort of "call", but the reality is that CallKit is effectively just a very specialized interface API whose only involvement with the audio system itself is session activation/deactivation. It doesn't ACTUALLY have access to the app’s raw audio data* and, as far as the app is concerned, it's just using a standard PlayAndRecord session to send out data.
*You'd think a feature like live translation would be an exception, but what's actually happening there is that the app is routing its own audio through our speech-to-text APIs, then sending text over to the CallUI for display. The details of that process are all handled by the CallKit framework (which is why there's so little API involved) but that doesn't change the fact that, as far as the call UI is concerned, it's just displaying the text it was told to show.
Given all that context, what you're actually asking for here is the ability for one app to capture the output of another app. We do have some support for that, but they all require the involvement of the app being captured. We've never provided a "general" capture mechanism, and call audio would obviously be the area we'd be most concerned about doing so.
If this is unsupported, does implementing this functionality require calls to be handled by our own VoIP service
A VoIP app has raw access to all of the audio, so it can obviously do whatever it wants.
or a carrier-side integration?
Sure. Most apps that do this sort of thing from the carrier side work by redirecting the user’s number to their own phone number. At that point, they have total access to "the call", since the incoming call is actually going to "them", not the user’s device.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
