Problem with screen unlock

[Sergio Bossa]

Hi,

I noticed the "temporarily disable screen lock" action stops working after a random amount of time even if the fiber it's running on is active (paused): any ideas how this could happen? On a related note, is it possible to implement an action to permanently unlock, same as the "lock device" action work?

Thanks,

Sergio B.

[Automate developer]

When the fiber stops the screen lock will return. Do the following so the user isn't interrupted by the screen relocking:
               :
             Fork ---------------------------+
               |                             |
     [Part you want unlocked]        Screen lock disable
               :                             |
                                    +--------+
                                    |        |
                                    |   When screen on
                                    |        |
                                    +--------+
  
Android provides no reliable way to permanently unlock the device.
The hacks available are way to intrusive, changing system settings and deleting system files.

[Sergio Bossa]

Thanks for your answer.

As I said, the fiber is not stopped by the way, but paused waiting on
a WiFi event to change, let's say:

[wifi changed?] -> [unlock] - |
^ |
^--------------------------|

Isn't it enough to keep the unlock active?

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Automate" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/automate-user/04f429ab-1508-4d44-884a-de11c7c7965d%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Sergio Bossa
http://www.linkedin.com/in/sergiob

[Automate developer]

That should be enough. Since you loop back after the unlock, the fiber is still running and the screen lock will remain disabled.

> automate-user+unsubscribe@googlegroups.com.

[Sergio Bossa]

Exactly, but after a while it locks again, even if the fiber log doesn't show any further action, so it's like something external is happening: any ideas?

To unsubscribe from this group and all its topics, send an email to automate-use...@googlegroups.com.

To post to this group, send email to automa...@googlegroups.com.
Visit this group at http://groups.google.com/group/automate-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/025945e5-d9ab-42fe-93da-c678e2120a06%40googlegroups.com.

[Automate developer]

Does the device relock or is it the screen that turns off?

Currently the screen lock has nothing to do with keeping the screen lit.
Maybe should add an option to the screen lock block to also keep the screen on, i.e. prevent the device from sleeping?

[Sergio Bossa]

It relocks *after* I turn off the screen.

This happens after hours of usage, turning the screen on/off several
times, so not sure your suggestions would help.

On Thu, Oct 9, 2014 at 7:32 PM, Automate developer

>>>> > automate-use...@googlegroups.com.

>>>> > To post to this group, send email to automa...@googlegroups.com.
>>>> > Visit this group at http://groups.google.com/group/automate-user.
>>>> > To view this discussion on the web visit
>>>> >
>>>> > https://groups.google.com/d/msgid/automate-user/04f429ab-1508-4d44-884a-de11c7c7965d%40googlegroups.com.
>>>> >
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>>> --
>>>> Sergio Bossa
>>>> http://www.linkedin.com/in/sergiob
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Automate" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to

>>> automate-use...@googlegroups.com.

>>> To post to this group, send email to automa...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/automate-user.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/automate-user/025945e5-d9ab-42fe-93da-c678e2120a06%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Automate" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> automate-use...@googlegroups.com.

> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/29a89678-e763-4ac8-babb-6f3e03eaabb3%40googlegroups.com.

[Automate developer]

Hmm, may be Android has a timeout on how long the screen lock can be disabled.
If you try a simple flow like this:
        :
  Flow beginning
        |
Screen lock disable
        |
     Delay 9h

The screen lock shouldn't be reneabled from 9h.
However, every time you install or uninstall some permission extension Automate has to restart it's service, then the screen lock will be lost.

>>>> > automate-user+unsubscribe@googlegroups.com.

>>>> > To post to this group, send email to automa...@googlegroups.com.
>>>> > Visit this group at http://groups.google.com/group/automate-user.
>>>> > To view this discussion on the web visit
>>>> >
>>>> > https://groups.google.com/d/msgid/automate-user/04f429ab-1508-4d44-884a-de11c7c7965d%40googlegroups.com.
>>>> >
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>>> --
>>>> Sergio Bossa
>>>> http://www.linkedin.com/in/sergiob
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Automate" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to

>>> automate-user+unsubscribe@googlegroups.com.

>>> To post to this group, send email to automa...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/automate-user.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/automate-user/025945e5-d9ab-42fe-93da-c678e2120a06%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Automate" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> automate-user+unsubscribe@googlegroups.com.

[Sergio Bossa]

