WorkManager останавливает планирование периодов c Worker после закрытия приложения

Question

возможно, это еще один вопрос о WorkManager, но я действительно не могу найти решение ...

Я пытаюсь, как следует из названия, запускать периодические c работы каждые 15 минут. На самом деле на рабочем месте я опрашиваю некоторые данные каждую минуту. После каждого опроса каждую почти 1 секунду я проверяю, остановлен ли работник и, если это так, возвращаюсь, в противном случае продолжаю ждать, пока не будет достигнута 1 минута, и снова опрашиваю данные.

В соответствии с документацией это должно работать, и это действительно так пока я не убью приложение с экрана недавнего приложения.

Вот код:

package com.qsea.app.cordova;

import android.content.Context;

import android.os.SystemClock;

import android.util.Log;

import androidx.work.Worker;
import androidx.work.WorkerParameters;

public class ServerListenerWorker extends Worker {

    public static final String TAG = "ServerListenerWorker";

    public ServerListenerWorker(
        Context appContext,
        WorkerParameters workerParams
    ) {
        super(appContext, workerParams);
    }

    @Override
    public Result doWork() {

        Log.d(TAG, "Doing work");

        final long startTime = SystemClock.elapsedRealtime();
        final int maxDelta = 840000; // 14 minutes

        while (true) {
            // I did this to stop this worker until 15 minutes
            // and then let the next worker run
            if (SystemClock.elapsedRealtime() - startTime >= maxDelta) {
                break;
            }

            // Here I'm polling data, if the polling results in a failure
            // I return Result.retry()

            // It avoid waiting if it remains only 1 minute until the max time
            if (SystemClock.elapsedRealtime() - startTime >= (maxDelta - 60000)) {
                break;
            }
            for (int i = 0; i < 60; i++) {
                SystemClock.sleep(950);
                // Here it checks if it is stopped
                if (isStopped()) {
                    Log.d(TAG, "Detected stop"); // this is actually never reached
                    break;
                }
            }
        }
        return Result.success();
    }
}

И я делаю следующее, чтобы начать работу

Constraints constraints = new Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build();
PeriodicWorkRequest periodicWorkRequest = new PeriodicWorkRequest.Builder(ServerListenerWorker.class, 15, TimeUnit.MINUTES)
    .addTag(serverListenerWorkerUID)
    .setConstraints(constraints)
    .build();
WorkManager.getInstance(cordova.getActivity()).enqueueUniquePeriodicWork(serverListenerWorkerUID, ExistingPeriodicWorkPolicy.KEEP, periodicWorkRequest);

Я проверяю правильную работу работника, просматривая журнал моего сервера (если я получаю запрос, он работает нормально), и, кажется, он работает нормально, пока я не закрою приложение. Затем он прекращает работу фактического работника и никогда не запускает его снова, пока я не открою приложение, где работа, похоже, ставится в очередь и возобновляется сразу после открытия приложения.

Я что-то не так делаю при инициализации? У меня также есть <service android:name=".ServerListenerWorker" android:permission="android.permission.BIND_JOB_SERVICE" /> в моем AndroidManifest. xml

Это ожидаемое поведение?

Я прочитал, что китайское ПЗУ имеет дополнительные ограничения для фоновых служб, и у меня есть HUAWEI, который, кажется, быть худшим в этом. Так может ли это быть устройство? И если да, то как Facebook, WhatsApp, Instagram и другие управляют этим, чтобы работать даже на этих устройствах?

Answer 1

Давайте разделим это на две разные проблемы.

1. То, что вы делаете в своих работниках, требует много энергии и было бы лучше, если бы вы использовали службу переднего плана, которая уведомляет пользователя о том, что ваше приложение работает постоянно в фоновом режиме. Вы также можете использовать WorkManager с недавно представленной поддержкой для работающих на протяжении длительного времени работников (которые под капотом используют службу переднего плана). Подробнее об этом см. В документации .

2. Если у вас возникли проблемы с указанными c OEM-изготовителями, откройте проблему на Android IssueTracker как это может быть нарушение CDD. Google может связаться с OEM и попросить, чтобы они исправили ROM. Это займет время, тем временем вы можете взглянуть на такие сайты, как , не убивайте мое приложение , чтобы понять, каковы ограничения на конкретном c устройстве и использовать библиотеку, такую ​​как autostarter , чтобы помочь пользователю перейти к нужной настройке.

Кстати, вам не нужно указывать своих работников в файле AndroidManifest.xml