starting a headless task is expected to run on UI thread:

@chirag04 thanks for the note. However, as I understand, one of the common uses of this is performing tasks triggered by a push notification (or a job schedule). These are clearly not required to run in a UI thread as these are background activities.

@oriharel according to the documentation, HeadlessJS is meant for tasks that are needed to be ran when your app in the background. In which case there are no operations on the main thread.

By default, your app will crash if you try to run a task while the app is in the foreground. This is to prevent developers from shooting themselves in the foot by doing a lot of work in a task and slowing the UI. You can pass a fourth boolean argument to control this behaviour.

Exactly. This is why I don't understand the "startTask must be triggered from the UI thread" requirement. Unless there is some limitation forcing the React context to be spawned from the UI thread.

That means you can not trigger a headless task from another headless task (threads of threads).

In the documentation, it is clearly stated -

Now, whenever you start your service, e.g. as a periodic task or in response to some system event / broadcast, JS will spin up, run your task, then spin down.

Which means, even if a BroadcastReceiver is triggered, say from a push notification, the Headless task should be able to perform.

But this is not the case, because there is an underline requirement that the onReactContextInitialized event handler will be called from the main thread (AKA UI thread). A requirement that most of the time not fulfilled (for example, when a user swiped out the app from the recent apps menu).

So in fact - I DO consider this a bug and updated the form.

+1

I think there's a bit of confusion here. The "UI" thread is simply the "main" thread of an Android application. It's the thread that Services naturally run on. For various reasons, the React context is always initialized on this thread, from where it spins off two others: JS and modules (IIRC). This is why startTask needs to be run on the UI/main thread, because it might need to initialize the context.

If you're on a background thread it should be fairly easy to post something to the main one and call startTask there. Is there a reason why that wouldn't work?

You're right, everything I said about the UI thread actually reffers to the main thread. The Service "onStartCommand" does indeed happen on that thread. However, inside startTask there is an asynchronic call to create the React context. The callback that is triggered asynchronically is no longer on that thread. And that is already a private area so we can't override this in our inheriting class.

An updated pull request here.

+1

Issue is now fixed and merged to React Native.

I have used latest version i.e 0.48.4 of react-native, still, I don't see your changes in File HeadlessJsTaskService.java.

I don't think it's released yet

Hi. I tried to fix this file manually, but i got another error.

My code

BackgroundJob.register({
        jobKey: exactJobKey,
        job: () => process()
    });

    BackgroundJob.schedule({
        jobKey: exactJobKey,
        period: 900000,
        override: true,
        allowExecutionInForeground: true,
        persist: true
    });

Check your AppRegistry in js code. You need to register a js file before you call it from Java

Also check your HeadlessJsTaskService implementation in Java. Make sure you return new HeadlessJsTaskConfig with a name "exactJobKey".

Thanks. Looks like this issue is fixed in 0.49.5.