[Android Software/Hacking General [Developers Only]] ubergeek77:
I'm working on a personal modding project, where I take the AOSP Dialer and add some features that I'd like to have. Long story short, for a component of this, I need to figure out how Google has been able to inject arbitrary audio into the conversation/call audio stream.

For years, discussion online, and especially on Stack Overflow, has insisted that:

There are too many upstream limitations, this is impossible

This is impossible, you have to play it over the speaker and hope the microphone picks it up

You can't do this, even Google says so

Indeed, even Google's up-to-date MediaPlayer documentation clearly shoots this down and doesn't mince words:

However, we know this isn't true. At least, not anymore, and not on Pixel devices. Google's Call Screening feature can "talk" to someone calling your phone, but that synthesized audio is never played audibly to the user. In other words, Google has been able play a Text-To-Speech stream of audio to someone calling your device, doing so silently, clearly to the listener, and without requiring the handset speaker or user's microphone to be "on."

Despite the fact that this is "possible" by virtue of "it has already happened," I can't find any discussion, documentation, info, or anything helpful about how Google has been able to do this. So, what do you do?

The next logical step is to start decompiling the app, but that's easier said than done. I'm by no means an expert in reverse engineering Android apps. Admittedly, you could consider me a beginner. Still, I've found a few things that seem useful, so here's what I've been able to find:

First off, when compared to the AOSP Dialer, the Google Dialer requires an additional privapp-permission that may be of interest: android.permission.MODIFY_AUDIO_ROUTING. I can't find much about what this permission does or how it is used, but it's definitely used by the Google Dialer, and on a stock Pixel 3 XL ROM, that permission is defined in /product/etc/permissions/privapp-permissions-google-p.xml as a privapp-permission.

Next, when decompiling the app, one of the first things I noticed is that a special "IMPL" package containing a playInternal function is class injected/loaded dynamically, and it's adjacent to MediaPlayer code that seems to play audio over a certain channel. The class it tries to load is:

com/android/dialer/audio/impl/CallAudioPlayer

However, that package isn't present in the list of decompiled classes (there's no "audio" folder under "dialer"), and despite playInternal being explicitly called by a string, there aren't any other classes that seem to define the playInternal function.

I don't know where XDA stands on posting decompiled code, but if you're using JADX, the area of interest is in defpackage/bhk.java.

But if I'm correct, this means that:

You can use MediaPlayer to play over the call stream, contrary to Google's documentation; you just need a special IMPL that allows for that behavior

This (probably?) requires the aforementioned MODIFY_AUDIO_ROUTING permission

If one were to obtain/locate and re-implement CallAudioPlayer.java, you could probably reproduce this behavior in the AOSP Dialer, or any other system app with the necessary permissions

If I'm not correct, then chasing down CallAudioPlayer will be a dead end. Still, the fact stands that Google did this somehow, so the answer must be somewhere.

So... that's where I'm at with this. I don't feel like I'll get much further without some help from more knowledgeable people, since I don't know where this CallAudioPlayer class is located. If it's in the base apk, but obfuscated, I can't find it. And if it's in a system framework or overlay APK, it must be using a different name, since no instances of CallAudioPlayer or playInternal exists in any of the relevant .apks on my system.

If this requires more sophisticated Android system/API modifications, that's fine too. This will end up on a custom ROM, so even if part of this behavior extends outside of the APK, any potential solution can be implemented in an AOSP ROM to achieve this functionality.

If you have any advice on how this may have been done, I really appreciate any and all discussion I can get on this. And if you don't know, I encourage you to ask a friend or someone who might be more knowledgeable when it comes to reverse engineering. Even if no one outright knows the answer to this, I hope to get at least some recent discussion on this topic, so that people investigating this in the future will at least have some sort of starting point.

Thanks for reading!