BUG: Data network default breaks weirdly and annoyingly if Location is set to OFF (from the quick tiles) regardless of permissions (at least in work profile?)

[Alexius]

Steps to reproduce:

Have Automate in work profile (may also be reproducible in owner profile, didn't check)

Create a flow that uses Data Network Default block

Grant relevant permissions

Design the flow to be continuously running 

Enable "run at startup"

Run the flow

Disable location

Reboot (or pause and then unpause work profile apps, which is a comfier way to play with this bug)


Expected behavior:
Flow would gracefully start because nominally network info  can still be retrieved  OR it would fail explicitly and put a red message in the flow log.

Observed behavior:

Automate service fails to start wholesale (no notification about number of fibers running) silently BUT the flow is nonetheless is executed SOMETIMES (I know because it modifies some files when it fires so I can check if it ran or not without opening automate and reading logs) without putting anything useful into any log I can find.

This does not result in explicit error in logs.

Also, notably, if you manually open the Automate app (from the work profile app drawer) the service will initiate and notification with fiber counter will appear (so whatever "location is disabled' is doing is not very critical for launching automate's service OR resuming the "data network default" containing flow - after automate being opened the flow is displayed as running and runs just fine)

 explicitly starting the service as root via cmd
cmd activity start --user 13 -a android.intent.action.VIEW -n com.llamalab.automate/com.llamalab.automate.StartServiceActivity -f 0 com.llamalab.automate
will succeed at starting the service and the fiber counting notification regardless of whether location is on or off . The flow with data network default block will be resumed gracefully.

Starting any flow via shortcut regardless of whether location is on or off will succeed at starting the service and make the fiber counter notification show, and the data network default flow will resume and run gracefully.

So that's about it.

Oh, and the reason I implicate the "Location: OFF" in the quick access tiles is that if I turn it to Location:ON from there and then pause/unpause work apps (or reboot, tried both) no problems occur and Automate starts as expected, resuming every flow with no problem

[Henrik "The Developer" Lindqvist]

Android version?

[Alexius]

Android 16, GrapheneOS latest OTA (but also reproduced on CalyxOS latest OTA, can try doing it on stock too)

[Henrik "The Developer" Lindqvist]

Sadly Google has made it increasingly difficult to start a foreground service at reboot, the latest release, version 1.47.3 has made some changes to hopefully fix that.

Ensure Automate has been granted the "allow all the time" location permission, see system settings, App, Automate, App permission, location.

[Alexius]

Still has unreliable startup along same lines for me, but adding following workaround solves it (so far, it seems):

1) create a separate flow that has an automate start service listener (on a loop) and a shutdown broadcast receiver (forked at start of loop)

2) have the "service start" one start the "location-problematic" flow and then loop back (re-arming the service start listener and the shutdown one)

3) have the "shutdown listener" kill the "location-problematic" flow, no need to loop this one back.

4) this way, the "location-problematic" flow gets killed at system shutdown and it is the "handler" script that gets resumed at reboot, and upon detecting the reboot restarts our location-problematic flow and rearms itself . Because the location-problematic service is not resumed at start, the weird location-permissions related behavior does not trigger. The "handler" flow has no problem starting up the problematic flow (NB! I have an extra "precise 1 second" delay between firing of the listner and the problematic flow start, just to be on the safe side) 

For some reason, using "boot completed" listener is less reliable than "automate service start" listener for this usecase, don't know what's up with  that. Hope this helps someone )  

[Henrik "The Developer" Lindqvist]

So Automate starts okay after a reboot if no running flow is using a location block?

The "boot completed" broadcast is only sent once every reboot, "Automate service start" every time Automate is restarted, e.g. after being killed. So they're not reporting the same thing.

[Alexius]

Well, I'm testing with " Data Network Default" block but yes, when the "offending flow" is not being resumed at startup (has been terminated before system shutdown) the thing works just fine as far as starting the service is concerned.

[Io Yaj Gahju]

I must regretfully point out that it is still broken for me on latest.

If a flow has something like query network state the autostart of persistent notification (but not flow execution itself) gets broken for me unless I turn location on. Notably, granting draw over other apps does NOT resolve it for me 

Android latest stock, Pixel 7

Also reproduced on CalyxOS Pixel 5

Workaround: grant "draw over other apps" permission AND have a flow that explicitly punches the persistent service notification into existence by means of following block 

Start App Activity 

package :

com.llamalab.automate

Activity Class 

com.llamalab.automate.StartServiceActivity

Then, and only then, will the notification with fibre counters appear.

Incidentally, disabling the flow with "location implicated" network state block DOES NOT fix "missing notification" problem for me, as if the location access is still implicitly expected (and location system active) even if the "offensive" flow is disabled.

Notably, the "kickstart" also won't work if done directly from the "offensive" flow with network block

So I have to do both the "kill network flow at shutdown" AND grant draw over other apps, AND also my own "kickstart workaround" in a separate flow!

Something is weirdly broken in foreground service department.

Incidentally I have evidence that inferior automation app, which I can't use because it does not implement a function crucial to my usecase, handles the "start up service with notification gracefully, then start automated functions that touch network state naughtily" with flying colors (so it CAN be done).

Sticking with Automate but boy would I love to not have to do TWO boondongle workarounds AND grant the spooky draw over other apps permission just to get  standard persistent notification up.

Wishing you luck in getting to the bottom of this and thanks for great app (especially the ability to pick up "notification dismissed" as distinct event!)

[мJ Zкxy]

Can you made it clear if the query is if network available but not connected or 5g or wi-fi connected or it should be in separate block?

[Io Yaj Gahju]

the way I go about it is 

"data network default?" block

can be either immediate or fire when changed, affects nothing

data, 5G, wifi - not changed during my testing, all on.

reboot.

IF Location is on (the location button in quick tiles) Automate launches like a boss

IF Location is off (again, by means of quick tile press) at moment (re)boot is completed, the fiber gets resumed but persistent notification for Automate (the fiber counter) never appears (other notifications from Automate can!)

to get service / persistent notification working as intended have to use both workarounds described in this thread AND grant display over other apps

[мJ Zкxy]

I think your system see your Automate notification as default or normal priority as it is not urgent as SMS notification and not persistent notification doesn't mean flow is not running correctly in this case.

[Io Yaj Gahju]

it is the other way around it is my flow's notifications that work, and it is Automate's internal persistent one that does not

What I find weird is the dependency of state of location button, other location-implicated software has no trouble creating a foreground-service notification, that just ain't right that Automate can not

P.S FWIW I tried to make persistent notification non-silent and higher priority and it does not change the behavior.

[Henrik "The Developer" Lindqvist]

Indeed, the "draw over other apps" is basically mandatory on Android 16, as the "run on system startup" dialog say.

Without it the Automate service must be started without requesting "location", which will affect anything related to location, i.e. anything requesting the "access location in the background" privilege, as the Data network default block does.

As the system Location settings, does the Automate service start and work with it enabled?