I believe it is something weirder than that: it happens randomly (and today didn't happen at all), and it also happens with the Llama app; maybe something related to my phone, I'll see if I can give you better information, thanks for now.

>>>> > automate-use...@googlegroups.com.

>>>> > To post to this group, send email to automa...@googlegroups.com.
>>>> > Visit this group at http://groups.google.com/group/automate-user.
>>>> > To view this discussion on the web visit
>>>> >
>>>> > https://groups.google.com/d/msgid/automate-user/04f429ab-1508-4d44-884a-de11c7c7965d%40googlegroups.com.
>>>> >
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>>> --
>>>> Sergio Bossa
>>>> http://www.linkedin.com/in/sergiob
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Automate" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to

>>> automate-use...@googlegroups.com.

>>> To post to this group, send email to automa...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/automate-user.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/automate-user/025945e5-d9ab-42fe-93da-c678e2120a06%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Automate" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> automate-use...@googlegroups.com.

[Automate developer]

Thanks for reporting it's also an issue with Llama.

If the Automate service is somehow killed off, in a low memory situation, the lock is lost. But Automate uses a "foreground" service, so it shouldn't.

[Sergio Bossa]

I managed to overcome this by forking an "unlock" fiber which loops
over the "device unlocked" condition and keeps unlocking until it's
stopped by the main fiber asking to lock (all this based on a main
"wifi connected" condition).

On a related note, I noticed the "device lock" action doesn't actually
lock if another running fiber disabled the lock: is this expected?
Shouldn't "device lock" *force* the lock screen?

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Automate" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/2c9bf821-9e92-445f-a961-2bb4a827c49d%40googlegroups.com.

[Automate developer]

There is no documentation no how "Device lock" behaves when screen lock is disabled:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#lockNow%28%29

I'd call it a security bug in Android since a device admin should override everything, otherwise it pretty useless.

On Friday, October 10, 2014 11:50:03 AM UTC+2, Sergio Bossa wrote:

I managed to overcome this by forking an "unlock" fiber which loops
over the "device unlocked" condition and keeps unlocking until it's
stopped by the main fiber asking to lock (all this based on a main
"wifi connected" condition).

On a related note, I noticed the "device lock" action doesn't actually
lock if another running fiber disabled the lock: is this expected?
Shouldn't "device lock" *force* the lock screen?

On Thu, Oct 9, 2014 at 11:57 PM, Automate developer
<henrik.l...@gmail.com> wrote:
> Thanks for reporting it's also an issue with Llama.
>
> If the Automate service is somehow killed off, in a low memory situation,
> the lock is lost. But Automate uses a "foreground" service, so it shouldn't.
>
>
> On Friday, October 10, 2014 12:29:40 AM UTC+2, Sergio Bossa wrote:
>>
>> I believe it is something weirder than that: it happens randomly (and
>> today didn't happen at all), and it also happens with the Llama app; maybe
>> something related to my phone, I'll see if I can give you better
>> information, thanks for now.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Automate" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/automate-user/PELR0dtMY9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> automate-user+unsubscribe@googlegroups.com.

[Mark Newton]

I've run into this problem as well. The fiber continues running but the lock screen gets re-enabled randomly after screen off. There doesn't really seem to be a way around it in the flow. I tried making the lock screen disable every time screen was turned on or off to no avail.

[Automate developer]

The only thing i can think of that may cause this, other than a Android bug/timeout, is the Automate background service getting killed by the system.

[Sergio Bossa]

On Wed, Oct 22, 2014 at 5:53 AM, Automate developer
<henrik.l...@gmail.com> wrote:

> The only thing i can think of that may cause this, other than a Android
> bug/timeout, is the Automate background service getting killed by the
> system.

That really looks like it: when the screen lock reappears, I noticed
other flows behave like they have been restarted.

I heard keeping a notification icon will help preventing the system to
kill the app: is that correct? Maybe you could add that as an option?

> On Wednesday, October 22, 2014 3:31:45 AM UTC+2, Mark Newton wrote:
>>
>> I've run into this problem as well. The fiber continues running but the
>> lock screen gets re-enabled randomly after screen off. There doesn't really
>> seem to be a way around it in the flow. I tried making the lock screen
>> disable every time screen was turned on or off to no avail.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Automate" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.

> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/967e2c99-830d-49db-b7b1-0ae72b0b77d3%40googlegroups.com.

[Sergio Bossa]

On Wed, Oct 22, 2014 at 2:31 AM, Mark Newton <markn...@gmail.com> wrote:

> I've run into this problem as well.

If that helps, I solved by unlocking inside a fiber that loops on the
"Device Unlocked?" condition; by doing so, every time the screen is
locked again, for any reason, it will react on the unlock condition,
do the unlock, and loop again to react at the next lock/unlock.

> The fiber continues running but the lock screen gets re-enabled randomly after screen off. There doesn't really seem to be a way around it in the flow.
> I tried making the lock screen disable every time screen was turned on or off to no avail.
>

> --

> You received this message because you are subscribed to the Google Groups "Automate" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to automate-use...@googlegroups.com.

> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.

> To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/3c6a4483-e8f3-4a74-8bb6-7327544e8f16%40googlegroups.com.

[Mark Newton]

That's a good idea. Ill give that a try Sergio. Thanks!

[Automate developer]

Automate does keep a notification, it's required by Android for "foreground" services.
But it's onlt done if the fiber count is greater than zero, otherwise it's okay to kill the service since it's unused.

On Wednesday, October 22, 2014 9:11:38 AM UTC+2, Sergio Bossa wrote:

[Sergio Bossa]

I can guarantee the fibers counter never reached zero in my case, so
it must be something else that allowed the OS to kill it.

> --
> You received this message because you are subscribed to the Google Groups
> "Automate" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/fad4d521-202f-44a7-a134-3b314d1fedd5%40googlegroups.com.

[Automate developer]

Even as a "foreground" service there's no guarantee that the OS won't kill it. But it should be the last to get killed.

On Wednesday, October 22, 2014 8:27:14 PM UTC+2, Sergio Bossa wrote:

I can guarantee the fibers counter never reached zero in my case, so
it must be something else that allowed the OS to kill it.

[Sergio Bossa]

I usually run with 300MBs free out of 1GB, so I doubt the OS killed it
as a last resort to get more memory.

On Wed, Oct 22, 2014 at 8:26 PM, Automate developer
<henrik.l...@gmail.com> wrote:
> Even as a "foreground" service there's no guarantee that the OS won't kill

> it. But should be the last to get killed.

>
> On Wednesday, October 22, 2014 8:27:14 PM UTC+2, Sergio Bossa wrote:
>>
>> I can guarantee the fibers counter never reached zero in my case, so
>> it must be something else that allowed the OS to kill it.
>>

> https://groups.google.com/d/msgid/automate-user/c89d2cca-3eb1-4987-bb67-4fde7ab7cb47%40googlegroups.com.

[Mark Newton]

I thought this was working for a while, but it doesn't. Eventually it stops disabling the lock screen even though the fiber is still running. Then, because it's in a loop to disable the lock screen when unlocked, it creates an insanely large log. Takes 30-40 seconds to load the log into a text viewer on my phone.

It's strange that it starts doing that even though the fiber was never stopped. I can see it reapply disable screen lock but it just doesn't work.

[Sergio Bossa]

On Mon, Nov 10, 2014 at 1:27 PM, Mark Newton <markn...@gmail.com> wrote:

> I thought this was working for a while, but it doesn't. Eventually it stops
> disabling the lock screen even though the fiber is still running. Then,
> because it's in a loop to disable the lock screen when unlocked, it creates
> an insanely large log. Takes 30-40 seconds to load the log into a text
> viewer on my phone.

I believe you should loop when the "unlocked" status changes, rather
than immediately: this means you should manually re-unlock, but at
least it wouldn't fill your log (and above all it wouldn't keep your
process busy).

> It's strange that it starts doing that even though the fiber was never
> stopped. I can see it reapply disable screen lock but it just doesn't work.
>
> On Wednesday, October 22, 2014 3:16:17 AM UTC-4, Sergio Bossa wrote:
>>
>> On Wed, Oct 22, 2014 at 2:31 AM, Mark Newton <markn...@gmail.com> wrote:
>>
>> > I've run into this problem as well.
>>
>> If that helps, I solved by unlocking inside a fiber that loops on the
>> "Device Unlocked?" condition; by doing so, every time the screen is
>> locked again, for any reason, it will react on the unlock condition,
>> do the unlock, and loop again to react at the next lock/unlock.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Automate" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/5a8c60c5-a958-4b55-b75d-f65e3ec28c70%40googlegroups.com.

[Mark Newton]

I've tried it both ways, using when changed mode and both immediate and when changed. The current way I have it set up I've taken a screenshot of and attached to this post. The flow disables the lock screen when connected to a trusted WiFi AP. Rather than re-enabling the lock screen, I have the fiber set to stop when disconnected from wifi, and start a new fork that waits until reconnected to the WiFi AP then starts the disable lockscreen loop again. I attached that process to.

Since the screen lock can only be disabled and re-enabled by the same fiber. I thought this was an ingenious solution, since stopping the fiber also re-enables the lock screen. The setup I have also works around the wifi connected block bug when the SSID and BSSID fields are empty. I'm not sure when it's breaking down since it almost seems random. The fibers never stop running, it just stops working for whatever reason.

[Sergio Bossa]

I can't quite debug your flow from the screenshots (which is actually
the most annoying aspect of Automate: flows are too hard to read and
understand), but according to your description it looks similar to
mine, which basically works as follows:

