"Call State?, Proceed when changed, State idle" not pausing when an incoming call is ringing.

[John Farrell]

Good evening,

I'm an experienced software engineer but a new Automate user. I'm finding it really impressive and powerful but am struggling to understand the behaviour of the "Call State?" block.

I'm trying to write a flow that waits for an incoming call to ring, does some stuff, waits for the call to stop ringing (or end) and then undoes some stuff.

I'm using "Call incoming" with the "Proceed  when ringing" option to wait for the call, followed by "Call State?" with "Proceed when changed" and state "Idle" to detect when the call ends (returns to state idle).

I am finding that the "Call State?" block seems to exit immediately without waiting whenever the call is ringing. Typically it exits immediately with NO on the first call, and with YES on following calls. But in no case that I've observed does it block waiting for the state to return to Idle while the call is ringing.

I attach a test flo that demonstrates this behaviour, along with a screenshot of its log when receiving a call. The test flo just tries the "Call State?" 3 times in succession then gives up and waits for another call, but I've also tried it in a loop with a 1 second delay between and it always seems to exit immediately when ringing even though I've selected "Proceed when changed".

I had expected it to block until the call returned to state idle, whether having gone unanswered or been answered and then hung-up.

Am I mistaken about how this should work or have I discovered a bug?

Thanks and best regards

John

[мJ ZЖУ]

Adding 3 same blocks continously seem not effective in your case just keep one Call state block and change it to Immediately.

There could be small issues where device could not detect properly if call is idle, incoming, or not.

[Henrik "The Developer" Lindqvist]

Remove last two superfluous Call state blocks since sequentially checking state like that will not work as you expect. 

Android version?

[John Farrell]

Hello Henrik

