Android 14 requires a foreground service type for startForeground

[KieronQuinn]

As of Android 14, all foreground services need a type.

Currently, when targeting 14, you get this exception when running a plugin:

E  FATAL EXCEPTION: main
E  Process: com.kieronquinn.app.smartspacer.plugin.tasker, PID: 10215
E  android.app.MissingForegroundServiceTypeException: Starting FGS without a type  callerApp=ProcessRecord{faa457f 10215:com.kieronquinn.app.smartspacer.plugin.tasker/u0a567} targetSDK=34
E      at android.app.MissingForegroundServiceTypeException$1.createFromParcel(MissingForegroundServiceTypeException.java:53)
E      at android.app.MissingForegroundServiceTypeException$1.createFromParcel(MissingForegroundServiceTypeException.java:49)
E      at android.os.Parcel.readParcelableInternal(Parcel.java:4870)
E      at android.os.Parcel.readParcelable(Parcel.java:4852)
E      at android.os.Parcel.createExceptionOrNull(Parcel.java:3052)
E      at android.os.Parcel.createException(Parcel.java:3041)
E      at android.os.Parcel.readException(Parcel.java:3024)
E      at android.os.Parcel.readException(Parcel.java:2966)
E      at android.app.IActivityManager$Stub$Proxy.setServiceForeground(IActivityManager.java:6761)
E      at android.app.Service.startForeground(Service.java:775)
E      at com.joaomgcd.taskerpluginlibrary.runner.TaskerPluginRunner$Companion.startForegroundIfNeeded(TaskerPluginRunner.kt:77)
E      at com.joaomgcd.taskerpluginlibrary.runner.TaskerPluginRunner$Companion.startForegroundIfNeeded$default(TaskerPluginRunner.kt:73)
E      at com.joaomgcd.taskerpluginlibrary.runner.IntentServiceParallel.startForegroundIfNeeded(IntentServiceParallel.kt:25)
E      at com.joaomgcd.taskerpluginlibrary.action.IntentServiceAction.onHandleIntent(ActionReceivers.kt:24)
E      at com.joaomgcd.taskerpluginlibrary.runner.IntentServiceParallel.onStart$lambda-3(IntentServiceParallel.kt:66)
E      at com.joaomgcd.taskerpluginlibrary.runner.IntentServiceParallel.$r8$lambda$f5iZS9-kgufLZQgCE7KMiNChUM8(Unknown Source:0)
E      at com.joaomgcd.taskerpluginlibrary.runner.IntentServiceParallel$$ExternalSyntheticLambda2.run(Unknown Source:4)
E      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:487)
E      at java.util.concurrent.FutureTask.run(FutureTask.java:264)
E      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
E      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
E      at java.lang.Thread.run(Thread.java:1012)

Note that the services declared in the manifest must also have this type, I suggest maybe the special use one might be best. Unsure how this would be taken in Play review though.

[joaomgcd]

Thank you for the heads up. Fixed in 0.4.9!

I did set it to android:foregroundServiceType="specialUse". Let's see if Google has any issues with that!

[Tolriq]

@joaomgcd See https://developer.android.com/about/versions/14/changes/fgs-types-required#special-use we are supposed to also add the property and this will all go through a google form very soon :(