"main":
when wifi changed:
if connected:
stop "unlock"
enable screen lock
if disconnected:
fork "unlock"
goto "main"

"unlock":
"unlock loop":
when screen unlocked:
disable screen lock
goto "unlock loop"

On Mon, Nov 10, 2014 at 2:22 PM, Mark Newton <markn...@gmail.com> wrote:
> I've tried it both ways, using when changed mode and both immediate and when
> changed. The current way I have it set up I've taken a screenshot of and
> attached to this post. The flow disables the lock screen when connected to a
> trusted WiFi AP. Rather than re-enabling the lock screen, I have the fiber
> set to stop when disconnected from wifi, and start a new fork that waits
> until reconnected to the WiFi AP then starts the disable lockscreen loop
> again. I attached that process to.
>

> Since the screen lock can only be disabled and re-enabled by the same fiber,
> I thought this was an ingenious solution. I'm not sure when it's breaking
> down since it almost seems random. The fiber never stops running, it just
> stops working...

>
> --
> You received this message because you are subscribed to the Google Groups
> "Automate" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/84488cff-c01b-4703-aa2b-a26fd38f898c%40googlegroups.com.

[Mark Newton]

Mine basically works the same way. Mines like this:

<Start flow>
-For each in BSSIDarray > start Fork "WiFi Connected"

