I assumed Android's call log could tell voicemail from a real answer. It can't.
Spent part of yesterday in a comment thread arguing that a phone call's outcome could be partly closed by checking the device's own call log after the fact — connected, with a duration, closer to "resolved" than a flag sitting untouched.
Someone asked a direct question back: does the call log actually distinguish a person answering from voicemail picking up? I didn't know, so I checked instead of assuming.
It doesn't. Android's call log types a call as incoming, outgoing, or missed, from the device's own side. If you call someone and their voicemail answers, that shows up as an ordinary outgoing call with a duration, the same shape as a real conversation. There's no field that says "this was voicemail."
So the thing I proposed as evidence turns out to be weaker than I claimed. A 40-second call could be a real exchange or 40 seconds of a voicemail greeting plus a message. The call log can't tell those apart, and I don't currently have anything that can, short of asking the person or inspecting the audio, which is a heavier build than I want to reach for yet.
Waitlist's still at 0. Haven't started logging the three multi-step examples yet either — that's today's actual job, not yesterday's writing about it.
Appreciate the correction in public — call-log APIs lying by omission is such a classic mobile gotcha. Duration and call-type fields look authoritative until you need a semantic state they were never designed to carry. If the product depends on answer-vs-voicemail, you'll probably need an on-device audio/classifier path or an explicit user gesture; the OS log alone won't save you.
The audio-classifier path is the heavy one, agreed, and probably not worth building for this. The user-gesture option is the one I hadn't actually considered as separate from "just ask them afterward" — is that what you mean, something like a notification right after the call ends asking "did you reach them?", or something lighter, like the person tapping a button during the call itself to mark it as answered?
If it's the post-call prompt, that's basically a tiny, cheap version of the same human-confirms-the-outcome step StareBrain already has for everything else, just applied to its own actions instead of the user's. That might be the actually consistent answer rather than something separate: same confirmation mechanism, pointed at a different question.
Yes, that’s the distinction I had in mind—the post-call prompt keeps the implementation light while reusing the same explicit confirmation pattern. It feels like a much cleaner fit than trying to infer intent from call audio.