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.