Flows occasionally get stuck executing debug dialog; AM inccorectly states missing permissions

[vertigo]

A few times now, I've had a flow run and leave a debug dialog red (executing), even after the dialog is closed. When this happens, stopping the flow doesn't work, nor does disabling and enabling it. The only thing I've found that fixes it is stopping and restarting the AM service via the main menu. I have no idea what causes it, and haven't been able to reliably reproduce it. Its occurrence rate is very low.

And there's another, separate problem I've experienced, but it's tied to this so I'll combine it with this. After disabling and enabling the AM service, I got a notification from AM that some flows needed notification access, which it said wasn't granted. When I clicked the notification, which took me to the trigger that needed it (Media Session Changed), it showed the blue bar saying "Access to notifications needs to be enabled to use this function. Click here..." But when I clicked that and it took me to the Notification access page in Android settings, AM was enabled, i.e. it had access. A minute or two later I got another, similar notification from AM, also saying something about missing some sort of notification permission (this one was slightly different, though, but I can't recall exactly what it said), and when I checked the flow, none of the items in the flow that have anything to do with notifications (two "Notification on Statusbar Displayed" conditions and two "Perform Action on Notification on Statusbar" actions) had the blue bar warning about missing permissions. This has happened before and, while I'm not certain, I have a feeling it may have been the other time I had to restart the AM service due to the stuck debug dialog issue.

[Desmanto]

What is the phone model and ROM name? This typically happens when the system kills the accessibility or notification service from Automagic. Xiaomi, Oppo, Vivo, Huawei, Samsung and several others which has similar ROM function to kill all apps; will make this happen more frequently. That's why I avoid using the kill all button, which I always refer as the "Nuke button". It does more harm than good.

[vertigo]

Moto Z Play, stock rom, 8.0. If by "kill all button" you mean stopping the AM service, I had no choice, since that's the only thing I could do to get the flows to stop running once they got stuck on the debug condition.

[Desmanto]

It should be quite AOSP-ish enough, so maybe it is not from the nuke button. Nuke button refer to the kill all, clear all, optimize RAM, clean memory or any other similar name you usually find in the recent menu, where pressing it will clear all the recent apps. This usually force stop some app including the background service, render the service partially disabled or broken.

In your case, maybe it is caused by common low RAM condition. Try to remember if this happen after you have not restart the phone for a while. Or does it happen after fresh restart?

[vertigo]

Don't remember for sure, but I rarely restart it, so probably hadn't been restarted for a while before it happened. But I also don't have low RAM issues; Android generally does pretty good at managing that. And not sure why low RAM would cause that very specific issues of causing a flow to get stuck on a debug condition. It's happened two or three times, and each time was the same thing. And at least one of those times, if not all of them, AM was in active use, so it definitely shouldn't have had issues accessing RAM, since it would be prioritized by Android.

[Desmanto]

i usually get stuck at the sound related action, such as speech output or input speech. But now rarely got that problem. I still hypothesized that some app were intefering with the audio focus. I already forgot what have changed, since it has been long time since the last time it happened.

I never get really stucked at debug dialog. When I do, it is usually because I quickly press something when the dialog appear. To reshow the dialog, I simply execute any flow which has dialog type element. The dialog will appear twice then, once for the executed flow and the other for the hidden debug dialog. Manual execution of any dialog also work (if you are inside automagic flow already).

But for permission revoked suddenly, mostly caused by crash. Of course one of the main cause is not enough RAM. Sometimes, it is not because really low RAM. But it is caused by too aggresive memory optimization. I have turned off any kind of battery saving or RAM optimization at any of my main phone. If you have any of those kind of opitmization, try to switch them off. Sometimes, that kind of setting can be deep hidden inside the jungle, a lot of brand put hides them pretty well.

[vertigo]

I'm pretty sure it's not battery optimization, which doesn't seem too aggressive on my phone and, as I said, it happens even when AM is the most recent app and only under a fairly specific circumstance (debug dialog). I'll have to try and remember to execute it again to see if it shows me the dialog and allows me to "fix" it that way. You had me do that with something similar before, which worked, so maybe that's the problem here, too. As for the permissions being "revoked," I'm not sure that's what's happening. Rather than being revoked, it seems like AM just thinks they are.

[Desmanto]

AM can be the foreground the app, but if you use the nuke button, the accessibility services still can be killed. Of course you don't do this, but this is just to show that it can still be killed by system.

These kind of problems are the most troublesome for the dev. In android 11 AMA, many devs ask about this. Let see if google will standardize this in android 11. For now, we can only make sure never use nuke button, turn off any kind of optimization (which do more harm than benefit). And if it still happen, you need to remember the pattern and try to troubleshoot from there.

[vertigo]

I do think it should be able to deal with the problem, though, when stopping a flow while stuck on something. For example, if a flow is stopped, AM should be able to see that a debug condition is stuck active and close the dialog, which may be hidden as you describe, so the flow actually stops as it's supposed to.

[Desmanto]

Maybe AM can add some kind of floating button when a dialog is hidden/stuck. The floating button is using widget component. It will appear when hidden/stuck dialog being shown (but hidden). Once we tap it, the hidden dialog will be shown and the floating button disappear again. Just like the INFO button for control UI.