Android O (bad) changes

220 views
Skip to first unread message

John Doe

unread,
Mar 21, 2017, 3:40:50 PM3/21/17
to Tasker - Developers
In the new android version there are several strict limitations about background processing. It's no more possible to register a broadcast receiver to receive an implicit intent and there are several limitations to execute background task. It seems that Google is trying to push developers to use the job scheduler api. Using a job in a plugin it means it won't be possible (or not reliable at all) to use a sync action. In some cases sync actions in a plugin are really needed, today it's the only way to send the final result of the operation to Tasker. In addition the background limitation means that a plugin has no chance to run normally because by definition it has no activity in foreground. The only way to bypass this restriction would be to have a foreground service but it isn't a good solution to let the user with 10 notifications just to run 10 plugins. It seems crazy to be honest. We are at the beginning since developer preview has been released today, however I would suggest, starting from today, to think an alternative way for the communication between Tasker and a plugin because the current model has several cons with the new android versions.

David Stone

unread,
Mar 21, 2017, 3:52:37 PM3/21/17
to Tasker - Developers
With my Send/Expect plugin and Nougat, I've had several reports that it performs erratically when power saving is enabled.  One user reported that white-listing the plugin restored proper behavior, while another had to disable power saving entirely.

Pent

unread,
Mar 21, 2017, 4:01:29 PM3/21/17
to Tasker - Developers
Thanks for the heads up, sounds ominous.

Will be the first thing I look at when Tasker 4.10 is out of the door in a few weeks, currently
I need all my keyboard time for coding.

It's annoying that Tasker users switch to new Android versions
faster than average users :-) Tasker is on 30% 7.0+ now,
compared to < 3% average.

Pent

John Doe

unread,
Mar 21, 2017, 4:06:02 PM3/21/17
to Tasker - Developers
Ahahah maybe it's just because Tasker users are all geeks :D About the background limitations, the docs says that an app is put on a whitelist when it receives an intent via receivers. However it talks about SMS/MMS, it's not clear if it was just an example or not (at least for me). In the next days I will try to perform some test and I will post any progress on this thread.

Jeremy Kane

unread,
Mar 22, 2017, 1:13:55 AM3/22/17
to Tasker - Developers
To be clear - you cannot register for implicit receivers via the manifest - you still can do so in code. (https://developer.android.com/preview/features/background.html#broadcasts - "Apps can use Context.registerReceiver() at runtime to register a receiver for any broadcast, whether implicit or explicit."

John Doe

unread,
Mar 22, 2017, 1:26:55 AM3/22/17
to Tasker - Developers
yes, it's true but for a Tasker plugin, it would mean that you need a foreground service to receive the intents. I hope Tasker currently send the query and fire intents using explicit broadcast.

Jeremy Kane

unread,
Mar 22, 2017, 1:36:10 AM3/22/17
to Tasker - Developers
Pent - you getting 3% from Google's dashboard? I don't know how they come up with those numbers, but I've found my stats to be much different than those numbers, usually WELL in favor of the newer versions of Android. Seems like they do themselves no favors by reporting the numbers they report, cause the reality seems MUCH better for them than their own numbers. 

I have (or work on) several apps with (fairly) large audience:

500,000 active user app: 20% Nougat, 56% Marshmallow.
18,000 active user app: 27% Nougat, 58% Marshmallow
26,000 active user app: 16% Nougat, 47% Marshmallow
Bluetooth Tasker Plugin (low numbers): 35% Nougat, 43% Marshmallow.

Clearly, you are correct - Tasker users upgrade at a higher rate than others, but I promise you that the biggest app I mentioned does not have an unusually geeky audience, and it's at 20%, which is still well above 3%.

Jeremy Kane

unread,
Mar 22, 2017, 1:43:39 AM3/22/17
to Tasker - Developers
I think I see what you are getting at. Yeah, I guess things could get interesting from here... Even though it might interfere with my own plugin and apps, I am still overall in favor of their efforts, just makes our lives a little more challenging :).