<Start WiFi Connected Fork>
-When WiFi connected
-Start Fork "Lock Screen Disable" (Stop when parent fiber stops enabled)
--When WiFi disconnected
--Start Fork "WiFi Connected" (This fork block doesn't have an okay connection so it stops the previously running "WiFi Connected" AND "Lock Screen Disable" forks, this way it also copies the variables into the new fork)

<Start Lock Screen Disable Fork>
-Disable Lock Screen
-Is device unlocked? (No loops to disable lock screen, Yes goes to next step)
-When device unlocked (No loops to disable lock screen)

My flow is available on the community as "Wi-Fi? Disable Lock Screen" if you want to check it out for yourself.

[Automate developer]

The flow in your second screenshot seems flawed.
Why do you Fork just before the "Is screen on"? It seems redundant, and you'll lose the fiber with the screen lock.

On Monday, November 10, 2014 3:22:51 PM UTC+1, Mark Newton wrote:

I've tried it both ways, using when changed mode and both immediate and when changed. The current way I have it set up I've taken a screenshot of and attached to this post. The flow disables the lock screen when connected to a trusted WiFi AP. Rather than re-enabling the lock screen, I have the fiber set to stop when disconnected from wifi, and start a new fork that waits until reconnected to the WiFi AP then starts the disable lockscreen loop again. I attached that process to.

[Automate developer]

When i get the time i'll make an online flow drawing site, to make it easier to help describe a solution.

On Monday, November 10, 2014 4:10:22 PM UTC+1, Sergio Bossa wrote:

I can't quite debug your flow from the screenshots (which is actually
the most annoying aspect of Automate: flows are too hard to read and
understand), but according to your description it looks similar to
mine, which basically works as follows:

"main":
  when wifi changed:
    if connected:
      stop "unlock"
      enable screen lock
    if disconnected:
      fork "unlock"
      goto "main"

"unlock":
  "unlock loop":
    when screen unlocked:
      disable screen lock
      goto "unlock loop"

[Sergio Bossa]

On Mon, Nov 10, 2014 at 7:25 PM, Automate developer
<henrik.l...@gmail.com> wrote:

> When i get the time i'll make an online flow drawing site, to make it easier
> to help describe a solution.

I believe your time would be better spent by improving Automate flow
editing itself :)

Three feature that would greatly improve it imho:
1) Allow to express and save flow sections as "sub-flows", so that
they can be referenced, started and stopped from "main" flows:
breaking down complex flows into smaller sub-flows would make it
easier to edit and understand them, as well as enable reuse; also, I
believe you already have all the machinery to do this (i.e. you could
just start/stop other flows as forks), so it should actually be quite
easy.
2) Enable blocks/connections highlighting, as I suggested on another thread.
3) Undo support.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/0ec9ddea-abe0-4e38-88f6-bb1cb5b09d93%40googlegroups.com.

[Automate developer]

1. Use the "Flow start" block, it works the same way as Fork, but you only pass data as a payload.
2. The blocks should highlight now, when you press and move them. Doesn't that work for you?
   I'll add highlighting of connections when dragged.
   
3. Undo are done, ready for the next release.

On Monday, November 10, 2014 8:35:54 PM UTC+1, Sergio Bossa wrote:

[Sergio Bossa]

On Mon, Nov 10, 2014 at 7:43 PM, Automate developer
<henrik.l...@gmail.com> wrote:

