feature/quality-of-life request: better semantics for autorun / non-autorun flows

76 views
Skip to first unread message

Alexius

unread,
Jul 8, 2025, 4:37:40 AMJul 8
to Automate for Android

Disclaimer: I may be misunderstanding the current semantics but I 1) did read the manual and 2) do use Automate and it mostly does what I want (so I do at least hope that I "get it right")

As it stands now there is an option to run one's flows at startup but there is no way to explicitly exclude some flows from doing so, it is done implicitly as far as I understand (flows that have been successfully started and are running are resumed on next boot, flows that have been, at the moment of reboot, not running are not)

I think it would be nice to have a checkbox, in the entry point configuration options near the "allow parallel launches" and "don't show in list of starting points", that would explicitly exclude a starting point from automatic launch ("ONLY allow manual launch from this block")

Henrik "The Developer" Lindqvist

unread,
Jul 14, 2025, 3:08:55 PMJul 14
to Automate for Android
The "run on system startup" option will just ensure that the app explicitly start at boot, but it could also be started in other ways, e.g. if it's enabled as a accessibility service, notification listener, default assistant, has a widget or QS tile, etc..
So there's no reliable way to detect if it's a "boot startup" or a "resume startup" an due to being killed by low-memory.

Henrik "The Developer" Lindqvist

unread,
Jul 14, 2025, 3:10:11 PMJul 14
to Automate for Android
Forgot, as an alternative, include an Broadcast receive block with action "Boot completed" that stops the flow or fiber.

On Tuesday, July 8, 2025 at 10:37:40 AM UTC+2 Alexius wrote:
Reply all
Reply to author
Forward
0 new messages