Profile detecting an app open (regardless of focus)

[Alan Rouse]

Hi,

I want my phone to stay unlocked when a particular application is in use.  I'm managing the locking aspect with AutoTools (changing the lock delay) and that is working fine.

However the profile is not working as I want.  The Tasker profile is detecting whether this app is in focus, not simply whether it is open.  From time to time while using that app, I will switch to another app or the home screen. Because Tasker is monitoring the focus, it fires the task to turn locking back to normal.  I want it to stay in unlocked state (long locking timeout) until I close the application.  If the screen times out and turns off while on the home screen, with my app still open but off screen, I don't want the phone to lock.

How can I do that?

Thanks!

Alan

[Marta Hintz]

make another profile so when you close the app you create a close variable. Then in the first profile it checks for that variable.

[Rich D]

However the profile is not working as I want.  The Tasker profile is detecting whether this app is in focus, not simply whether it is open. 

For native Tasker actions you can use this.

https://www.reddit.com/r/tasker/comments/3snleu/distinguish_between_app_running_in_background_and/

However several plugins will give  a list of backgrounded apps.

So you would need to run a loop and test for your backgrounded app ever x seconds. 

[Robert Ryan]

What Android version are you using? Are you trying to do this by using the services tab of an application context?

I think detecting background apps using this method is nerfed in Android 8+ because ActivityManager.getRunningServices() was deprecated.

Reference: https://developer.android.com/reference/android/app/ActivityManager#getRunningServices(int)

[Alan]

I'm using Nougat.  Apparently access to running apps requires root on Nougat, based on the messages I get from KC Tasker Process Running.  I've reverted from rooted Marshmallow to stock Nougat in hopes of getting Oreo OTA so I'm trying to avoid rooting for now. Tradeoffs....

For now, I'm using the builtin Apps profile to detect what's in focus. 

[Brad Minion]

When you selected the app did you turn on both "Activity" and "Services"?

--
You received this message because you are subscribed to the Google Groups "Tasker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tasker+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/d/optout.

[Alan]

I tried turning on both "Activity" and "Services".  But the services appear to continue after the app closes, so the task to reset the locking delay doesn't fire. 

Maybe it would fire eventually but that's not the behavior i was trying to create.

On Wednesday, July 25, 2018 at 8:56:17 AM UTC-4, Brad Minion wrote:

When you selected the app did you turn on both "Activity" and "Services"?

On Tue, Jul 24, 2018 at 11:19 AM, Alan <alan....@gmail.com> wrote:

I'm using Nougat.  Apparently access to running apps requires root on Nougat, based on the messages I get from KC Tasker Process Running.  I've reverted from rooted Marshmallow to stock Nougat in hopes of getting Oreo OTA so I'm trying to avoid rooting for now. Tradeoffs....

For now, I'm using the builtin Apps profile to detect what's in focus. 

On Tuesday, July 24, 2018 at 12:10:48 PM UTC-4, Robert Ryan wrote:

What Android version are you using? Are you trying to do this by using the services tab of an application context?

I think detecting background apps using this method is nerfed in Android 8+ because ActivityManager.getRunningServices() was deprecated.

Reference: https://developer.android.com/reference/android/app/ActivityManager#getRunningServices(int)

--
You received this message because you are subscribed to the Google Groups "Tasker" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tasker+un...@googlegroups.com.

[Alan]

How do I create a profile to detect when an app closes?

[Duck Redbeard]

Make an exit task for an app context

[Alan]

I have an app context for that app coming into focus, and another for it going out of focus.  I can't make an app context for the app closing.

If I put an exit task on the app coming into focus, it will fire immediately after setting the long locking delay.  So I could set a variable there.  But I have no way to unset the variable when the app closes.

[Duck Redbeard]

Exit task of app context could be to clear the variable if it is user created variable.

[Alan]

But that will be fired whenever the app goes out of focus, not just when the app closes.

[Duck Redbeard]

Are you in and out of this app when you say it is out of focus? Would you consider a time out or expiration period? Like if it is in the background for more than 3 hours consider it to be not in use.

[Alan]

I currently have it setting the timeout to 2 hours when it is in focus, and to 5 seconds when it is out of focus.  I think you're suggesting that I set a timer when it goes out of focus, and wait until it has been 3 hours (etc) before setting it back to 5 seconds.  In effect that means the phone will not lock until two hours after I close the app (long timeout) and the short timeout won't be set until 3 hours after I close the app.  Do I understand right?

If so, then I prefer the behavior I already have just monitoring the focus.

[Duck Redbeard]

Just looking for other ways to create a reference for that app's status. Never did anything like this.