> Use the "Flow start" block, it works the same way as Fork, but you only pass
> data as a payload.

That's not enough: i.e., you can't stop flows the same way as you stop "forks"

> The blocks should highlight now, when you press and move them. Doesn't that
> work for you?

They do highlight, but that's not what I meant: I meant to i.e.
long-press them and highlight the whole block and connections, without
having to hold or drag the block (while right now it requires you to
keep the block pressed).

> Undo are done, ready for the next release.

Cool!

> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/6b0bffe2-47c4-4462-95fb-1d1bf6e3050d%40googlegroups.com.

[Automate developer]

I'll could add the output fiber URI and the Stop with parent option to the "Flow start" block too.
I'll also make it accept relative "Flow URI", relative to the current flow. So the flow can be shared.

Long-press on a block are reserved for the copy & paste, multi-select action.

On Monday, November 10, 2014 8:50:54 PM UTC+1, Sergio Bossa wrote:

[Automate developer]

Each flow log will now include the line "Resumed after service restart" whenever the Automate service gets restarted, that may be caused by Android running low on memory and therefore killed the process.
Whenever you see that line, any screen lock would have been lost.

The only remaining cause would be that Android have an internal timeout on screen locks.

[Mark Newton]

That's what it's suppose to do. When Wifi gets disconnected from the trusted WiFi AP for that fork, it hits the new fork which copies the BSSID variable into that new fork so it can determine when wifi gets reconnected to that specific Wifi AP. The old fork gets stopped when the new fork is created, which also stops the disable lock screen fork.

On Monday, November 10, 2014 2:18:04 PM UTC-5, Automate developer wrote:

The flow in your second screenshot seems flawed.
Why do you Fork just before the "Is screen on"? It seems redundant, and you'll lose the fiber with the screen lock.

[Mark Newton]

I'd like to think memory isn't an issue since I usually always have at least 200MB free on my phone at all times (Usually around 600MB). I dont do a whole hell on a lot on it multi-tasking wise. I also have my OOM values set to basically never kill anything. I'm use to using the back kill button from AOKP days. Thanks for adding the "Resumed after service restart." That should help narrow it down if it is indeed a timer.

[Sergio Bossa]

On Mon, Nov 10, 2014 at 8:06 PM, Automate developer
<henrik.l...@gmail.com> wrote:

> I'll could add the output fiber URI and the Stop with parent option to the
> "Flow start" block too.
> I'll also make it accept relative "Flow URI", relative to the current flow.
> So the flow can be shared.

Cool, I see it's in the new version, I'll give it a try.

> Long-press on a block are reserved for the copy & paste, multi-select
> action.

What about double tapping?

> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/ddb2938f-87a9-4869-a389-3ef569789fe0%40googlegroups.com.

[Mark Newton]

My infinite looping problem appears to be caused by a full restart or shell restart. After Automate boots and resumes the flows, press the power button and relocking the device sends the screen unlock fiber into an infinite loop going:

Disable lock screen > Is device Unlocked (No) > Disable lock screen etc... etc...

[Mark Newton]

I also want to point out that Run on System Startup is disabled in settings.

Ive seen three different outcomes in the log from the flow restarting after a reboot or shell restart. Here they are:

1)This shows the flow erroring after reboot/shell reload.I first unlock the device, start automate, then when I relock the device it shows the lock screen. Because it doesn't disable the lock screen it causes an infinite loop at "Is device unlocked?" It's important to note, that even if I removed "Is device unlocked?" and used only "When device unlocked?" it still wouldn't disable the lock screen like it's suppose to. It would stop the infinite looping, but still not work like it should. It looks to me like resuming the fiber after a reboot causes the disable screen lock block to stop working because it still thinks the previous disable screen lock is still active from before the reboot.

