will Tasker eventually implement profiles based on "android.app.usage" API ?

[CoolRaoul]

I always had reliability issues with Tasker "Application context" based profiles (for instances they doesn't trigger at all when display is forced in "immersive mode")

Meanwhile, I've noticed that other applications (like this one for instance), which use a different approach, based on "android.app.usage" Android API are much more reliable regarding detecting foreground running app.

I think it would be very useful that un upcoming Tasker version supports this method (maybe with a simple on/off toggle in the "Application context" app selection UI)

Alternatively a plugin would be a suitable workaround but I've unable to find one.

[Pent]

Hadn't seen that API.

As far as I can see (please correct me if I'm wrong), there's no way to register for updates so Tasker
would have to query that API a couple of times per second.

Pent

[CoolRaoul]

I'm pretty sure that it can be event driven.

And in any case, a polling approach should neve be requided.

There is a bunch of java code samples here: http://www.programcreek.com/java-api-examples/index.php?api=android.app.usage.UsageEvents

A thread with loop based on that kind of code could be not so much ressource intensive I guess:

while (events.getNextEvent(event)) {
      if (event.getEventType() == UsageEvents.Event.MOVE_TO_FOREGROUND) {
        // do some stuff
      }
      if (event.getEventType() == UsageEvents.Event.MOVE_TO_BACKGROUND) {
        // do some stuff
      }
}

[Pent]

I'm pretty sure that it can be event driven.

If you find some code let me know, I don't see it.

Whether polling is resource intensive depends what Android is doing behind the function
calls.

Tasker used to use polling however, it's probably not that bad as a backup solution for
ROMs that have trouble keeping an accessibility service running (looking at you, Samsung).

Pent

[CoolRaoul]

Unfortunately, even though I've good knowledge of programming in others areas, Android Java development is not one of my skills.

But in any cases, among every applications I've tested which are able to change state depending of the foreground application, ones which use that API (which can be detected by their presence in Settings -> "Security" -> "Apps with usage access"), are very little CPU ressource intensive as far as I've been able to notice.

That's what I thought, that Tasker could optionally use this method as an effective way to implement the "application context" state

Meanwhile, I think I've found a, pretty much obfuscated but working, way to do what I need.

Ut works by using "Sleepless in AP" and autonotification apps.

The first one is able to selectively disable screen timeout (side effect but I can live with that) for selected applications. When such an app is detected, it creates a notifications with text "<appname> currently prevent the device sleep". So I'm able to intercept the notification text using autonotification, extract app name and set a global variable (%FGRND_NOSLEEP_APP for instance) accordingly.  and have n associated profile activated.

It seem to work but I would have preferred to find a way to make this works entirely using Tasker.