John Doe

unread,
Mar 22, 2017, 2:03:51 AM3/22/17
to Tasker - Developers
I don't understand why they don't provide a runtime permission for background activities, exactly what iOS does. In this case at least can decide, at the moment Google wants decide for us and I'm talking as an Android user in this case.

John Doe

unread,
Apr 23, 2017, 8:29:08 AM4/23/17
to Tasker - Developers
Good and bad news: after a couple of test I hit the illegalStateException after I received the fire intent from Tasker. It means the app is not always whitelisted after an intent is received or maybe the app is whitelisted only when some intent are received. The good news is that the background limitations seems in some way related to the battery optimizations, so if you exclude Tasker and any plugin from battery optimization list, everything works ok again. The only problem is that Google doesn't accept a Tasker plugin with the request ignore battery optimization permission and according to Google Play ToS is not possible to request it, so I think the only think we can do is simple fail if the plugin is not on the whitelist.

Matej Drobnič

unread,
May 19, 2017, 10:02:12 AM5/19/17
to Tasker - Developers
So "frozen" apps can't even receive intents from FOREGROUND apps? That sounds like a pretty big deal for many use cases, not just Tasker. We should make a thread on Google's issue tracker for this.

John Doe

unread,
May 20, 2017, 4:14:03 AM5/20/17
to Tasker - Developers
"frozen" apps can receive intents of course but they can't start a service in background, they can start a foreground service using Context.startForegroundService(). I'm not sure if with DP2 is now possible to exclude an app from background limits using the option in the battery stat. However the fallback at the moment is to start the service in foreground, there isn't any alternative.

John Doe

unread,
May 20, 2017, 4:14:55 AM5/20/17
to Tasker - Developers
Just a note: they can receive **explicit** intents.

Matej Drobnič

unread,
May 20, 2017, 4:15:55 AM5/20/17
to Tasker - Developers
Does that mean that they can still run for couple of seconds when broadcast receiver is executed?

John Doe

unread,
May 20, 2017, 4:17:14 AM5/20/17
to Tasker - Developers
10 seconds but if you need to do some network operation for example you can't do it in the receiver

Matej Drobnič

unread,
May 20, 2017, 4:19:17 AM5/20/17
to Tasker - Developers
That doesn't sound so bad then. Or am I missing something?

Sure, it will be a hassle to modify it at first, but then plugin could just run temporary foreground service, do the stuff it needs to do and then terminate itself.

John Doe

unread,
May 20, 2017, 4:26:01 AM5/20/17
to Tasker - Developers
Yep, not the best thing to have always a notification for the background work. If your task uses 10 action with 10 10 plugins, you could see 10 notifications. The best thing would be a modification of the protocol. Tasker could bind services in the plugin instead of sending an intent, calling a specific interface with AIDL. In this case the service should run in the context of a foreground aoo.
However the most important thing for the user is to have a way to allow the app to execute its job in background. Now it seems possible excluding the app from battery optimizations.

Matej Drobnič

unread,
May 20, 2017, 4:30:43 AM5/20/17
to Tasker - Developers
But tasks execute sequentially, right? So you would see 1 notification at the time.

Plus task actions are generally pretty short (I don't I have actually seen task action that runs past the few seconds, but I guess they are out there), so user might not see the notifications at all, if they execute quickly.

You make a good point though, that this could all be avoided by changing the protocol. Thanks for the explanation.

John Doe

unread,
May 20, 2017, 4:35:15 AM5/20/17
to Tasker - Developers
An async action (i.e. 0 timeout Tasker action) starts the operations on the plugin side but Tasker doesn't wait for completion so next action is executed. It's an extreme scenario of course but the protocol should be really updated. In addition when the screen is off, the system can delay broadcast intents, binding a service should avoid that. Another pros: intents can return only limited data to Tasker because intents payload is limited, using a direct interface with AIDL overcome this problem.
Reply all
Reply to author
Forward
0 new messages