DTMF, oder Dual-Tone Multi-Frequency, ist seit vielen Jahrzehnten ein essenzielles System, das für die Übertragung von Eingaben über Telefonleitungen genutzt wird. Es erfüllt eine wichtige Funktion bei der Interaktion mit automatischen Systemen, wie dem Eingeben von PIN-Codes oder Navigieren durch Sprachmenüs während eines Anrufs. Trotz der scheinbaren Einfachheit dieser Funktion gibt es auf Android eine überraschende Hürde: Es gibt keine offizielle, öffentlich zugängliche Schnittstelle, um DTMF während eines aktiven Telefonats zu senden, wenn Ihre Anwendung nicht die Standard-Telefon-App ist. Dies bereitet vielen Entwicklern große Schwierigkeiten, zumal die Anforderungen an barrierefreie Anwendungen und individuelle Assistenz-Tools stark steigen. Das Grundproblem liegt in den strengen Sicherheitseinstellungen von Android.
Die Plattform erlaubt nur der Standard-Call-Anwendung den direkten Zugriff auf bestimmte Telefondienste, einschließlich der Funktion playDtmfTone() aus der Klasse android.telecom.Call, die theoretisch DTMF-Töne senden könnte. Doch um diese API zu nutzen, muss Ihre App InCallService implementieren und den Status der aktiven Anrufe kontrollieren – eine klare Voraussetzung, die sich aus Sicherheits- und Datenschutzgründen etabliert hat. Standardmäßig möchte Google nicht, dass beliebige Apps während eines laufenden Anrufs Zugriff auf solche Funktionen haben, um Manipulationen oder Missbrauch zu verhindern.
Viele Entwickler versuchen deshalb zunächst, den Standard-Telefon-Client zu ersetzen oder zu überlagern, was jedoch weitreichende Folgen und eine enorme Entwicklungslast bedeutet. Eine eigene vollständige Telefon-App muss höchst komplex gestaltet sein, mit einer intuitiven Benutzeroberfläche, Integration in Kontakte, Anruflisten, Voicemail-Service und der Handhabung von zahlreichen Edge Cases. Für die meisten Projekte ist dies weder realistisch noch wirtschaftlich zu stemmen. Im Rahmen eines Projekts namens LifeCompanion, das barrierefreie Assistenzfunktionen für Menschen mit motorischen, sensorischen oder kognitiven Einschränkungen bietet, wurde genau diese Herausforderung aufgegriffen. Die Anwendung sollte in der Lage sein, während Telefonaten über eine Schnittstelle auf einem PC DTMF-Töne an das angeschlossene Android-Gerät zu senden, ohne dabei die System-standard-App zu ersetzen.
Die Suche nach einer geeigneten Methode führte zu einem ernüchternden Befund: Offizielle APIs unterstützen die Anforderung nicht. Entwicklerforen, einschlägige Dokumentationen und sogar Google-Mitarbeiter hatten bestätigt, dass es in diesem Bereich keine einfache, direkte Lösung gibt. Interessanterweise wurde allerdings eine alternative Möglichkeit greifbar, die auf den Accessibility Services von Android basiert. Diese Services sind primär dafür gedacht, Menschen mit Behinderungen bei der Nutzung von Smartphones zu unterstützen, indem Sie Interaktionen mit der Benutzeroberfläche automatisieren oder erleichtern. Doch genau diese Spielräume erlauben auch das automatische Klicken auf Bildschirmbutton und so das Senden von DTMF-Frequenzen via Simulation von Benutzereingaben.
Die Idee ist genial in ihrer Einfachheit: Anstatt auf tiefer Systemebene DTMF-Töne zu erzeugen, wird die Telefon-App im Vordergrund so „ferngesteuert“, dass sie selbst die Töne generiert, indem der entsprechende Ziffernblock gedrückt wird. Dies erfordert jedoch den aktiven Betrieb und die Genehmigung eines Accessibility Services, der die notwendigen Klicks erkennen sowie durchführen kann, und deshalb entsprechenden Zugriff von den Nutzern erfordert. Technisch bedeutet dies, dass immer wenn ein DTMF-Code gesendet werden soll, ein Intent an den Accessibility Service geleitet wird. Dieser versucht dann zunächst, den Anrufbildschirm zu identifizieren. Dazu werden bekannte Paketnamen von Telefon-Apps, unter anderem Hersteller-Apps wie Google Dialer oder Samsung InCall UI, abgefragt und verwendet, um sicherzustellen, dass der Service nur handelt, wenn ein Telefonat am Laufen ist.
Um sicherzugehen, dass der Nummernblock geöffnet ist, durchsucht der Accessibility Service die aktuelle Benutzeroberfläche nach den einzelnen Zifferntasten 0 bis 9 sowie * und #. Falls der Block nicht sichtbar ist, macht die Logik sich daran, das entsprechende Umschalt-Widget zu suchen und zu aktivieren. Diese Suche basiert auf dem Text der Bedienelemente oder deren Beschreibung, wobei Mehrsprachigkeit berücksichtigt werden muss, beispielsweise "Keypad" auf Englisch oder "Clavier" auf Französisch. Die DTMF-Ziffer wird daraufhin gezielt gesucht und der entsprechende Button simuliert gedrückt – je nach Situation wird das mehrmals versucht, um sicherzugehen, dass der Klick erfolgreich ausgeführt wird. Zwischen den Aktionen werden kleine Pausen eingebaut, um den flüssigen Ablauf im UI zu gewährleisten, da die Oberfläche aufgrund dieser Manipulationen Aktualisierungen durchläuft.
Der große Vorteil dieser Lösung ist, dass die App nicht zum Standard-Telefonprogramm werden muss und somit nicht alle üblichen Telefonfunktionen implementieren oder verwalten muss. Sie nutzt stattdessen eine existierende Systemkomponente, was die Entwicklung und den Wartungsaufwand erheblich reduziert. Darüber hinaus ist die Lösung problemlos in Kotlin oder Java integrierbar und lässt sich in bestehende Assistenzprojekte oder andere Kommunikations-Apps einfügen. Allerdings ist diese Methode nicht frei von Nachteilen. Aufgrund ihrer Abhängigkeit von der Oberfläche der Drittanbieter-Telefon-Apps kann es auf manchen Geräten oder Android-Versionen zu Inkompatibilitäten kommen.
Unterschiedliche Hersteller oder personalisierte Benutzeroberflächen haben eigene Dialer-Designs, sodass möglicherweise weitere Anpassungen erforderlich sind. Außerdem muss der Nutzer explizit dem Accessibility Service zustimmen, was bei der Vermittlung von Vertrauen und Datenschutzbedenken eine Hürde darstellen kann. Zweitens stellt das automatische Klicken auf UI-Elemente eine nicht unerhebliche Fehlerquelle dar. So kann beispielsweise durch Bildschirmsperre, Bildschirmdrehung oder andere UI-Änderungen die Erkennung der sichtbaren Tasten fehlschlagen. Im schlimmsten Fall könnte der Anruf sogar unbeabsichtigt beendet werden, wenn etwa das Sternchen (*) fälschlicherweise gedrückt wird.
Trotz dieser Limitationen ist der Accessibility-Service-Ansatz aktuell die praktikabelste Möglichkeit, DTMF-Töne auf Android zu senden, wenn man nicht die komplette Telefon-App ersetzen möchte. Es zeigt exemplarisch, wie flexibel und mächtig dieser Teil der Android-Architektur für kreative Lösungen eingesetzt werden kann. Darüber hinaus demonstriert das Beispiel, wie wichtig es ist, Barrierefreiheit auch als Mittel für erweiterte Steuerungsoptionen zu betrachten und wie eng diese unterschiedliche Bereiche im System miteinander verzahnen. Durch die aktive Nutzung von Accessibility Services können Entwickler Werkzeuge schaffen, die nicht nur Menschen mit Einschränkungen nutzen, sondern auch ganz neue Anwendungsfälle möglich machen. Der Entwicklungsprozess des hier beschriebenen Services startete mit einer einfachen Version, die viele Probleme mit ständig öffnender und schließender Tastatur verursachte.
Durch iterative Verbesserungen wurde die Logik verfeinert, dass das Tastenfeld nur dann geöffnet oder geschlossen wird, wenn es nötig ist, anhand präziser Zählungen der sichtbaren Tasten. Darüber hinaus wurde die Erkennung des aktiven Telefon-UI deutlich robuster gestaltet, um Fehlaktivierungen zu minimieren. Um diese Methoden in eigenen Projekten umzusetzen, bedarf es grundsätzlich der Aktivierung und Erlaubnis des Accessibility Features durch den Nutzer. In der Praxis sollte Ihre App den Anwender mit passenden Hinweisen und Erklärungen begleiten, damit dieser verstehen kann, weshalb die erweiterten Berechtigungen notwendig sind. Dies sorgt für Transparenz und erhöht die Wahrscheinlichkeit, dass Ihre Lösung auf unterschiedlichen Geräten stabil läuft.
Parallel lohnt es sich, ständig die System-APIs zu beobachten. Android entwickelt sich weiter, und während heute der offizielle Support für DTMF außerhalb der Standard-Telefon-App fehlt, könnte sich das in zukünftigen Versionen ändern. Ebenso könnten Hersteller eigene Schnittstellen anbieten oder Drittanbieter-Apps neue Wege entwickeln. Bis dahin bleibt die Accessibility-Service-Methode eine wertvolle Alternative. Abschließend gilt: Die Fähigkeit, während eines Anrufs DTMF-Töne zu senden, ist keine triviale Funktion mehr, wenn man die Android-Plattformregeln und Sicherheitspolitik betrachtet.
Für Entwickler, die diese Herausforderung meistern wollen, bietet die Nutzung von Accessibility Services einen effizienten Kompromiss zwischen Benutzerfreundlichkeit, Sicherheitsanforderungen und Entwicklungsaufwand. Das Beispiel des LifeCompanion-Projekts zeigt, mit welchen technischen Details und praktischen Anpassungen ein solcher Service realisiert werden kann und bietet eine solide Grundlage für ähnliche Lösungen verschiedenster Art auf Android-Geräten.
