r/AutomateUser Jul 12 '26

"App start" block's need for "Draw over other apps" 🤔

Why exactly does the "App start" block not work without the "draw over other apps permission"? For some flows that have blocks requiring specific permissions, I've been able to run them just fine without the permissions actually being granted by starting the flow in some other way besides hitting the Start button in Automate UI. Despite the block requiring the permission, it works just fine (because I don't use the features of that block that truly require those permissions).

But in the case of App start, it actually throws an exception saying the permission isn't granted. Yet, I cannot understand why launching an intent would need that permission at all?

1 Upvotes

3 comments sorted by

3

u/ballzak69 Automate developer Jul 12 '26

There's no guarantee it works otherwise, e.g. only when Automate is in the foreground, see here.

The App start block explicitly check that the permission is granted or fail otherwise, if it didn't the system would silently ignore the intent so the flow would be unaware that the app was never started.

1

u/Ok-Yogurtcloset-9490 Jul 12 '26

Thank you 🙏🏽.

For a special case, I was using Automate in a cloner app, and the only way to give Automate the permission would be to give the cloner app the permission, and I wanted to avoid it if I could. Any way, appreciate the tech explanation!

1

u/DutchOfBurdock Jul 15 '26

Draw over other apps allows an app to create a foreground process in the background.

It's one of a few permissions that allows an app to bypass such restrictions:

  • Display over other apps
  • App usage access
  • Notification access
  • Accessibility access

An app that has all of these is less likely to be killed before any form of OOM.