2014-11-11 11:32:45.934 INFO 2747@1: Flow beginning
2014-11-11 11:32:45.942 INFO 2747@29: File exists?
2014-11-11 11:32:45.943 INFO 2747@41: Variable set
2014-11-11 11:32:45.944 INFO 2747@32: File read text
2014-11-11 11:32:45.951 INFO 2747@30: Variable set
2014-11-11 11:32:45.952 INFO 2747@34: Dialog choice?
2014-11-11 11:32:48.365 INFO 2747@35: Expression true?
2014-11-11 11:32:48.366 INFO 2747@36: Expression true?
2014-11-11 11:32:48.368 INFO 2747@51: Expression true?
2014-11-11 11:32:48.369 INFO 2747@197: Expression true?
2014-11-11 11:32:48.370 INFO 2747@16: For each
2014-11-11 11:32:48.371 INFO 2747@166: Variable set
2014-11-11 11:32:48.385 INFO 2747@167: Expression true?
2014-11-11 11:32:48.386 INFO 2747@139: Fork
2014-11-11 11:32:48.399 INFO 2747@16: For each
2014-11-11 11:32:48.400 INFO 2747@170: Delay
2014-11-11 11:32:48.410 INFO 2748@171: Wi-Fi connected?
2014-11-11 11:32:48.412 INFO 2748@188: Fork
2014-11-11 11:32:48.427 INFO 2748@172: Wi-Fi connected?
2014-11-11 11:32:48.435 INFO 2749@190: Screen lock set state
2014-11-11 11:32:48.437 INFO 2749@191: Device unlocked?
2014-11-11 11:32:48.438 INFO 2749@192: Device unlocked?
2014-11-11 11:33:56.198 INFO 2747@170: Resumed after service restart
2014-11-11 11:33:56.199 INFO 2747@170: Delay
2014-11-11 11:33:56.210 INFO 2748@172: Resumed after service restart
2014-11-11 11:33:56.215 INFO 2748@172: Wi-Fi connected?
2014-11-11 11:33:56.233 INFO 2749@192: Resumed after service restart
2014-11-11 11:33:56.234 INFO 2749@192: Device unlocked?
2014-11-11 11:34:03.264 INFO 2749@190: Screen lock set state
2014-11-11 11:34:03.285 INFO 2749@191: Device unlocked?
2014-11-11 11:34:03.297 INFO 2749@190: Screen lock set state
2014-11-11 11:34:03.301 INFO 2749@191: Device unlocked?
2014-11-11 11:34:03.310 INFO 2749@190: Screen lock set state
2014-11-11 11:34:03.311 INFO 2749@191: Device unlocked?
2014-11-11 11:34:03.312 INFO 2749@190: Screen lock set state
2014-11-11 11:34:03.314 INFO 2749@191: Device unlocked?
2014-11-11 11:34:03.315 INFO 2749@190: Screen lock set state
2014-11-11 11:34:03.316 INFO 2749@191: Device unlocked?
2014-11-11 11:34:03.318 INFO 2749@190: Screen lock set state
*Infinite Looping at this stage*

2)Some how a new fiber got started on top of the resumed fiber. This works correctly, but now there are two fibers disabling the lock screen for the same WiFi AP.
EDIT: I'm fairly sure this is the result of me starting Automate before WiFi was connected after booting.

2014-11-11 11:29:57.614 INFO 2743@1: Flow beginning
2014-11-11 11:29:57.618 INFO 2743@29: File exists?
2014-11-11 11:29:57.619 INFO 2743@41: Variable set
2014-11-11 11:29:57.620 INFO 2743@32: File read text
2014-11-11 11:29:57.646 INFO 2743@30: Variable set
2014-11-11 11:29:57.647 INFO 2743@34: Dialog choice?
2014-11-11 11:29:59.464 INFO 2743@35: Expression true?
2014-11-11 11:29:59.466 INFO 2743@36: Expression true?
2014-11-11 11:29:59.468 INFO 2743@51: Expression true?
2014-11-11 11:29:59.469 INFO 2743@197: Expression true?
2014-11-11 11:29:59.470 INFO 2743@16: For each
2014-11-11 11:29:59.472 INFO 2743@166: Variable set
2014-11-11 11:29:59.474 INFO 2743@167: Expression true?
2014-11-11 11:29:59.475 INFO 2743@139: Fork
2014-11-11 11:29:59.509 INFO 2743@16: For each
2014-11-11 11:29:59.525 INFO 2743@170: Delay
2014-11-11 11:29:59.550 INFO 2744@171: Wi-Fi connected?
2014-11-11 11:29:59.554 INFO 2744@188: Fork
2014-11-11 11:29:59.582 INFO 2744@172: Wi-Fi connected?
2014-11-11 11:29:59.605 INFO 2745@190: Screen lock set state
2014-11-11 11:29:59.607 INFO 2745@191: Device unlocked?
2014-11-11 11:29:59.610 INFO 2745@192: Device unlocked?
2014-11-11 11:30:59.709 INFO 2743@170: Resumed after service restart
2014-11-11 11:30:59.710 INFO 2743@170: Delay
2014-11-11 11:30:59.719 INFO 2744@172: Resumed after service restart
2014-11-11 11:30:59.720 INFO 2744@172: Wi-Fi connected?
2014-11-11 11:30:59.740 INFO 2745@192: Resumed after service restart
2014-11-11 11:30:59.741 INFO 2745@192: Device unlocked?
2014-11-11 11:31:18.218 DBUG 2744@2744: NETWORK_STATE_CHANGED_ACTION: CONNECTING
2014-11-11 11:31:20.188 DBUG 2744@2744: NETWORK_STATE_CHANGED_ACTION: CONNECTING
2014-11-11 11:31:20.238 DBUG 2744@2744: NETWORK_STATE_CHANGED_ACTION: CONNECTING
2014-11-11 11:31:20.289 DBUG 2744@2744: NETWORK_STATE_CHANGED_ACTION: CONNECTED
2014-11-11 11:31:20.291 DBUG 2744@2744: SupplicantState: COMPLETED
2014-11-11 11:31:20.353 INFO 2744@188: Fork
2014-11-11 11:31:20.523 INFO 2744@172: Wi-Fi connected?
2014-11-11 11:31:20.540 INFO 2746@190: Screen lock set state
2014-11-11 11:31:20.541 INFO 2746@191: Device unlocked?
2014-11-11 11:31:20.543 INFO 2746@192: Device unlocked?
2014-11-11 11:32:43.232 INFO 2743@170: Stopped by user
2014-11-11 11:32:43.300 INFO 2744@172: Stopped by user
2014-11-11 11:32:43.338 INFO 2745@192: Stopped by parent
2014-11-11 11:32:43.349 INFO 2746@192: Stopped by parent
2014-11-11 11:32:43.361 INFO 2745@192: Stopped by user
2014-11-11 11:32:43.365 INFO 2746@192: Stopped by user