[Rich D]

As Robert stated the ability to get all "recent" "currently running" apps was depreciated.  For security reasons I would imagine. I thought you could get this from the shell 'dumpsys' . You could try poking around in there. 

[Alan]

Yes that ought to be possible.  But it requires root.  I think I'll settle for the in-focus, out-of-focus approach for now.

Thanks to everyone for the discussion.

[Rich D]

Yes that ought to be possible.  But it requires root. 

Not any more!!!!   If you grant tasker 'secure settings'  you can now get access to dumpsys.  This might be still in the beta, Not sure..

[Alan]

Looks like it's included here.

https://joaoapps.com/my-first-public-tasker-release/

I'm still not sure how it can be available without root.  I would think the locked bootloader + stock selinux would block access to settings from an app context.  But maybe someone has tried it and can confirm otherwise.  All I know is that KC Tasker Process Running is reporting that it needs root to do that even though Tasker has been granted WRITE_SECURE_SETTINGS.

[Rich D]

I'm still not sure how it can be available without root.  I would think the locked bootloader + stock selinux would block access to settings from an app context.  But maybe someone has tried it and can confirm otherwise.

I have not been able to grant secure settings ( no access to PC) so I have not been able to test as of yet. I was very exited to see this possibility because I used dumpsys  frequently on my old rooted device. 

[Alan]

The purpose of locking the bootloader is to prevent things like we want to do.  If apps like Tasker can modify the security parameters of your phone, so can malware.   In a locked-bootloader phone, those things are prevented by a combination of conventional user access controls and selinux policy. The locked bootloader won't boot the next stage unless it passes a cryptographic digital signature test proving that it has not been altered.  This is what's known as "Secure Boot". The only way we are able to alter the system is to unlock the bootloader to bypass those tests.  Then we have to alter access control policy / selinux policy which is built into the stock kernels to permit what we want to do.  But you can't do those things without unlocking the bootloader and rooting the phone.  At least that's how I understand it.

[Alan]

The "news" in all this for me is that detecting background apps is considered a security risk and so it is prevented by stock security policy. I don't quite get why that is a security risk, but apparently the stock security policy is blocking it, at least in stock Nougat.

[Rich D]

Not sure how you are doing the work around, However I would suggest having 2 profiles, something like this. 

Profile: App in focus

Context: App

Enter Task: 

1. Stop

Exit Task:

1. Enable profile : App Timer

2. Variable set %App_exit_time TO: %TIMES

Profile: App Timer

Context: Time - Every 2 min 

Task:

1. If %TIMES - %App_exit_time > 900 

2.       Do your app off stuff

3.       Disable profile App Timer

4. End if

[Rich D]

Hit send to soon :/

Forgot...  you need to check if app is currently in focus as well...

Profile: App in focus

Context: App

Enter Task: 

1. Stop

Exit Task:

1. Enable profile : App Timer

2. Variable set %App_exit_time TO: %TIMES

Profile: App Timer

Context: Time - Every 2 min 

Task:

1. If %TIMES - %App_exit_time > 900 

         &  %PACTIVE !~ *,App in focus,*

[Alan]

Thanks for the example combining exit task, timer, and passing a variable.  So, if I understand right, when I close the app, or when it goes out of focus, in 900 seconds the locking delay will be reset to five seconds (my normal value). That's a viable scenario depending on the use pattern of the app. 

Or if I just use in-focus and out-of-focus to set the locking delay, it will reset to five seconds immediately when the app goes out of focus. 

The screen timeout delay also comes into play, because "screen off" starts the locking delay timer.  I'm not too concerned about what happens when I manually turn off the screen, since I can make sure the app has focus when I do that (and therefore a long locking delay is set).  I can set the screen off delay to a long enough value so it doesn't time out with the app out of focus in my normal use of the app.  That's what I'm currently doing.  It doesn't have a real impact on battery life in my usage pattern since I am in the habit of turning off the screen manually when I'm not interacting with it.

The app in question is a GPS based app which I use for mapping my hiking routes.  I stop frequently to take a picture or to use other apps, keeping the hiking app open in the background. But I always (theoretically) bring the hiking app back into focus and turn off the screen to continue the hike. The issue comes during breaks in the hike, when I may use other apps as I eat lunch etc.  I want the phone to stay ready for a quick picture and I don't want to have to fiddle with an unlocking pattern first.  I also don't want to use the phone's built-in quick camera feature because pictures taken that way are not attached to the map by the GPS app.  FWIW...

[Alan]