If this road is chosen then the value should be well defined and we should already prepare a talk to convince Google, this will be a nightmare as each and every time :(

[KieronQuinn]

You can override the service declaration in your manifest with your own description and the manifest merger will merge it. The important thing in this fix was the code.

[Tolriq]

I perfectly know that, but you missed the important part: Google Form to publish in Play Store in a couple of months or less depending on their decisions.

If all apps puts random things there it will be harder to have a common ground discussion with Google so that they accept the permission and not reject your app and you'll be wondering what to do in that case.

The specialUse case is for certain one that will be under the form and will be the harder to get validated by the dumb support team.

[KieronQuinn]

I don't read it as that. I read it as it's a freeform field to put your use for it, like how it is in the various forms on the Play Console. I think having a shared one would actually be detrimental as they'd view it as either spam or potentially malicious if everyone submitted the same generic "This is for Tasker" reason.

[Tolriq]

The use is the same for everyone as it's the same library and the same service name.

I suppose you never had to deal with Google support for permission forms and the joy it is. At 99,99% the answer will be rejected, we can not confirm that this is a core feature of your application. The reviewer barely speak English and everything needs to be very simple sentences. Try to explain this is to allow automation from another app named tasker.

[KieronQuinn]

I regularly deal with Google's policy team, in fact I spent much of last week arguing with them to turn on a VPN because they indeed do not read what is in front of them. This was for an app with 1.2 million users and was blocking an important update - they are useless.

However, I reiterate, I do not think sending the same message from multiple apps to them is a very good idea. Their ideas of "spam" are very rudimentary, and I'm pretty confident this would fall under them. The use is not the same for everyone, plugins do not all do the same thing. For example, the plugin at the root of this thread is for allowing Tasker to update and modify components of my app to effect what is displayed in a widget - it's not just "Allows Tasker to work with my app". They are more likely to approve an app-specific description than one they've seen before from another app.

[Tolriq]

Well I'll let you discover then when they tell you that you do not need a foreground service for that.

Tasker is foreground if it binds to our service for your need you do not need to go foreground.

To update widget they will tell you work manager that is made for this. The concept of other app calling your app won't matter. That's why yes it matters to explain why tasker needs to start a foreground service to communicate with our app even if in most case it actually don't.

[KieronQuinn]

You've essentially just proven my point. If I were to use a generic message, they would indeed ask why I need a foreground service to update a widget. That is why it should be custom, so you can provide a explanation of why it is needed. Just saying "oh it works with this app called Tasker" would most likely just be rejected, whereas a detailed message about what the Tasker integration provides and why a separate service is needed would be far, far better.

Anyway, since we're never going to reach an agreement on this, how about as a compromise there could be a generic reason in the library, with a strong emphasis of overriding it with your own. If you want to run the risk of using a generic message, that's on you. But when in a year they blanket ban every app with the generic message because it's deemed "spam" or because one of them was doing something deemed malicious and therefore they're all connected, don't say you weren't warned.

[Tolriq]

I'll remove the plugin and tell user to call my API instead.

And the explanation will be on the form that you fill not in the 20 char you'll use there.
So yes having all tasker services using the same explanation that you justify in the form will. It's easier to keep the service name via R8 to ensure Google is aware than having each and every user explaining that no we do not need foreground but Takser current API requires ven if in fact it does not

Future will tell but 12 years on Play Store touching with many perm form we already know it will be a shit show. They want the end of foreground services.

[KieronQuinn]

The developer page specifically asks for the explanation to be in the manifest, and asks you to provide enough information in it alone - putting a brief explanation in here and expecting them to read the form will probably not go well

I agree the service name will stay the same - it will have to - but the use case does not need to.

And yes, they are doing everything they can to kill off foreground services. The Play Store is minefield to submit to nowadays, which is why I no longer submit personal projects due to the risk of their stupid "association" bans impacting my work, because one test phone was on the same IP once or something ridiculous like that. It's bad enough having to communicate with the policy team for large apps, let alone small ones.

[Tolriq]

Again there is no need for the service to be foreground for 99% of the cases. So either we can have a default communication or most people will be rejected. Tasker is foreground if it binds to our service we are foreground too.

So the actual real solution is to fix the API to not require foreground when not needed, not hoping that everyone will be able to pass a dumb review system handled by monkeys. This will be frustration for the whole Tasker eco system with no benefits.

[joaomgcd]

Sorry for the late Response.

@Tolriq foreground services are required if the actions done in the service take more than 5 seconds to complete.

Unfortunately you can't really control how much time your service will take because sometimes users' devices are slow and will take a long time to perform even trivial operations.

Because of this I thought it would be appropriate to make foreground services a requirement?

What do you think?

Also, ( also for @KieronQuinn ) just thinking here: since not all plugins require actions or conditions (a plugin could only have an action or a condition and not both) I shouldn't declare the services at all in the plugin library's manifest, right? Because if I do, plugin developers will have to justify services that they don't even use. Am I thinking correctly?

[Tolriq]

@joaomgcd I don't know Tasker internals but since tasker is foreground it can just bind to the service and do not have any limitation in times. The 5 second limit for a service is the time to go foreground if you call startforeground else it ANR. But this is another story since you can bind and not call startForeground at all. (https://developer.android.com/guide/components/foreground-services#background-start-restriction-exemptions)

For the other question, yes if there's things that does not require the foreground services at all clients should not be forced to deal with the stupid Google review team.

One way could be to split the library in 2 parts so that it's clear what requires it (if it really requires) and what does not.

But really the question is are the services really needing the foreground here? I'm pretty sure we can solve this without foreground at all.