0

My works scheduled in the WorkManager are not always being executing when the app in the background. This is how I schedule them:

    Constraints myConstraints = new Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build();

    OneTimeWorkRequest batchingWork = new OneTimeWorkRequest.Builder(BatchingJobWorker.class)
            .setConstraints(myConstraints)
            .setInitialDelay(minLatencyJobs, TimeUnit.MILLISECONDS)
            .setBackoffCriteria(BackoffPolicy.LINEAR, 10 * 1000, TimeUnit.MILLISECONDS)
            .addTag(BATCHING_JOB_WORK)
            .build();

    WorkManager.getInstance(context)
            .enqueueUniqueWork(BATCHING_JOB_WORK, ExistingWorkPolicy.APPEND, batchingWork);

I read from this other thread that the problem could be that the Android operating system could be killing / force stopping the app so that the services, schedulers, alarms, broadcast receivers, etc., are no longer working.

However, in my case I'm scheduling the job from a background service and the delays I'm setting are small (1 min or less), so I know that the app is running at that moment. Also, I'm testing this with my testing devices, so I know no one is killing the app by swipping it from the recents menu. This is the exact procedure I'm following:

  1. An MQTT message is received in the background service
  2. I request a PARTIAL_WAKE_LOCK
  3. Some code is executed (I know this code is being called, so I suppose the MQTT and background service part is working fine).
  4. I schedule the work in the WorkManager.

As I said, in some cases the doWork() of the worker is not executed. These are some tests I did:

  • When the work is scheduled in a running activity with a button click and the app is in foreground, it works as expected.
  • Disabling the battery saver mode in some phones seems to help, but It doesn't fix the problem in 100% of the cases.
  • Some smartphones or ROMs seem to have higher probability of executing the scheduled work.
  • When the worker doesn't executes I don't see any exception in the log.
  • The failure probability seems to increase with the amount of previous jobs executed in the background. In fact, when no more works are being executing, usually reinstalling the app fixes the problem.
  • With the device connected to power seems to work better.

Could anyone with me a clue about what is happening here? Am I doing something wrong?

Thanking you in advance.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Xoán
  • 1
  • 2
  • with the policy as ExistingWorkPolicy.APPEND it's hard to know what exactly worker running if your app scheduled too much Worker, do you really want to APPEND instead of REPLACE? – Công Hải Jul 08 '20 at 09:36
  • @CôngHải I used APPEND as it's the most obvious way to do it with my use case, but I can adapt it and use REPLACE instead. I'll give it a try, thanks! – Xoán Jul 08 '20 at 09:55
  • With REPLACE I don't notice any difference. Should I use `beginUniqueWork` instead of `enqueueUniqueWork`? I cannot find the difference between the two. Is `beginUniqueWork` going to respect the initial delay as `enqueueUniqueWork` does? – Xoán Jul 10 '20 at 12:27
  • Maybe this could help https://medium.com/nala-money/the-bifurcation-of-android-6fa1cced074d and https://dontkillmyapp.com/ – kenn Jul 10 '20 at 12:58
  • @kenn Thank you for that article. However, after reading it, I'm affraid there could be no solution for my problem. – Xoán Jul 16 '20 at 06:25
  • As a temporary solution I'm going to add the guides from https://dontkillmyapp.com/ to my app so the user can whitelist it. But I found this strange, because when the service runs the application is alive, but then the work is not executed. – Xoán Jul 16 '20 at 06:28
  • The best solution would be to use firebase, also adding it in the app docs is also wise. – kenn Jul 16 '20 at 07:57
  • Yes, I was planning to do it in the future, but maybe it's time to do it. Thanks for you suggestion! – Xoán Jul 17 '20 at 10:39

0 Answers0