But what happens if the app goes out of focus (starting the 900 sec timer) and then comes back into focus?  I think the timer continues, and eventually sets the locking delay to 5 seconds even though the app is been back in focus at that time.  There could even be multiple timers running due to coming in and out of focus.  Seems like a problem.

[Rich D]

But what happens if the app goes out of focus (starting the 900 sec timer) and then comes back into focus?  I think the timer continues, and eventually sets the locking delay to 5 seconds even though the app is been back in focus at that time.  There could even be multiple timers running due to coming in and out of focus.  Seems like a problem.

I don't think there will be a issue. Here is how the flow should work. 

- open app

  main profile goes active

      enter task runs

     

- app looses focus

   main profile goes inactive

      exit task runs

         timer profile starts the 900 sec timer and checks every 2 min

            if you do not open the app again then after 900 sec you screen lock will set

-open app again

    enter task runs

       timer profile keeps checking every 2 min untill end of 900 sec. 

           900 sec expired but app is still in focus so if condition is still false because main profile is still active so timer keeps checking untill app loses focus.

- app looses focus

   main profile goes inactive

      exit task runs and resets the variable so timer is reset to 900 sec. 

            if you do not open the app again then after 900 sec you screen lock will set

The 900 sec timer will have a +/- of 2 minutes because the timer activation interval. 

This should ensure you screen lock will not be activated for at least 900 sec (+/- 2min) any time your app loses focus or is exited no matter how many times you open and close it. 

Did I miss any potential scenarios.?

[Alan]

I'm pretty new to Tasker and maybe I misunderstand how profiles work. But it is my understanding that Tasker detects entering the defined state for the Profile, and when that occurs it fires the task.  So it's not being in the state that causes the task to run, but *entering* the state. It's the transition into the state, not the continuing of the state.

So, in your scenario, if I enter the state where the app has focus, the task fires.  Now if I leave the state, and enter it again, a second task fires.  And if I repeat this five times in a minute, the task fires five times.  

Now, five tasks are running, each waiting on a 900 second timer, each with a different start time.  So each will eventually (at different times) check to see whether to reset the locking delay. Meanwhile suppose I continue to use the app in my normal pattern. If one of them happens to do the test while the app is out of focus, the locking delay will be reset.  Subsequently, my experience will be that it is essentially random whether I'll experience the short or long locking delay on the next screen off.

[Duck Redbeard]

From the user guide:

Collisions
Sometimes a task needs to be executed of which a copy is already executing. This can happen quite often e.g. when a task widget button is pressed twice quickly, or a task contains a Wait action or shows a dialog.
The way in which a collision is resolved is specified by the user. There are 3 options:

the new task is ignored (the default)
the existing task is aborted and the new one starts from its first action. The current action of the previous task is finished if it is already being carried out.
both tasks run simultaneously
Note that the last option can lead to several copies of a task all running at once.

[Alan]

Ah, interesting.  Thanks for enlightening me.

So, if there is a single instance of the 900 second timer running, and I'm using the app with it going into and out of focus in my normal pattern, I'll still get different results depending on whether the app happens to be in focus or out of focus at the moment the 900 second timer expires.  Right?

[Duck Redbeard]

If you select "abort existing task" it will kill the one already running and start the new one, which in effect resets that timer.

[Alan]

Ok, thanks.  I'm learning a lot of new things at once here.  Thanks for your help!

[Rich D]

There could be some confusion with the term 'timer'. We do not actually have a timer  running, we are just using a every 2 min time profile to check the real world time against a starting point in time and the start point time is reset whenever the app loses focus Wich resets the time interval. 

 

So, if there is a single instance of the 900 second timer running, and I'm using the app with it going into and out of focus in my normal pattern, I'll still get different results depending on whether the app happens to be in focus or out of focus at the moment the 900 second timer expires.  Right?

Correct. 

If in focus then nothing will happen, the time loop will continue and when it loses focus the variable is reset and another 900 sec interval begins.

 If out of focus then the 'if' condition will be true an your screen lock should be set and the time profiles will be disabled. 

On Saturday, July 28, 2018 at 2:46:30 PM UTC-4, Duck Redbeard wrote:

From the user guide:

Collisions
Sometimes a task needs to be executed of which a copy is already executing. This can happen quite often e.g. when a task widget button is pressed twice quickly, or a task contains a Wait action or shows a dialog.
The way in which a collision is resolved is specified by the user. There are 3 options:

the new task is ignored (the default)
the existing task is aborted and the new one starts from its first action. The current action of the previous task is finished if it is already being carried out.
both tasks run simultaneously
Note that the last option can lead to several copies of a task all running at once.

--
You received this message because you are subscribed to the Google Groups "Tasker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tasker+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/d/optout.