Auto-Dialer: Anruflisten automatisiert abarbeiten (Android)

Wer beruflich Listen abtelefoniert – Rückrufe, Terminabstimmungen, wiederkehrende Kontaktrunden –, verbringt Zeit nicht mit dem Gespräch, sondern mit dem Drumherum: Nummer heraussuchen, abtippen, wählen, nach dem Auflegen zurück in die Liste finden, Position merken. Die Aufgabe klingt nach einem simplen Automatisierungsfall. Technisch ist sie es nicht, weil Android nicht dafür gebaut ist, dass eine App von außen die Telefonie steuert.

Der Kern des Problems liegt im Lebenszyklus der App. Sobald ein Anruf ausgelöst wird, übernimmt das Betriebssystem: Die System-Telefonie kommt in den Vordergrund, die auslösende App wandert in den Hintergrund und kann dort – je nach Android-Version, Hersteller und Energiespar-Einstellung – pausiert oder beendet werden. Genau in diesem Moment muss aber die eigentliche Automatik stattfinden: erkennen, dass das Gespräch beendet ist, den Eintrag als abgearbeitet markieren und die nächste Nummer wählen. Eine Warteschlange, die im Zustand der Oberfläche lebt, ist damit unbrauchbar.

Dazu kommen zwei praktische Hürden. Erstens die Berechtigungen: Direktes Wählen ohne Bestätigungsschritt setzt eine ausdrücklich erteilte Laufzeit-Berechtigung voraus – ohne sie gibt es keine Automatik, sondern nur einen vorausgefüllten Wählbildschirm. Zweitens die Datenqualität: Nummern kommen entweder aus der Kontaktdatenbank des Geräts oder aus CSV-Dateien, die aus ganz anderen Vorsystemen stammen, mit unterschiedlichen Trennzeichen, Zeichenkodierungen und Schreibweisen für ein und dieselbe Rufnummer.

Die App ist bewusst zweigeteilt. Alles, was Oberfläche ist – Listenverwaltung, Import, Fortschritt der Warteschlange, Einstellungen –, läuft in Flutter. Alles, was die Telefonie berührt, liegt nativ in Android. Die Naht zwischen beiden Welten sind Method Channels, und sie ist asymmetrisch gedacht: Kommandos wandern von Dart in den nativen Teil, Zustandsänderungen kommen als Ereignisstrom zurück. Das hält die Schnittstelle klein und macht sie zum einzigen Ort, an dem beide Seiten sich abstimmen müssen.

Der Zuschnitt ist kein Zufall. Der Oberflächen-Anteil einer solchen App ist der größere und der, an dem am meisten iteriert wird – dafür spielt Flutter seine Stärken aus. Der Telefonie-Anteil ist klein, aber empfindlich: Die zuständigen Android-Schnittstellen haben sich über die Versionen mehrfach verändert, etwa die Ablösung des klassischen PhoneStateListener durch TelephonyCallback ab Android 12, und die Regeln rund um Telefonie-Berechtigungen werden regelmäßig nachgeschärft. Solche Änderungen fängt man besser in einer kleinen, isolierten Kotlin-Schicht ab als verteilt über die ganze App.

Die Abarbeitung selbst ist ein Zustandsautomat auf der nativen Seite: bereit, wählt, im Gespräch, nach dem Gespräch, nächster Eintrag oder Pause. Weitergeschaltet wird nicht über Timer, sondern über die Anrufzustände, die das System meldet. Das ist der entscheidende Unterschied in der Praxis: Ein zeitgesteuerter Dialer läuft aus dem Tritt, sobald ein Gespräch länger dauert, spät angenommen wird oder in der Mailbox landet. Ein ereignisgesteuerter wartet schlicht, bis der Anrufzustand wieder auf frei wechselt.

Die Eingangsseite bleibt bewusst einfach: Nummern kommen aus den Gerätekontakten oder aus einer CSV-Datei. Die Normalisierung auf ein einheitliches Wählformat – führende Null, Ländervorwahl, Leer- und Sonderzeichen in der Schreibweise – gehört in den Import und nicht in die laufende Anrufserie. Was einmal in der Warteschlange steht, soll wählbar sein. Und weil eine Automatik, die sich nicht anhalten lässt, im Betrieb unbrauchbar ist, bleibt der aktuelle Eintrag jederzeit sichtbar und die Abarbeitung jederzeit unterbrechbar.

• Automatisches Wählen ganzer Listen
• CSV- & Kontakt-Import
• Warteschlangen-Abarbeitung
• Native Android-Telefonie via Method Channels

Für den betrieblichen Einsatz eines Kunden entwickelt und dort in der Praxis genutzt: Die App steuert die native Android-Telefonie und arbeitet Anruflisten selbstständig ab. Einsatzdetails des Kunden behandeln wir vertraulich.

Verallgemeinerbar ist vor allem eines: Bei Apps, die Funktionen des Betriebssystems automatisieren, steckt der Aufwand selten im sichtbaren Feature, sondern im Prozess-Lebenszyklus und im Berechtigungsmodell. Die Frage, ob eine App etwas technisch kann, ist meist schnell beantwortet. Die eigentlichen Fragen lauten, was passiert, wenn das System die App in den Hintergrund schiebt, welche Berechtigung aktiv erteilt werden muss und was davon in der nächsten Betriebssystem-Version anders geregelt ist. Solche Apps haben – anders als reine Oberflächen-Anwendungen – einen dauerhaften Wartungsanteil, der von Anfang an in die Planung gehört.

Ebenso übertragbar ist die Architekturfrage: Cross-Platform oder nativ entscheidet sich sinnvoll pro Funktion, nicht pro Projekt. Eine plattformübergreifende Oberfläche mit einer schmalen nativen Schicht genau dort, wo Systemzugriff nötig ist, ist häufig die günstigere Antwort als beide Extreme – vorausgesetzt, die native Fläche wird bewusst begrenzt und dokumentiert. Und für interne Werkzeuge gilt: Der Zuschnitt entscheidet über die Machbarkeit. Ein Dialer, der eine Liste abarbeitet, ist ein überschaubares Vorhaben; ein System, das zusätzlich Kampagnen, Gesprächsergebnisse und Fremdsysteme verwaltet, ist ein anderes Projekt.