Sorry I should have mentioned this is Automate 1.51.1 on Android 16 (Samsung A56, 

Build number BP2A.250605.031.A3.A566BXXSABZD1, 

Kernel version 6.6.77-android15-8-abA566BXXSABZD1-4k #1 Wed Apr 101:30:36 UTC 2026). 

My actual flow doesn't have the two superfluous "Call State?" blocks, I just added them for debug purposes to see what happened. 

Nevertheless, I don't understand why the first "Call State?" block exits immediately with No rather than waiting for the call state to become Idle. 

Thanks for any insight. 

John 

[Henrik "The Developer" Lindqvist]

The system may report the incoming call before the call state change hence it probably detects the going from Idle to Ringing taking thus taking NO path. Try ignoring it (connect to itself), or insert a short Delay.

[John Farrell]

Hello again Henrik and thanks for your reply.

I appreciate the potential for a race condition between "Call incoming" and the system state change and I've now done some more investigation.

I changed the test as you suggested to delay 1s before "Call state?" and to loop back on itself on a "NO", but the "Call state?" is still not waiting for ringing to end before it exits YES.

You can see from the attached log that we have a Call incoming at 12:14:00.091.  After a 1 second delay we check the "Call state?" at 12:14:01.104.  This exits YES almost immediately at 12:14:01.116.  However, the call was still ringing at this stage.

I also attach a separate flow I ran in parallel that calls "Broadcast receive" in a loop to monitor android.intent.action.PHONE_STATE.  You can see from its log that it detects the incoming call at 12:14:00.639 with state RINGING. A fraction of a second later at 12:14:00.642 it reports the incoming_number of the RINGING call.  It then reports nothing until 15 seconds later at 12:14:15.894 when it reports the change to state IDLE (which coincides with the incoming call stopping ringing).

So I don't understand why the "Call state?" wait for Idle returned YES at 12:14.01.116 when the incoming call was already ringing and didn't return to state Idle until almost 15 seconds later.

I also tried increasing the delay between "Call incoming" to "Call state?" to 5 seconds, but the "Call state?" still exited YES without pausing.

Thanks and best regards,

John

[мJ ZЖУ]

You set the delay to check call state to every one second which I think too frequent.

The call is still ringing because you neither pick it or hang up so it doesn't do anything other than flow above.

[Henrik "The Developer" Lindqvist]

I just tested your "Idle wait problem (loop version).flo" flow in the Android 16 emulator:

06-12 20:23:32.457 I 3@1: Flow beginning
06-12 20:23:32.458 I 3@2: Call incoming
06-12 20:23:55.009 U 3@3: Call received. Do some stuff then wait for call to go idle again.
06-12 20:23:55.009 I 3@18: Delay
06-12 20:23:56.019 I 3@4: Call state?
06-12 20:23:59.327 U 3@5: Wait for idle returned YES. Undo some stuff and wait for next call.
06-12 20:23:59.327 I 3@2: Call incoming
06-12 20:24:05.765 U 3@3: Call received. Do some stuff then wait for call to go idle again.
06-12 20:24:05.766 I 3@18: Delay
06-12 20:24:06.778 I 3@4: Call state?
06-12 20:24:10.276 U 3@5: Wait for idle returned YES. Undo some stuff and wait for next call.
06-12 20:24:10.277 I 3@2: Call incoming

It seems to work as expected, so it may be Samsung breaking something.

I suspect the Call state block is immediately reporting it current state when it's registered, standard Android doesn't do this.

But the block should handled this anyway, since it reads the current state then await it to change.

As a test, insert an Call state with Proceed=Immediately after the Delay, what does state does it report?

[John Farrell]

Good evening Henrik.

Thanks for checking that out I really appreciate you spending the time.  Interesting result.

I've inserted an extra Call State?, Immediate, Idle and this is what it reports.

Let me know if there's anything else you'd like me to try.

Best regards,

John

[John Farrell]

Hello Henrik,

A further bit of data in case it's useful.

I ran the exact same test and monitoring flows on a different device - Xiaomi 12 Lite, Android 14 - logs attached.

The raw broadcast intents are virtually identical across both devices.

However the "Call State?, When changed, Idle" block behaves completely differently.

On Xiaomi it successfully holds the fibre for about 14 seconds from 22:58:55.824 until 22:59:10.114 when the call actually stops ringing.

Whereas on Samsung, per previous message, the same block falls through almost immediately even though the call is still ringing.

Not sure if this helps shed light on the problem but I thought I'd mention it just in case. Certainly seems like a strange one!

Best regards

John

--
You received this message because you are subscribed to a topic in the Google Groups "Automate for Android" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/automate-user/8rTRXm3Q-eY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to automate-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/automate-user/980934f2-7056-4f76-8a41-887ebae2c131n%40googlegroups.com.

[Henrik "The Developer" Lindqvist]

Hmm, so the system method seems to gets the correct current NO state since it's RINGING.

But when registering a system "listener" for a change in that state, it immediately reports an incorrect IDLE (value 0) which differs from RINGING hence the block proceeds.

As a test, try setting the Subscription id.

[John Farrell]

Sure, I'll try that right now.

I should have mentioned the Samsung device has 2 SIMs and the Xiaomi does not.  Sorry I hadn't thought of that previously.

John

[John Farrell]

Hi Henrik,

Well I think you nailed it!

Attached updated flow which tracks subscription_id across "Call_incoming" and "Call state?", plus logs.

As you can see by matching the new test log against the raw broadcast log, the 'When changed' block now behaves flawlessly.

The immediate check returns 'NO' at 00:06:44.261, and the 'When changed' block successfully holds the fibre for 14.532 seconds. It releases and returns YES at 00:06:58.793, perfectly matching the system's raw IDLE broadcast at 00:06:58.922.

So the moral to the story is that you must correctly specify the subscription_id in the "Call state?" block to avoid unexpected behaviour on devices with more than one SIM.

Many thanks for putting the time and effort into pinning this down.  Sorry I didn't think to include the subscription_id earlier.

Best regards

John

[Henrik "The Developer" Lindqvist]

The odd thing is that the Call state block always use a Subscription id even if the users didn't explicitly select one, it defaults to using the default subscription for voice, maybe that's broken on Samsung.

As a test, please create a flow with the Subscription default get block with Proceed=Immediately and Usage=Voice then log its Subscription id output, what its value?

[John Farrell]

[John Farrell]

Sorry hit send too soon.

Attached log and flow for requested test.

It seems "Get default subscription, Voice" is returning a null subscription_id and sim_slot.

Maybe because I have my Preferred SIM for Calls set to "Always ask" in the Samsung SIM Manager (screenshot attached).

John

[Henrik "The Developer" Lindqvist]

Thanks. So that's the issue, on Samsung the default Subscription ids aren't available, cannot be accessed.

There's probably no workaround, so i'll have add a notice in the docs about Samsung devices.

[Henrik "The Developer" Lindqvist]

Indeed, that might be the cause, yet another feature Samsung has broken.

Can you try the flow with the "Always ask" option?

[John Farrell]

One final test for tonight.

I changed my Preferred SIM for calls first to RedBySFR and then to O2 UK while running "Idle wait problem (loop version 2)". Log attached,

With preferred SIM set to RedBySFR and with call to O2 UK SIM, "Wait for call state idle" returns immediately at 01:59:38.616.

With preferred SIM set to O2 UK and call to O2 UK SIM, "Wait for call state idle" pauses for ~15 seconds before returning at 02:02:33.306.

So I think this confirms, "Call State?" requires either that the correct subscription_id is specified or that the incoming call SIM matches the default subscription for voice. Best, then, to always specify the correct subscription_id as an input to "Call State?".

John

--

You received this message because you are subscribed to a topic in the Google Groups "Automate for Android" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/automate-user/8rTRXm3Q-eY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to automate-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/automate-user/fa39368d-ee3a-4862-a81d-5cd95fcf43c0n%40googlegroups.com.

[Henrik "The Developer" Lindqvist]

Thanks. Okay, then i guess the Subscription default get block, and the same system method for getting it also used by other blocks like Call state, simply don't work on Samsung.

Sadly there's no workaround for that except maybe adding a custom setting in Automate as a fallback, or adding a notice in the documentation.

[John Farrell]

Yes  I think you're right, if "Preferred SIM for calls" is set to "Always Ask" in Samsung SIM Manager there's no way that "Subscription default get" can return a useful subscription_id and "Call state?" etc. will therefore fail unless the correct subscription_id is passed in.

I've done that now for my actual flow and it seems to be working well regardless of "Preferred SIM" setting, so I guess the morale of the story remains to always specify the correct subscription_id for the current call.

Even on non-Samsung devices, its probably a good idea to do that, in case the default voice subscription does not match the actual subscription_id for the current call?

John