3) The fork stops for some reason and restarts. This makes the flow work correctly.
EDIT: I figured this one out. This is what happens when it resumes the fiber on the "When device unlocked?" block. I have nothing connected to yes, so it stops the fiber. Then starts the new fork when WiFi is connected. Possibly because I waited for the device to fully boot before I unlocked and started Automate?

2014-11-11 11:48:06.382 INFO 2750@1: Flow beginning
2014-11-11 11:48:06.383 INFO 2750@29: File exists?
2014-11-11 11:48:06.386 INFO 2750@41: Variable set
2014-11-11 11:48:06.386 INFO 2750@32: File read text
2014-11-11 11:48:06.394 INFO 2750@30: Variable set
2014-11-11 11:48:06.395 INFO 2750@34: Dialog choice?
2014-11-11 11:48:07.983 INFO 2750@35: Expression true?
2014-11-11 11:48:07.987 INFO 2750@36: Expression true?
2014-11-11 11:48:07.988 INFO 2750@51: Expression true?
2014-11-11 11:48:07.988 INFO 2750@197: Expression true?
2014-11-11 11:48:07.989 INFO 2750@16: For each
2014-11-11 11:48:07.990 INFO 2750@166: Variable set
2014-11-11 11:48:07.991 INFO 2750@167: Expression true?
2014-11-11 11:48:07.996 INFO 2750@139: Fork
2014-11-11 11:48:08.054 INFO 2750@16: For each
2014-11-11 11:48:08.059 INFO 2750@170: Delay
2014-11-11 11:48:08.065 INFO 2751@171: Wi-Fi connected?
2014-11-11 11:48:08.071 INFO 2751@188: Fork
2014-11-11 11:48:08.123 INFO 2751@172: Wi-Fi connected?
2014-11-11 11:48:08.136 INFO 2752@190: Screen lock set state
2014-11-11 11:48:08.138 INFO 2752@191: Device unlocked?
2014-11-11 11:48:08.139 INFO 2752@192: Device unlocked?
2014-11-11 11:48:40.758 INFO 2750@170: Resumed after service restart
2014-11-11 11:48:40.760 INFO 2750@170: Delay
2014-11-11 11:48:40.767 INFO 2751@172: Resumed after service restart
2014-11-11 11:48:40.767 INFO 2751@172: Wi-Fi connected?
2014-11-11 11:48:40.781 INFO 2752@192: Resumed after service restart
2014-11-11 11:48:40.782 INFO 2752@192: Device unlocked?
2014-11-11 11:48:43.497 INFO 2752@0: Stopped at end
2014-11-11 11:48:43.528 DBUG 2751@2751: NETWORK_STATE_CHANGED_ACTION: CONNECTING
2014-11-11 11:48:53.581 DBUG 2751@2751: NETWORK_STATE_CHANGED_ACTION: CONNECTING
2014-11-11 11:48:53.621 DBUG 2751@2751: NETWORK_STATE_CHANGED_ACTION: CONNECTING
2014-11-11 11:48:53.764 DBUG 2751@2751: NETWORK_STATE_CHANGED_ACTION: CONNECTED
2014-11-11 11:48:53.765 DBUG 2751@2751: SupplicantState: COMPLETED
2014-11-11 11:48:53.826 INFO 2751@188: Fork
2014-11-11 11:48:53.929 INFO 2751@172: Wi-Fi connected?
2014-11-11 11:48:53.960 INFO 2753@190: Screen lock set state
2014-11-11 11:48:53.961 INFO 2753@191: Device unlocked?
2014-11-11 11:48:53.963 INFO 2753@192: Device unlocked?

