How to (actually) send DTMF on Android without being the default call app

It's not hard for apps to commit toll fraud - all it takes is sending SMS or phone calls programmatically. Here's the Google Play page on billing fraud: https://developers.google.com/android/play-protect/phacatego... , and a writeup about malware used for WAP billing fraud: https://www.humansecurity.com/learn/blog/satori-perpectives-... .

I don't think that applies here. You get billed for the connection. But you can't send DTMF without being already connected (not in the GSM world anyway), so this can't affect the call billing.

Is there a spec for these anywhere? the , and ; specifically.

This sounds like it exactly solves a problem I have in automating interaction with my phone carrier's IVR interface for adding billing credit. Each of the delays are different, but predictable, and the whole process is about 30 seconds long.

I knew about the comma, but not about the semicolon. Very cool information!

yes, this is particularly useful ! but sadly yep, the app needs to be interactive as it's basically users controlling their phone using their pc, and a much bigger screen :)

I think isolating the call stream to authorised apps makes a lot of sense. Using a accessibility feature to make accessibility work seems like the right solution to this problem. The initial hack (just injecting tones into the system) sounds like a bad solution to be honest.

For other advanced stuff you have to be the default dialer app which also makes a lot of sense. If you're going to be an accessible dialer, you may as well actually communicate to the system that that is what you are. With plenty of open source dialer apps to borrow from, I don't expect the burden to even be that high.

Interestingly, the post writes that the app communicates with the phone over ADB. I wonder if you could just inject keypad button presses using adb, so the app doesn't need to even be an accessibility service to get the tones across? Although I guess that only works if the dialer is in the foreground.

> It seems totally reasonable to me that arbitrary apps can't insert sounds into my call audio, am I wrong here?

No, though I will say I'm upset with how protected calls have become on phones in recent years. I used to record every phone call with an app so I had a record of it, something which is completely legal to do where I live, but that really isn't possible anymore.

Now all my calls go through a VOIP provider and call recording is a feature they offer.

Well, unless it's the app that makes the call.

But AFAIK both Android and iOS disabled all call apps except for their own.

Previously they allowed as long as the keypad looked "distinctively different from the default call app", but turned that off some time ago. I can see the security reasoning, but still think there were ways to make it possible and secure.

A similar question, for example, is how to record a call, default or not. AFAIK there's no way.

> generating DTMF tones yourself and injecting them into the audio stream?

When I was an undergrad I had an audio file for each digit and a winamp playlist for each of my frequently dialed numbers. I'd hold my (landline) phone against the computer speakers and double-click the playlist to dial. I'm sure I spent more time setting this up than it ever saved, but it was somehow pleasing that this ridiculously over-powered speed dialer worked.

If you are the dialer app, you could generate DTMF tones, yes.

If you want to do dialer things without being the dialer, then no. Android doesn't permit apps to access the audio streams of a call to non-dialer apps.

In this case, the solution was to use an accessibility service to perform accessibility tasks as an accessibility app. Quite appropriate, I think. Although it will fail if the dialer of your choice doesn't have a keypad with the exact right labels (or numbers? I don't know if phones in writing systems with alternative numbers still show Arabic numerals on the dialer).

There's a few different reasons things are more complex, but one interesting wrench to throw in is that audio tones may not be the best way to send DTMF. Many digital telephone networks support out-of-band DTMF where the digits are sent as digital keypress events instead of actual tones (tones are usually still emitted to the user for comfort). There are a few potential benefits but mostly it improves reliability over iffy connections, reducing instances of one press being detected as two due a dropout in the middle, for example. I believe 3GPP has supported out-of-band DTMF for some time but it may not have been common, VoLTE encourages it much more. The other end is always going to have support for traditional in-band DTMF because they don't know what type of connection the caller has, so it's not a fatal problem, but less than ideal to use in-band DTMF when out-of-band DTMF is supported. This type of consideration is one of the reasons that the telephony part of phones is more complicated than you might think.

yes, the solution presented in the article ultimately ends up using the accessibility APIs to click buttons in the dialer, due to restrictions on non-default-call apps

well technically you can, and a quick google search leads to apps that do this. but when you aren't in speakerphone mode, well the sound isn't loud enough to be properly processed on the other end of the line

That app doesn't allow you to inject the tones into an in-progress call; it just plays the tone. If the phone is in speakerphone mode it might work, though would probably still be unreliable. If not, then it just won't work.

although this solution seems really cool, we had only a few months to work on this, and to yoink an existing app well we would need to check if the license allows for it. also, we didn't wanted to have the burden of maintaining features out of our scope

it was a school project so I had not the time nor the expertise to do it