Auto-Dialer: Working Through Call Lists Automatically (Android)

Anyone who works through call lists professionally – callbacks, scheduling, recurring contact rounds – spends a noticeable share of that time not on the conversation but on everything around it: locating the number, typing it in, dialing, finding the way back into the list after hanging up, remembering the position. It sounds like a straightforward automation problem. Technically it isn't, because Android was never built to let an app drive telephony from the outside.

The heart of the problem is the app lifecycle. The moment a call is placed, the operating system takes over: the system telephony moves to the foreground, the app that triggered the call drops into the background and can be paused or terminated there – depending on Android version, device manufacturer and battery-saving settings. Yet that is precisely the moment the actual automation has to happen: detect that the call has ended, mark the entry as processed, dial the next number. A queue that lives in the state of the user interface is therefore unusable.

Two practical hurdles come on top of that. First, permissions: placing a call directly, without a confirmation step, requires an explicitly granted runtime permission – without it there is no automation, only a pre-filled dialer screen. Second, data quality: numbers come either from the device's contact database or from CSV files exported by entirely different upstream systems, with varying delimiters, character encodings and notations for one and the same phone number.

The app is deliberately split in two. Everything that is user interface – list management, import, queue progress, settings – runs in Flutter. Everything that touches telephony sits natively in Android. The seam between the two worlds is made of method channels, and it is designed to be asymmetric: commands travel from Dart into the native layer, state changes come back as a stream of events. That keeps the interface small and makes it the single place where both sides have to agree on anything.

The split is not arbitrary. In an app like this, the interface is the larger part and the part that gets iterated on most – exactly where Flutter plays to its strengths. The telephony part is small but sensitive: the relevant Android APIs have changed several times across versions, for instance the replacement of the classic PhoneStateListener with TelephonyCallback from Android 12 onward, and the rules around telephony permissions are tightened regularly. Changes like that are easier to absorb in a small, isolated Kotlin layer than spread across the whole app.

Processing itself is a state machine on the native side: idle, dialing, in call, post-call, next entry or pause. Advancing is driven not by timers but by the call states the system reports. In practice that is the decisive difference: a time-driven dialer falls out of step as soon as a call runs long, is answered late or ends up in voicemail. An event-driven one simply waits until the call state returns to idle.

The input side stays deliberately simple: numbers come from the device contacts or from a CSV file. Normalizing them into a single dialable format – leading zero, country code, spaces and punctuation – belongs in the import, not in a running series of calls. Anything that makes it into the queue should be dialable. And because automation that cannot be stopped is unusable in daily operation, the current entry stays visible at all times and processing can be interrupted at any point.

• Automatic dialing of whole lists
• CSV & contact import
• Queue processing
• Native Android telephony via method channels

Built for a client's operational use and used there in practice: the app controls native Android telephony and works through call lists on its own. The client's deployment details are treated confidentially.

One lesson generalizes above all others: in apps that automate operating-system functions, the effort rarely sits in the visible feature but in the process lifecycle and the permission model. Whether an app can technically do something is usually answered quickly. The real questions are what happens when the system pushes the app into the background, which permission has to be actively granted, and which of those rules will be handled differently in the next OS release. Unlike pure interface applications, apps like this carry a permanent maintenance share that belongs in the planning from the start.

The architecture question generalizes just as well: cross-platform or native is sensibly decided per capability, not per project. A cross-platform interface with a thin native layer exactly where system access is required is often the cheaper answer than either extreme – provided the native surface is deliberately bounded and documented. And for internal tools, scope decides feasibility. A dialer that works through a list is a manageable undertaking; a system that also manages campaigns, call outcomes and third-party systems is a different project altogether.