[Automate developer]

As i said earlier:
https://groups.google.com/d/msg/automate-user/PELR0dtMY9Q/mby9DR1Ce7YJ

It's hard for me to interpret, from the logs, whats going on when you execute so many unrelated blocks and forks.

The screen lock works by registering an "lock object" with each fiber when you disable the screen lock. When re-enabled with the screen lock block, or the fiber stops, the "lock object" is removed.
This "lock object" isn't automatically recreated when the Automate service is restarted, so if a restart happens at any of the blocks after the screen lock disable block, the lock is lost.

[Sergio Bossa]

FYI, I noticed when this happens the "resume after restart" message is printed now; by the way, it doesn't restart from the beginning of the flow, but from the block it was interrupted on.

--

You received this message because you are subscribed to the Google Groups "Automate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to automate-use...@googlegroups.com.
To post to this group, send email to automa...@googlegroups.com.
Visit this group at http://groups.google.com/group/automate-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/275ba5f4-c1ba-4d71-ba5e-ff9459d2701f%40googlegroups.com.

[Automate developer]

Is it Android that terminates Automate, or a reboot?

Seems like Android don't care that Automate is a "foreground" service, which should only be killed off as a last resort when memory runs critically low.
Do you regularly swipe await Automate activities from the recent tasks screen?

http://stackoverflow.com/questions/20636330/start-sticky-does-not-work-on-android-kitkat-edit-and-jelly-bean


A flow should restart from the block where it was last!

On Saturday, November 15, 2014 10:59:39 AM UTC+1, Sergio Bossa wrote:

FYI, I noticed when this happens the "resume after restart" message is printed now; by the way, it doesn't restart from the beginning of the flow, but from the block it was interrupted on.

...

[Sergio Bossa]

It was Android apparently killing the service (no reboot). I'm not
sure which activities are you referring to.

> --
> You received this message because you are subscribed to the Google Groups
> "Automate" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to automate-use...@googlegroups.com.
> To post to this group, send email to automa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/automate-user.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/automate-user/df6ea8c6-3962-45ac-8167-25b5897c8cad%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Automate developer]

There seems to be two pretty serious Android bugs, which kills services it shouldn't, even foreground ones!

Bug #1: On the "Recent tasks" screen, the screen of "open" Android apps, if you swipe away an app "activity" there, any background service for that app are also killed.
Bug #2: If an app receives a "broadcast", from an homescreen app widget for example, any service may also be killed.

http://stackoverflow.com/questions/20636330/start-sticky-does-not-work-on-android-kitkat-edit-and-jelly-bean

So i wonder if you regurarly swipe away apps in the Android "recent tasks" screen.
https://code.google.com/p/android/issues/detail?id=63618

On Sunday, November 16, 2014 1:12:41 PM UTC+1, Sergio Bossa wrote:

It was Android apparently killing the service (no reboot). I'm not
sure which activities are you referring to.

[Sergio Bossa]

Nope, I don't usually do that. I wonder if you should try to put an icon for the service, I know you are against that, but maybe you could make it optional?

--

You received this message because you are subscribed to the Google Groups "Automate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to automate-use...@googlegroups.com.
To post to this group, send email to automa...@googlegroups.com.
Visit this group at http://groups.google.com/group/automate-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/b38e6d03-9e98-473f-b4bb-6a2708fffd72%40googlegroups.com.

[Automate developer]

No swiping tasks, good. Then it's not Android bug #1.

Automate has an icon for the service, but only when flows are running. It has the lowest priority so it will be at the bottom of the notification list.
The icon is required the make a "foreground" services, so Android doesn't kill it. But that's obviously not working for you, since Android still keeps killing the service.

On Sunday, November 16, 2014 8:45:12 PM UTC+1, Sergio Bossa wrote:

Nope, I don't usually do that. I wonder if you should try to put an icon for the service, I know you are against that, but maybe you could make it optional?

[Mark Newton]

I'm sure you probably know this. Or have already found and read this from stackoverflow. But just in case you haven't, I'm going to post the link here. The first answer has a ton of good information.

https://stackoverflow.com/questions/6645193/foreground-service-being-killed-by-android

[Automate developer]

Thanks for the link, interesting read.

Android seems to think the Automate service process is a "provider". But the process is much more, all background stuff run in that process.
So much for resource saving, i may have to move the ContentProvider (database) to another process.

[Automate developer]

The next release will save any active Screen lock with the fiber, so if the service is restarted the lock will be recreated automatically.