Interfejs WorkManager API ułatwia planowanie opóźnionych, asynchronicznych zadań, które muszą być wykonywane niezawodnie. Te interfejsy API umożliwiają tworzenie zadań i przekazywanie ich do WorkManagera do wykonania po spełnieniu ograniczeń.
Twoja opinia pomoże nam ulepszyć Jetpacka. Daj nam znać, jeśli zauważysz nowe problemy lub masz pomysły na ulepszenie tej biblioteki. Zanim utworzysz nowy problem, zapoznaj się z dotychczasowymi problemami w tej bibliotece. Możesz zagłosować na istniejący problem, klikając przycisk z gwiazdką.
androidx.work:work-*:2.10.0 został zwolniony. Wersja 2.10.0 zawiera te komity.
Znaczące zmiany od wersji 2.9.1
Dodano tagi śledzenia do zadań z WorkManager, dzięki czemu polecenie „adb shell dumpsys jobscheduler” jest znacznie łatwiejsze do zrozumienia, ponieważ zawiera nazwę wykonywanego zadania. Dodano też sekcje śledzenia wokół kluczowych obszarów WorkManager.
Dodano element sterujący Configuration.workerCoroutineContext do kontrolowania modułu rozsyłającego, w którym wykonywane jest działanie CoroutineWorker.
Deweloperzy mogą określić NetworkRequest jako ograniczenie dla instancji roboczej za pomocą metody Constraints.setRequiredNetworkRequest. Dzięki temu możesz dokładniej określić, w której sieci ma działać ta instancja robocza.
WorkManager Wersja 2.10.0 jest teraz skompilowana z pakietem SDK 35 i zawiera różne zmiany zapewniające zgodność z tym pakietem.
Wersja 2.10.0-rc01
24 października 2024 r.
androidx.work:work-*:2.10.0-rc01 został zwolniony. Wersja 2.10.0-rc01 zawiera te komisy.
Wersja 2.10.0-beta01
2 października 2024 r.
androidx.work:work-*:2.10.0-beta01 został zwolniony. Wersja 2.10.0-beta01 zawiera te komity.
Wersja 2.10.0-alpha04
18 września 2024 r.
androidx.work:work-*:2.10.0-alpha04 został zwolniony. Wersja 2.10.0-alpha04 zawiera te komity.
Zmiany w interfejsie API
Dodaj przyczynę zatrzymania STOP_REASON_FOREGROUND_SERVICE_TIMEOUT, gdy instancja robocza na pierwszym planie zostanie zatrzymana z powodu przekroczenia limitu czasu wykonywania na podstawie typu usługi na pierwszym planie. (Ibd0af)
Wersja 2.10.0-alpha03
4 września 2024 r.
androidx.work:work-*:2.10.0-alpha03 został zwolniony. Wersja 2.10.0-alpha03 zawiera te komity.
Nowe funkcje
Dodano tagi śledzenia do zadań z WorkManager, dzięki czemu polecenie „adb shell dumpsys jobscheduler” jest znacznie łatwiejsze do zrozumienia, ponieważ zawiera nazwę wykonywanego zadania. Dodano też sekcje śledzenia wokół kluczowych obszarów WorkManager.
Zmiany w interfejsie API
WorkManager 2.10.0 jest teraz kompilowany z pakietem SDK 35.
Napraw problem z usługami na pierwszym planie typu „short service” i „data sync”, które powodują przekroczenie limitu czasu i wywołują ANR, gdy WorkManager nie wywołuje stopSelf(). Ta poprawka dotyczy tylko urządzeń z interfejsem API 34 i 35, na których wprowadzono typy usług na pierwszym planie. (ca06b2, b/364508145)
Nowe interfejsy API WorkerParameters, które umożliwiają przełączanie procesu zdalnego, do którego Worker się łączy podczas korzystania z WorkerFactory. (Ibdc8a, Ie8a90, I7373f)
Poprawki błędów
Rozwiązanie problemu awarii spowodowanego przez próbę ponownego uruchomienia przez WorkManager trwającej przez długi czas instancji roboczej (czyli roboczej na pierwszym planie), gdy typ pracy na pierwszym planie miał uprawnienia wymagane przez Androida 14, które zostały cofnięte. (b/333957914)
Usunięto ręczne określanie dostępu do nowych interfejsów API platformy, ponieważ odbywa się to automatycznie za pomocą modelowania interfejsu API podczas korzystania z R8 z AGP 7.3 lub nowszym (np. R8 w wersji 3.3) oraz we wszystkich wersjach kompilacji przy użyciu AGP 8.1 lub nowszego (np. D8 w wersji 8.1). Klienci, którzy nie korzystają z AGP, powinni zaktualizować D8 do wersji 8.1 lub nowszej. Więcej szczegółów znajdziesz w tym artykule. (Ia60e0, b/345472586)
Wersja 2.10.0-alpha02
17 kwietnia 2024 r.
androidx.work:work-*:2.10.0-alpha02 został zwolniony. Wersja 2.10.0-alpha02 zawiera te komity.
Zmiany w interfejsie API
Dodaliśmy możliwość emitowania zakresów przechwytywania za pomocą konfigurowalnego elementu @RestrictToTracer w elementach WorkManager. (I17d7f, b/260214125)
Dodano element sterujący Configuration.workerCoroutineContext do kontrolowania modułu rozsyłającego, w którym wykonywane jest działanie CoroutineWorker. Pomaga to całkowicie uniknąć używania Dispatchers.Default w elementach WorkManager. (Icd1b7)
Dodaj niestandardowe moduły obsługi wyjątków dla Workers (Ib1b74, b/261190695)
Funkcje OneTimeWorkRequest.Builder i PeriodicWorkRequest.Builder można teraz tworzyć za pomocą KClass zamiast Class: val request = OneTimeWorkRequest.Builder(Worker::class).setConstraints(...).build() (Ib55f6)
Klasa WorkManager została przeniesiona do Kotlina. Teraz metody zwracające LiveData, ListenableFuture lub Flow podają prawidłowe informacje o możliwości wystąpienia wartości null. Może to wymagać wprowadzenia zmian w kodzie źródłowym klienta, jeśli założenia dotyczące możliwości występowania wartości null w tym kodzie były nieprawidłowe. (If6757)
Deweloperzy mogą określić NetworkRequest jako ograniczenie dla pracownika za pomocą metody Constraints.setRequiredNetworkRequest. Dzięki temu możesz dokładniej określić, w której sieci ma działać ta instancja robocza.
Zmiany w interfejsie API
Dodanie możliwości określenia NetworkRequest jako ograniczenia. (Id98a1, b/280634452)
Wersja 2.9
Wersja 2.9.1
7 sierpnia 2024 r.
androidx.work:work-*:2.9.1 został zwolniony. Wersja 2.9.1 zawiera te komity.
Poprawki błędów
Rozwiązanie problemu awarii spowodowanego przez próbę ponownego uruchomienia przez WorkManager długo działającego workera (czyli workera na pierwszym planie), gdy typ pracy na pierwszym planie miał cofniętą uprawnienie wymagane w Androidzie 14. (b/333957914)
Dostrzegalność za pomocą Flow. Zamiast LiveData postępy pracownika można teraz obserwować za pomocą metod WorkManager.getWorkInfosFlow i podobnych metod.
Teraz WorkManager zawiera wskazówkę, dlaczego instancja robocza została wcześniej zatrzymana. Możesz go użyć, wysyłając zapytanie z poziomu instancji roboczej za pomocą metody getStopReason() lub z poziomu WorkInfo za pomocą metody getStopReason().
Dokładne planowanie okresowych pracowników za pomocą setNextScheduleTimeOverride. Umożliwia to dynamiczne obliczanie kolejnego harmonogramu pracy okresowej, który może służyć do implementowania zaawansowanych funkcji, takich jak adaptacyjne czasy odświeżania, niestandardowe zachowanie prób ponownego wykonania czy uruchamianie zadania dotyczącego kanału z wiadomościami przed każdym porannym wstaniem użytkownika bez przesunięcia. Aby uniknąć anulowania obecnie działającego zadania podczas planowania kolejnego, należy używać funkcji ExistingPeriodicWorkPolicy.UPDATE.
Testowanie WorkManagera z wykorzystaniem wątków dopasowanych do produkcji. ExecutorsMode.PRESERVE_EXECUTORS można użyć w funkcji initializeTestWorkManager, aby zachować wykonawców ustawionych w funkcji Configuration i użyć rzeczywistego wątku głównego.
Interfejsy API dotyczące coroutine, takie jak CoroutineWorker, zostały przeniesione z dodatkowego artefaktu work-runtime-ktx do głównego artefaktu work-runtime. work-runtime-ktx jest teraz pusty.
Zmiany w interfejsie API
Do grupy WorkInfo został dodany użytkownik stopReason. Dostęp do zmiennej stopReason jest możliwy po uruchomieniu instancji roboczej. Może to być przydatne w raportowaniu stopReason, ponieważ po zatrzymaniu zadania można bardzo szybko zatrzymać całą aplikację. (I21386)
Umożliw ustawienie wartości Clock w konfiguracji i używanie jej do określania kolejności wykonywania testów Worker. (Ic586e)
Do metody getStopReason() dodano metodę ListenableWorker, która wskazuje, dlaczego instancja robocza została zatrzymana. (I07060)
Dodano WorkManagerTestInitHelper#closeWorkDatabase(), aby uniknąć ostrzeżenia Closeguard o wycieku zasobów. (Ia8d49)
Konstruktor klasy WorkInfo jest teraz publiczny, co może być przydatne podczas testowania. (Ia00b6, b/209145335)
work-runtime-ktx jest teraz pusty, a CoroutineWorker i inne narzędzia do Kotlina są teraz dostępne w głównym artefakcie środowiska uruchomieniowego. (I71a9a)
Dodano metodę setNextScheduleTimeOverride, która umożliwia dokładne ustawianie okresowych harmonogramów pracy (I3b4da).
Dodano getNextScheduleTimeMillis, aby uzyskać informacje o planowanym czasie działania, do WorkInfo. (I797e4)
Informacje o początkowym opóźnieniu i częstotliwości są dodawane do WorkInfo. (I52f2f)
Dodano metodę observe workers via Flows za pomocą metod getWorkInfosByTagFlow, getWorkInfoByIdFlow, getWorkInfosForUniqueWorkFlow, getWorkInfosFlow (If122a).
Do konstruktorów i właściwości Constraints dodano brakujące adnotacje @RequiresApi(...). Zostały one dopasowane do odpowiednich adnotacji w metodach settera w bibliotece Constraints.Builder, które istniały już w pierwszych wersjach biblioteki WorkManager. (I6d7d2)
WorkManager ma teraz osobny limit dla pracowników odpowiedzialnych za URI treści, aby zapewnić im gwarantowane sloty w JobScheduler i zapobiec braku aktualizacji treści w przypadku dużego obciążenia. Limit można skonfigurować za pomocą Configuration.Builder.setContentUriTriggerWorkersLimit. (Ic128f)
Teraz WorkManager zawiera wskazówkę, dlaczego usługa została wcześniej zatrzymana. Możesz go użyć, aby zapytać o dane dotyczące pracownika za pomocą metody getStopReason() lub WorkInfo za pomocą metody getStopReason().
Zmiany w interfejsie API
Do grupy WorkInfo został dodany użytkownik stopReason. Udostępnia ona stopReason po uruchomieniu instancji roboczej. Może to być przydatne w raportowaniu stopReason, ponieważ po zatrzymaniu zadania można bardzo szybko zatrzymać całą aplikację. (I21386)
Zezwalanie na ustawianie zegara za pomocą konfiguracji i używanie go do określania kolejności wykonywania testów Worker. (Ic586e)
Do metody getStopReason() dodano metodę ListenableWorker, która wskazuje, dlaczego instancja robocza została zatrzymana. (I07060)
Dodano WorkManagerTestInitHelper#closeWorkDatabase(), aby uniknąć ostrzeżenia Closeguard o wycieku zasobów. (Ia8d49)
Poprawki błędów
Dodano możliwość pominięcia overrideNextScheduleTime za pomocą TestDriver oraz rozwiązano problemy z testowalnością. (Ic2905)
Dostrzegalność za pomocą Flow-s. Zamiast LiveData postępy pracownika można teraz obserwować za pomocą metod WorkManager.getWorkInfosFlow i podobnych metod.
Dokładne planowanie okresowych pracowników za pomocą setNextScheduleTimeOverride. Umożliwia to dynamiczne obliczanie kolejnego harmonogramu pracy okresowej, który może służyć do implementowania zaawansowanych funkcji, takich jak adaptacyjne czasy odświeżania, niestandardowe zachowanie prób ponownego wykonania czy uruchamianie zadania dotyczącego kanału z wiadomościami przed każdym porannym wstaniem użytkownika bez przesunięcia. Aby uniknąć anulowania obecnie działającego zadania podczas planowania następnego, należy używać funkcji ExistingPeriodicWorkPolicy.UPDATE.
WorkManager testuje wątki dopasowane do produkcji. ExecutorsMode.PRESERVE_EXECUTORS można użyć, aby zachować wykonawców ustawionych w Configuration i używać rzeczywistego wątku głównego.
Interfejsy API dotyczące coroutines, takie jak CoroutineWorker, zostały przeniesione z dodatkowego artefaktu work-runtime-ktx do głównego artefaktu work-runtime. Pole work-runtime-ktx jest teraz puste.
Zmiany w interfejsie API
Konstruktor WorkInfo jest teraz publiczny, co może być przydatne podczas testowania. (Ia00b6, b/209145335)
work-runtime-ktx jest teraz pusty, a CoroutineWorker i inne narzędzia do obsługi Kotlina są teraz dostępne w głównym artefakcie work-runtime. (I71a9a)
Dodano metodę setNextScheduleTimeOverride, która umożliwia dokładne ustawianie okresowych harmonogramów pracy (I3b4da).
Nazwa getEarliestRunTimeMillis została zmieniona na getNextScheduleTimeMillis. (I2bd7a)
Informacje o czasie następnego zaplanowanego uruchomienia są dodawane do WorkInfo. (I797e4)
Informacje o początkowym opóźnieniu i częstotliwości są dodawane do WorkInfo. (I52f2f)
Dodano metodę observe workers via Flows za pomocą metod getWorkInfosByTagFlow, getWorkInfoByIdFlow, getWorkInfosForUniqueWorkFlow, getWorkInfosFlow (If122a).
Do konstruktorów i właściwości ograniczeń dodano brakujące adnotacje @RequiresApi(...). Zostały one dopasowane do odpowiednich adnotacji w metodach settera w bibliotece Constraints.Builder, które istniały już w pierwszych wersjach biblioteki WorkManager. (I6d7d2)
WorkManager ma teraz osobny limit dla pracowników zajmujących się URI treści, aby zapewnić im gwarantowane miejsca w JobScheduler i zapobiec braku aktualizacji treści w przypadku dużego obciążenia. Limit można skonfigurować za pomocą Configuration.Builder.setContentUriTriggerWorkersLimit. (Ic128f)
Dodano WorkManager.updateWork, aby zaktualizować pracę, zachowując jej pierwotny czas kolejkowania i łańcuchowanie.(I9a248, b/219446409)
Dodano użytkownika ExistingPeriodicWorkPolicy.UPDATE Te zasady umożliwiają aktualizację okresowego dzieła pod kątem nazwy. Jest ona podobna do obecnej funkcji REPLACE, ale mniej inwazyjna: nie anuluje zadania, jeśli jest ono obecnie wykonywane, i zachowuje czas kolejkowania – początkowe opóźnienie i okres są obliczane na podstawie pierwotnego czasu kolejkowania, a nie czasu aktualizacji. REPLACE zostało wycofane, aby zmniejszyć ryzyko pomylenia funkcji o bardzo podobnych nazwach REPLACE i UPDATE. Jeśli nadal chcesz zachować poprzednią semantykę REPLACE, możesz użyć nowo dodanego elementu CANCEL_AND_REENQUEUE, który jest identyczny z elementem REPLACE. (I985ed, b/219446409)
Dodano możliwość przechwytywania wyjątków harmonogramu, podając Consumer<Throwable> za pomocą funkcji setSchedulingExceptionHandler.
Dodano możliwość przekazania wartości Consumer<Throwable> za pomocą metody setInitializationExceptionHandler, aby określić, czy podczas inicjowania WorkManagera wystąpiły problemy.
Pomoce w wersji inline dla funkcji OneTimeWorkRequest i PeriodicWorkRequest zostały przeniesione z funkcji androidx.work:work-runtime-ktx do funkcji androidx.work:work-runtime (I0010f, b/209145335).
Dodano pomocnicze metody WorkQuery.fromIds, WorkQuery.fromStates, WorkQuery.fromUniqueWorkNames i WorkQuery.fromTags, aby umożliwić bezpośrednie tworzenie obiektów WorkQuery. (b/199919736) (If48f2, b/199919736)
RxWorker zarówno w przypadku RxJava 2, jak i RxJava 3 ma teraz metodę setForeground zwracającą Completable, którą można użyć zamiast metody setForegroundInfoAsync zwracającej ListenableFuture.
RxWorker zarówno w przypadku RxJava 2, jak i RxJava 3 ma metodę getForegroundInfo zwracającą Single, którą można użyć zamiast metody getForegroundInfoAsync zwracającej ListenableFuture. (b/203851459)
Ograniczenia można teraz tworzyć bezpośrednio zamiast używać funkcji Constraints.Builder, co jest wygodne dla użytkowników Kotlina. (Idc390, b/137568653)
Dodano możliwość sprawdzenia, czy WorkManager została zainicjalizowana. Dodaliśmy też nowy interfejs API getConfiguration() dla programistów bibliotek, który umożliwia uzyskanie konfiguracji, z którą została zainicjowana biblioteka WorkManager. (I6eff3, b/212300336)
Poprawki błędów
Rozwiązaliśmy problem z łatwym harmonogramem, który uniemożliwiał natychmiastowe uruchamianie podprocesów podczas obciążenia. (I9686b, b/248111307)
Dodaliśmy uprawnienie @RequiresPermission do interfejsów API, które wymagają przyznania uprawnienia POST_NOTIFICATIONS w pakiecie SDK 33 lub nowszym. (Ie542e, b/238790278)
Rozpowszechnianie anulowań w CoroutineScope w ListenableFuture przy użyciu suspendCancellableCoroutine.
Dodano właściwości WorkerInfo.getGeneration() i WorkerParameters.getGeneration(), które zwracają generację instancji roboczej. Pracownik ma wiele generacji, jeśli został zaktualizowany za pomocą funkcji WorkManager.updateWork lub WorkManager.enqueueUniquePeriodicWork za pomocą funkcji ExistingPeriodicWorkPolicy.UPDATE. Pamiętaj, że jeśli instancja robocza jest obecnie uruchomiona, ta metoda może zwrócić nowszą generację niż ta, która jest obecnie uruchomiona, jeśli podczas wykonywania instancji roboczej nastąpiła aktualizacja. (I665c5, b/219446409) (I128a9, b/219446409)
Dodaliśmy InitializationExceptionHandler, czyli sterownik wyjątków, który pozwala określić, czy podczas inicjowania WorkManager wystąpiły problemy. (I061de)
Dodano możliwość aktualizowania WorkRequests w nieinwazyjny sposób, zachowując oryginalny czas kolejkowania, łańcuchowanie itp. Więcej informacji znajdziesz w artykułach WorkManager.updateWork i ExistingPeriodicWorkPolicy.UPDATE.
Zmiany w interfejsie API
Dodano WorkManager.updateWork, aby zaktualizować pracę, zachowując jej pierwotny czas kolejkowania i łańcuchowanie.(I9a248, b/219446409)
Dodano użytkownika ExistingPeriodicWorkPolicy.UPDATE Te zasady umożliwiają aktualizację okresowej pracy na podstawie nazwy. Jest ona podobna do obecnej funkcji REPLACE, ale mniej inwazyjna: nie anuluje zadania, jeśli jest ono obecnie wykonywane, i zachowuje czas kolejkowania – początkowe opóźnienie i okres są obliczane na podstawie pierwotnego czasu kolejkowania, a nie czasu aktualizacji. REPLACE zostało wycofane, aby zmniejszyć zamieszanie między bardzo podobnymi nazwami REPLACE i UPDATE. Jeśli nadal chcesz zachować poprzednią semantykę REPLACE, możesz użyć nowo dodanego elementu CANCEL_AND_REENQUEUE, który jest identyczny z elementem REPLACE. (I985ed, b/219446409)
Dodaj możliwość przechwytywania wyjątków harmonogramu przez zdefiniowanie SchedulingExceptionHandler. (I033eb)
Pomoce w wersji inline dla funkcji OneTimeWorkRequest i PeriodicWorkRequest zostały przeniesione z funkcji androidx.work:work-runtime-ktx do funkcji androidx.work:work-runtime (I0010f, b/209145335).
Poprawki błędów
Dodano @RequiresPermission do interfejsów API, które wymagają przyznania uprawnienia POST_NOTIFICATIONS w pakiecie SDK 33 lub nowszym. (Ie542e, b/238790278)
Ograniczenia można teraz tworzyć bezpośrednio zamiast za pomocą Buildera, co jest wygodne dla użytkowników Kotlina. (Idc390, b/137568653)
Dodano możliwość sprawdzenia, czy WorkManager została zainicjalizowana. Dodaliśmy też nowy interfejs API getConfiguration() dla programistów bibliotek, który umożliwia uzyskanie konfiguracji, z którą została zainicjowana biblioteka WorkManager. (I6eff3, b/212300336)
Dodano pomocnicze metody WorkQuery.fromIds do tworzenia zapytań roboczych bezpośrednio z identyfikatorów. (Ie5bdf, b/199919736)
Metoda RxWorker ma teraz funkcję setForeground, która zwraca wartość Completable. Można jej używać zamiast funkcji setForegroundInfoAsync, która zwraca wartość ListenableFuture. (I85156)
W RxWorker dla RxJava 2 jest teraz dostępna metoda getForegroundInfo z wynikiem Single, którą można użyć zamiast metody getForegroundInfoAsync z wynikiem ListenableFuture. (I21c91, b/203851459)
W wersji RxWorker dla RxJava 3 dodano metodę getForegroundInfo, która zwraca wartość Single. Można jej używać zamiast metody getForegroundInfoAsync, która zwraca wartość ListenableFuture. (I1ca8a)
Metoda RxWorker ma teraz funkcję setForeground, która zwraca wartość Completable. Można jej używać zamiast funkcji setForegroundInfoAsync, która zwraca wartość ListenableFuture. (I992a3, b/203851459)
Poprawki błędów
Rozpowszechnianie anulowań w CoroutineScope w ListenableFuture przy użyciu suspendCancellableCoroutine. (I77e63)
WorkManager wprowadza nowy interfejs API WorkRequest.Builder.setExpedited(...), który ułatwia stosowanie ograniczeń usług działających na pierwszym planie w Androidzie 12.
Gdy używasz setExpedited(...), WorkManager deleguje zadania przyspieszone w JobSchedulerze od Androida 12, zapewniając jednocześnie zgodność wsteczną w poprzednich wersjach Androida przez delegowanie do usługi na pierwszym planie.
androidx.work:work-*:2.7.0-alpha04 został zwolniony.
Ta wersja zawiera też zmiany z wersji 2.6.0-beta01.
Zmiany w interfejsie API
Właściwość ListenableWorker.setForegroundAsync() nie jest już wycofana.
W miarę możliwości zalecamy korzystanie z interfejsu WorkRequest.Builder.setExpedited(...) API. Aby lepiej obsługiwać sytuacje, w których aplikacja nie podlega ograniczeniom usługi na pierwszym planie, deweloperzy mogą korzystać z interfejsu API ListenableWorker.setForegroundAsync().
Jeśli wywołanie ListenableWorker.setForegroundAsync() nastąpi, gdy aplikacja podlega ograniczeniom dotyczącym usług na pierwszym planie, zostanie rzucony wyjątek ForegroundServiceStartNotAllowedException.
Poprawki błędów
Gdy przyspieszone zadania zostaną ponownie zaplanowane, nie będą już przyspieszone. Stają się one zwykłymi zadaniami.
W WorkManagerze2.6.0-alpha02: dodano RemoteCoroutineWorker, czyli implementację RemoteListenableWorker, która może się łączyć z procesem zdalnym. (I30578)
W WorkManagerze2.6.0-alpha02: ustaw WorkManagerInitializer jako publiczne, aby inne androidx.startup.Initializer mogły ich używać jako zależności. (I5ab11)
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.