WorkManager
Dernière mise à jour | Version stable | Version finale | Version bêta | Version alpha |
---|---|---|---|---|
30 octobre 2024 | 2.9.1 | - | - | - |
Déclarer des dépendances
Pour ajouter une dépendance à WorkManager, vous devez ajouter le dépôt Maven Google à votre projet.
Ajoutez les dépendances des artefacts dont vous avez besoin dans le fichier build.gradle
de votre application ou module :
Groovy
dependencies { def work_version = "2.9.1" // (Java only) implementation "androidx.work:work-runtime:$work_version" // Kotlin + coroutines implementation "androidx.work:work-runtime-ktx:$work_version" // optional - RxJava2 support implementation "androidx.work:work-rxjava2:$work_version" // optional - GCMNetworkManager support implementation "androidx.work:work-gcm:$work_version" // optional - Test helpers androidTestImplementation "androidx.work:work-testing:$work_version" // optional - Multiprocess support implementation "androidx.work:work-multiprocess:$work_version" }
Kotlin
dependencies { val work_version = "2.9.1" // (Java only) implementation("androidx.work:work-runtime:$work_version") // Kotlin + coroutines implementation("androidx.work:work-runtime-ktx:$work_version") // optional - RxJava2 support implementation("androidx.work:work-rxjava2:$work_version") // optional - GCMNetworkManager support implementation("androidx.work:work-gcm:$work_version") // optional - Test helpers androidTestImplementation("androidx.work:work-testing:$work_version") // optional - Multiprocess support implementation("androidx.work:work-multiprocess:$work_version") }
Pour en savoir plus sur l'utilisation des extensions Kotlin, consultez la documentation sur les extensions KTX.
Pour en savoir plus sur les dépendances, consultez la page Ajouter des dépendances de build.
Commentaires
Vos commentaires nous aident à améliorer Jetpack. N'hésitez pas à nous contacter si vous découvrez de nouveaux problèmes ou si vous avez des idées pour améliorer cette bibliothèque. Veuillez consulter les problèmes existants de cette bibliothèque avant d'en signaler un nouveau. Vous pouvez ajouter votre vote à un problème existant en cliquant sur le bouton en forme d'étoile.
Pour en savoir plus, consultez la documentation sur l'outil Issue Tracker.
Version 2.10
Version 2.10.0
30 octobre 2024
Publication d'androidx.work:work-*:2.10.0
. La version 2.10.0 contient ces commits.
Changements importants depuis la version 2.9.1
- Ajout de tags de suivi aux tâches à partir de
WorkManager
, ce qui rend "adb shell dumpsys jobscheduler" beaucoup plus facile à comprendre, car il contiendra le nom du worker en cours d'exécution. Des sections de trace sont également ajoutées autour des zones clés deWorkManager
. Configuration.workerCoroutineContext
a été ajouté pour contrôler le répartiteur oùCoroutineWorker
est exécuté.- Les développeurs peuvent spécifier
NetworkRequest
comme contrainte pour un nœud de calcul via la méthodeConstraints.setRequiredNetworkRequest
. Cela permet de contrôler plus précisément le réseau sur lequel ce nœud de calcul doit s'exécuter. WorkManager
2.10.0 est à présent compilé avec le SDK 35 et contient plusieurs modifications pour assurer la compatibilité avec ce SDK.
Version 2.10.0-rc01
24 octobre 2024
Publication d'androidx.work:work-*:2.10.0-rc01
. La version 2.10.0-rc01 contient ces commits.
Version 2.10.0-beta01
2 octobre 2024
Publication d'androidx.work:work-*:2.10.0-beta01
. La version 2.10.0-beta01 contient ces commits.
Version 2.10.0-alpha04
18 septembre 2024
Publication d'androidx.work:work-*:2.10.0-alpha04
. La version 2.10.0-alpha04 contient ces commits.
Modifications apportées à l'API
- Ajoutez le motif d'arrêt
STOP_REASON_FOREGROUND_SERVICE_TIMEOUT
lorsqu'un nœud de calcul de premier plan est arrêté en raison d'un délai d'exécution basé sur le type de service de premier plan. (Ibd0af)
Version 2.10.0-alpha03
4 septembre 2024
Publication d'androidx.work:work-*:2.10.0-alpha03
. La version 2.10.0-alpha03 contient ces commits.
Nouvelles fonctionnalités
- Ajout de tags de suivi aux tâches à partir de
WorkManager
, ce qui rend "adb shell dumpsys jobscheduler" beaucoup plus facile à comprendre, car il contiendra le nom du worker en cours d'exécution. Des sections de trace sont également ajoutées autour des principaux domaines deWorkManager
.
Modifications apportées à l'API
- WorkManager 2.10.0 est désormais compilé avec le SDK 35.
- Correction des nœuds de calcul de premier plan de type "short service" et "synchronisation des données" qui entraînaient une erreur ANR lorsque
WorkManager
n'appelait passtopSelf()
. Ce correctif ne s'applique qu'aux appareils équipés des API 34 et 35, où les types de services de premier plan ont été introduits. (ca06b2, b/364508145) - Nouvelles API
WorkerParameters
permettant de changer le processus distant auquel leWorker
se lie lors de l'utilisation d'unWorkerFactory
. (Ibdc8a, Ie8a90, I7373f)
Correction de bugs
- Correction d'un plantage causé par
WorkManager
qui tentait de redémarrer un nœud de calcul de longue durée (c'est-à-dire un nœud de calcul de premier plan) lorsque le type de premier plan de la tâche avait des autorisations préalables Android 14 révoquées. (b/333957914). - Suppression de la description manuelle de l'accès aux nouvelles API de la plate-forme, car cela se produit automatiquement via la modélisation d'API lorsque vous utilisez R8 avec AGP 7.3 ou version ultérieure (par exemple, R8 version 3.3) et pour tous les builds lorsque vous utilisez AGP 8.1 ou version ultérieure (par exemple, D8 version 8.1). Les clients qui n'utilisent pas AGP sont invités à passer à la version 8.1 de D8 ou ultérieure. Consultez cet article pour en savoir plus. (Ia60e0, b/345472586)
Version 2.10.0-alpha02
17 avril 2024
Publication d'androidx.work:work-*:2.10.0-alpha02
. La version 2.10.0-alpha02 contient ces commits.
Modifications apportées à l'API
- Ajout de la possibilité d'émettre des plages de trace via un
Tracer
@RestrictTo
configurable dansWorkManager
. (I17d7f, b/260214125) Configuration.workerCoroutineContext
a été ajouté pour contrôler le répartiteur oùCoroutineWorker
est exécuté. Cela permet d'éviter complètement l'utilisation deDispatchers.Default
dansWorkManager
. (Icd1b7)- Ajout de gestionnaires d'exceptions personnalisés pour les nœuds de calcul. (Ib1b74, b/261190695)
OneTimeWorkRequest.Builder
etPeriodicWorkRequest.Builder
peuvent désormais être créés avecKClass
au lieu deClass
:val request = OneTimeWorkRequest.Builder(Worker::class).setConstraints(...).build()
. (Ib55f6)- La classe
WorkManager
a été migrée vers Kotlin. Les méthodes qui renvoientLiveData
,ListenableFuture
ouFlow
fournissent désormais des informations correctes sur la possibilité de valeur nulle. Des modifications peuvent être nécessaires dans le code source des clients si les hypothèses de possibilité de valeur nulle dans ce code étaient incorrectes. (If6757)
Version 2.10.0-alpha01
24 janvier 2024
Publication d'androidx.work:work-*:2.10.0-alpha01
. Liste des commits de la version 2.10.0-alpha01
Nouvelles fonctionnalités
- Les développeurs peuvent spécifier
NetworkRequest
comme contrainte pour un nœud de calcul via la méthodeConstraints.setRequiredNetworkRequest
. Cela permet de contrôler plus précisément le réseau sur lequel ce nœud de calcul doit s'exécuter.
Modifications apportées à l'API
- Ajout de la possibilité de spécifier
NetworkRequest
comme contrainte. (Id98a1, b/280634452).
Version 2.9
Version 2.9.1
7 août 2024
Publication d'androidx.work:work-*:2.9.1
. La version 2.9.1 contient ces commits.
Correction de bugs
- Correction d'un plantage causé par
WorkManager
qui tentait de redémarrer un nœud de calcul de longue durée (c'est-à-dire un nœud de calcul de premier plan) lorsque les autorisations préalables requises pour Android 14 du type de premier plan de la tâche avaient été révoquées. (b/333957914)
Version 2.9.0
29 novembre 2023
Publication d'androidx.work:work-*:2.9.0
. Liste des commits de la version 2.9.0
Modifications importantes depuis la version 2.8.0
- Observabilité via les
Flow
. Au lieu deLiveData
, la progression du nœud de calcul peut désormais être observée viaWorkManager.getWorkInfosFlow
et des méthodes similaires dans Flow. WorkManager
fournit désormais un indice sur la raison pour laquelle un nœud de calcul a été arrêté précédemment. Il peut être interrogé à partir d'un nœud de calcul lui-même via la méthodegetStopReason()
ou à partir deWorkInfo
viagetStopReason()
.- Planification précise des nœuds de calcul périodiques via
setNextScheduleTimeOverride
. Cela permet de calculer de manière dynamique le prochain calendrier de travail périodique, qui peut être utilisé pour implémenter des fonctionnalités avancées telles que des délais d'actualisation adaptatifs, un comportement de nouvelle tentative personnalisé ou l'exécution d'un nœud de calcul de flux de nouvelles avant que l'utilisateur ne se réveille chaque matin sans dérive.ExistingPeriodicWorkPolicy.UPDATE
doit être utilisé avec ces techniques pour éviter d'annuler un worker en cours d'exécution lors de la planification du suivant. - Test de WorkManager avec mise en correspondance de threads en production.
ExecutorsMode.PRESERVE_EXECUTORS
peut être utilisé dansinitializeTestWorkManager
pour conserver les exécuteurs définis dansConfiguration
et pour utiliser le thread principal réel. - Les API de coroutines telles que
CoroutineWorker
ont été déplacées de l'artefact supplémentaire work-runtime-ktx vers l'environnement d'exécution de l'artefact principal. work-runtime-ktx est désormais vide.
Modifications apportées à l'API
stopReason
a été ajouté àWorkInfo
. Il rendstopReason
disponible après l'exécution du nœud de calcul. Il peut être utile de créer des rapportsstopReason
de manière utilisable, car une fois qu'un worker a été arrêté, une application elle-même peut être arrêtée très rapidement. (I21386)- Autoriser la définition de
Clock
via la configuration et son utilisation pour contrôler le séquençage de l'exécution des tests des workers. (Ic586e) - La méthode
getStopReason()
a été ajoutée àListenableWorker
pour indiquer pourquoi le nœud de calcul a été arrêté. (I07060) - Ajout de
WorkManagerTestInitHelper#closeWorkDatabase()
pour éviter l'avertissement de Closeguard concernant les fuites de ressources. (Ia8d49). - Le constructeur de
WorkInfo
est désormais public, ce qui peut être utile pour les tests. (Ia00b6, b/209145335) work-runtime-ktx
est désormais vide,CoroutineWorker
et d'autres utilitaires spécifiques à Kotlin sont désormais disponibles dans l'artefact principal de l'environnement d'exécution. (I71a9a).- Ajout de la méthode
setNextScheduleTimeOverride
, qui permet de définir précisément les planifications de travail périodiques (I3b4da) - Ajout de
getNextScheduleTimeMillis
pour obtenir des informations sur l'heure d'exécution planifiée dansWorkInfo
. (I797e4) - Les informations sur le délai initial et la périodicité sont ajoutées à
WorkInfo
. (I52f2f). - Ajout de la méthode d'observation des nœuds de calcul via des flux via les méthodes
getWorkInfosByTagFlow
,getWorkInfoByIdFlow
,getWorkInfosForUniqueWorkFlow
etgetWorkInfosFlow
(If122a) - Ajout des annotations
@RequiresApi(...)
manquantes aux constructeurs et aux propriétés deConstraints
. Elles sont désormais alignées sur les annotations correspondantes sur les setters dansConstraints.Builder
qui existaient depuis les premières versions deWorkManager
. (I6d7d2) WorkManager
dispose désormais d'une limite distincte pour les nœuds de calcul d'URI de contenu afin de leur offrir des emplacements garantis dansJobScheduler
pour éviter de manquer des mises à jour de contenu en cas de charge élevée. Vous pouvez configurer la limite viaConfiguration.Builder.setContentUriTriggerWorkersLimit
. (Ic128f)- Des contraintes sont ajoutées à
WorkInfo
. (I162c0)
Version 2.9.0-rc01
18 octobre 2023
Publication d'androidx.work:work-*:2.9.0-rc01
. Liste des commits de la version 2.9.0-rc01
- Aucune modification depuis la dernière version bêta
Version 2.9.0-beta01
6 septembre 2023
Publication d'androidx.work:work-*:2.9.0-beta01
. Liste des commits de la version 2.9.0-beta01.
Modifications apportées à l'API
- Ajout de constantes pour les motifs d'arrêt renvoyés par
WorkInfo.stopReason
etListenableWorker.stopReason
. (I0cc00)
Version 2.9.0-alpha02
26 juillet 2023
Publication d'androidx.work:work-*:2.9.0-alpha02
. Liste des commits de la version 2.9.0-alpha02
Nouvelles fonctionnalités
WorkManager
fournit désormais des indications sur les raisons pour lesquelles un nœud de calcul a été arrêté précédemment. Il peut être interrogé à partir d'un nœud de calcul lui-même via la méthodegetStopReason()
ou à partir deWorkInfo
viagetStopReason()
.
Modifications apportées à l'API
stopReason
a été ajouté àWorkInfo
. Il rendstopReason
disponible après l'exécution du nœud de calcul. Cela peut être utile pour créer des rapportsstopReason
de manière utilisable, car une fois qu'un worker a été arrêté, une application elle-même peut être arrêtée très rapidement. (I21386)- Autorisez l'horloge à être définie via la configuration et à être utilisée pour piloter le séquencement de l'exécution des tests Worker. (Ic586e).
- La méthode
getStopReason()
a été ajoutée àListenableWorker
pour indiquer pourquoi le nœud de calcul a été arrêté. (I07060) - Ajout de
WorkManagerTestInitHelper#closeWorkDatabase()
pour éviter l'avertissement de Closeguard concernant les ressources divulguées. (Ia8d49)
Correction de bugs
- Ajout de la possibilité de contourner
overrideNextScheduleTime
à l'aide deTestDriver
et correction des problèmes de testabilité. (Ic2905).
Version 2.9.0-alpha01
7 juin 2023
Publication d'androidx.work:work-*:2.9.0-alpha01
. Liste des commits de la version 2.9.0-alpha01
Nouvelles fonctionnalités
- Observabilité via les
Flow
. Au lieu deLiveData
, la progression du nœud de calcul peut désormais être observée viaWorkManager.getWorkInfosFlow
et des méthodes similaires dans Flow. - Planification précise des nœuds de calcul périodiques via
setNextScheduleTimeOverride
. Cela permet un calcul dynamique du prochain planning de travail périodique, qui peut être utilisé pour implémenter des fonctionnalités avancées telles que les temps d'actualisation adaptatifs, un comportement personnalisé en cas de nouvelles tentatives ou pour exécuter un nœud de calcul de flux d'actualités avant que l'utilisateur ne se réveille chaque matin sans dérive.ExistingPeriodicWorkPolicy.UPDATE
doit être utilisé avec ces techniques pour éviter d'annuler un worker en cours d'exécution lors de la planification du suivant. - Test de
WorkManager
avec la production de mise en correspondance de threads.ExecutorsMode.PRESERVE_EXECUTORS
peut être utilisé pour conserver les exécuteurs définis dansConfiguration
et pour utiliser le thread principal réel. - Les API de coroutines telles que
CoroutineWorker
ont été déplacées de l'artefact supplémentairework-runtime-ktx
vers l'artefact principalwork-runtime
.work-runtime-ktx
est désormais vide.
Modifications apportées à l'API
- Le constructeur de
WorkInfo
est désormais public, ce qui peut être utile pour les tests. (Ia00b6, b/209145335) work-runtime-ktx
est désormais vide.CoroutineWorker
et d'autres utilitaires spécifiques à Kotlin sont désormais disponibles dans l'artefactwork-runtime
principal. (I71a9a).- Ajout de la méthode
setNextScheduleTimeOverride
, qui permet de définir précisément les planifications de travail périodiques (I3b4da) - Changement de nom :
getEarliestRunTimeMillis
devientgetNextScheduleTimeMillis
. (I2bd7a). - Les informations sur l'heure de l'exécution planifiée suivante sont ajoutées à
WorkInfo
. (I797e4) - Les informations sur le délai initial et la périodicité sont ajoutées à
WorkInfo
. (I52f2f) - Ajout d'une méthode permettant d'observer les nœuds de calcul via des flux via les méthodes
getWorkInfosByTagFlow
,getWorkInfoByIdFlow
,getWorkInfosForUniqueWorkFlow
etgetWorkInfosFlow
. (If122a) - Ajout des annotations
@RequiresApi(...)
manquantes aux constructeurs et aux propriétés des contraintes. Ils sont désormais alignés avec les annotations correspondantes sur les setters deConstraints.Builder
qui existaient depuis les premières versions deWorkManager
. (I6d7d2). WorkManager
dispose désormais d'une limite distincte pour les nœuds de calcul d'URI de contenu afin de leur offrir des emplacements garantis dansJobScheduler
pour éviter de manquer des mises à jour de contenu en cas de charge élevée. La limite peut être configurée viaConfiguration.Builder.setContentUriTriggerWorkersLimit
. (Ic128f)- Des contraintes sont ajoutées à
WorkInfo
. (I162c0)
Version 2.8
Version 2.8.1
22 mars 2023
Publication d'androidx.work:work-*:2.8.1
. Liste des commits de la version 2.8.1
Correction de bugs
- Correction d'une erreur ANR dans
RescheduleReceiver
qui ne gérait pas correctement deux diffusions simultanées. (b/236906724)
Version 2.8.0
8 février 2023
Publication d'androidx.work:work-*:2.8.0
. Liste des commits de la version 1.9.0
Changements importants depuis la version 2.7.0
Nouvelles fonctionnalités
- ll est maintenant possible de mettre à jour
WorkRequests
de manière non intrusive, afin de préserver le temps de mise en file d'attente d'origine, le chaînage, etc. Pour en savoir plus sur cette fonctionnalité, consultez ces article de blog détaillé, ainsi que les javadocsWorkManager.updateWork
etExistingPeriodicWorkPolicy.UPDATE
.
Modifications apportées à l'API
- Ajout de
WorkManager.updateWork
pour mettre à jour le travail tout en préservant son temps de mise en file d'attente et son chaînage d'origine. (I9a248, b/219446409) ExistingPeriodicWorkPolicy.UPDATE
a été ajouté. Cette règle permet de mettre à jour une tâche périodique à partir de son nom. Elle est semblable à la règleREPLACE
existante, mais est moins intrusive : elle n'annule pas un worker s'il est en cours d'exécution et préserve le temps de mise en file d'attente. Le retard initial et la période sont calculés à partir du temps de mise en file d'attente d'origine et non à partir du temps de mise à jour.REPLACE
est maintenant obsolète, pour éviter toute confusion entreREPLACE
etUPDATE
, dont les noms sont très similaires. Si vous souhaitez conserver la sémantique précédente deREPLACE
, vous pouvez utiliser la nouvelle règleCANCEL_AND_REENQUEUE
, qui est identique àREPLACE
. (I985ed, b/219446409)- Ajout de la possibilité d'intercepter les exceptions de planification qui fournissent
Consumer<Throwable>
via setSchedulingExceptionHandler - Ajout de la possibilité de fournir
Consumer<Throwable>
via setInitializationExceptionHandler pour déterminer si des problèmes se sont produits lors de l'initialisation de WorkManager. - Les outils d'aide intégrés pour
OneTimeWorkRequest
etPeriodicWorkRequest
ont été transférés deandroidx.work:work-runtime-ktx
versandroidx.work:work-runtime
(I0010f, b/209145335). - Ajout de méthodes d'assistance
WorkQuery.fromIds
,WorkQuery.fromStates
,WorkQuery.fromUniqueWorkNames
etWorkQuery.fromTags
pour créerWorkQuery
directement (b/199919736) (If48f2, b/199919736) - Ajout de
getForegroundInfo
àWorker
. (Ic1ead) - Dans
RxWorker
pour RxJava 2 et RxJava 3,setForeground
renvoie désormaisCompletable
, qui peut être utilisé à la place desetForegroundInfoAsync
qui renvoieListenableFuture
- Dans
RxWorker
pour RxJava 2 et RxJava 3,getForegroundInfo
renvoieSingle
, qui peut être utilisé à la place degetForegroundInfoAsync
qui renvoieListenableFuture
(b/203851459). - Les contraintes peuvent désormais être créées directement, sans utiliser
Constraints.Builder
, ce qui est pratique pour les utilisateurs de Kotlin (Idc390, b/137568653). - Ajout de la possibilité de vérifier si
WorkManager
a été initialisé. Ajout d'une APIgetConfiguration()
pour les développeurs de bibliothèques afin d'obtenir la configuration avec laquelleWorkManager
a été initialisé. (I6eff3, b/212300336)
Correction de bugs
- Correction d'un problème lié au planificateur agressif qui empêchait les workers de s'exécuter immédiatement en cas de charge élevée. (I9686b, b/248111307)
- Ajout de
@RequiresPermission
aux API nécessitant l'autorisationPOST_NOTIFICATIONS
sur le SDK 33 et versions ultérieures (Ie542e, b/238790278). - Les annulations dans le
CoroutineScope
sont propagées auListenableFuture
lorsque vous utilisezsuspendCancellableCoroutine
.
Version 2.8.0-rc01
7 décembre 2022
Publication d'androidx.work:work-*:2.8.0-rc01
. Liste des commits de la version 2.8.0-rc01
Nouvelles fonctionnalités
- Aucune nouvelle fonctionnalité dans cette version. Il s'agit principalement d'un saut de version.
Version 2.8.0-beta02
9 novembre 2022
Publication d'androidx.work:work-*:2.8.0-beta02
. Liste des commits de la version 2.8.0-beta02
Correction de bugs
- Correction de la méthode
equals
dansWorkInfo
, qui auparavant ne prenait pas en compte les informations de la nouvelle génération. (4977cc)
Version 2.8.0-beta01
5 octobre 2022
Publication d'androidx.work:work-*:2.8.0-beta01
. Liste des commits de la version 2.8.0-beta01
Correction de bugs
- Correction d'un problème lié au planificateur agressif qui empêchait les workers de s'exécuter immédiatement en cas de charge élevée. (I9686b, b/248111307)
Version 2.8.0-alpha04
7 septembre 2022
Publication d'androidx.work:work-*:2.8.0-alpha04
. Liste des commits de la version 2.8.0-alpha04
Modifications apportées à l'API
WorkerInfo.getGeneration()
etWorkerParameters.getGeneration()
ont été ajoutés afin de renvoyer la génération d'un nœud de calcul. Un worker comporte plusieurs générations s'il a été mis à jour viaWorkManager.updateWork
ouWorkManager.enqueueUniquePeriodicWork
à l'aide deExistingPeriodicWorkPolicy.UPDATE
. Notez que si le nœud de calcul est en cours d'exécution, il est possible que cette méthode renvoie une génération plus récente que celle du nœud de calcul en cours d'exécution si une mise à jour a été effectuée lors de son exécution. (I665c5, b/219446409) (I128a9, b/219446409)- Ajout de
InitializationExceptionHandler
, un gestionnaire d'exceptions permettant de déterminer si des problèmes se sont produits lors de l'initialisation deWorkManager
. (I061de)
Version 2.8.0-alpha03
10 août 2022
Publication d'androidx.work:work-*:2.8.0-alpha03
. Liste des commits de la version 2.8.0-alpha03
Nouvelles fonctionnalités
- ll est maintenant possible de mettre à jour
WorkRequests
de manière non intrusive, afin de préserver le temps de mise en file d'attente d'origine, le chaînage, etc. Pour en savoir plus, consultezWorkManager.updateWork
etExistingPeriodicWorkPolicy.UPDATE
.
Modifications apportées à l'API
- Ajout de
WorkManager.updateWork
pour mettre à jour le travail tout en préservant son temps de mise en file d'attente et son chaînage d'origine. (I9a248, b/219446409) ExistingPeriodicWorkPolicy.UPDATE
a été ajouté. Cette règle permet de mettre à jour une tâche périodique à partir de son nom. Elle est semblable auREPLACE
existant, mais elle est moins intrusive : elle n'annule pas un nœud de calcul s'il est en cours d'exécution et préserve le temps de mise en file d'attente. Le délai initial et la période sont calculés à partir du temps de mise en file d'attente d'origine et non à partir du temps de mise à jour.REPLACE
est maintenant obsolète, pour éviter toute confusion entreREPLACE
etUPDATE
, dont les noms sont très similaires. Si vous souhaitez conserver la sémantique précédente deREPLACE
, vous pouvez utiliser la nouvelleCANCEL_AND_REENQUEUE
, qui est identique àREPLACE
. (I985ed, b/219446409)- Ajout de la possibilité d'intercepter les exceptions de planification en définissant un
SchedulingExceptionHandler
. (I033eb) - Les outils d'aide intégrés pour
OneTimeWorkRequest
etPeriodicWorkRequest
ont été transférés deandroidx.work:work-runtime-ktx
versandroidx.work:work-runtime
(I0010f, b/209145335).
Correction de bugs
- Ajout de
@RequiresPermission
aux API nécessitant l'autorisation POST_NOTIFICATIONS sur le SDK 33 ou versions ultérieures. (Ie542e, b/238790278)
Version 2.8.0-alpha02
6 avril 2022
Publication d'androidx.work:work-*:2.8.0-alpha02
. Liste des commits de la version 2.8.0-alpha02
Modifications apportées à l'API
- Les contraintes peuvent désormais être créées directement sans utiliser le constructeur, ce qui est pratique pour les utilisateurs de Kotlin. (Idc390, b/137568653)
- Ajout de la possibilité de vérifier si
WorkManager
a été initialisé. Ajout d'une APIgetConfiguration()
pour les développeurs de bibliothèques afin d'obtenir la configuration avec laquelleWorkManager
a été initialisé. (I6eff3, b/212300336)
Version 2.8.0-alpha01
12 janvier 2022
Publication d'androidx.work:work-*:2.8.0-alpha01
. Liste des commits de la version 2.8.0-alpha01
Modifications apportées à l'API
- Ajout des méthodes d'assistance
WorkQuery.fromStates
,WorkQuery.fromUniqueWorkNames
etWorkQuery.fromTags
pour créer directement WorkQuery. (If48f2, b/199919736) - Ajout de méthodes BuildCompat expérimentales pour les futurs SDK. (Iafd82, b/207528937)
- Ajout de
getForegroundInfo
àWorker
. (Ic1ead) - Ajout de méthodes d'assistance
WorkQuery.fromIds
permettant de créer des requêtes WorkQuery directement à partir d'identifiants. (Ie5bdf, b/199919736) - RxWorker dispose désormais de
setForeground
, qui renvoieCompletable
et qui peut être utilisé à la place desetForegroundInfoAsync
qui renvoieListenableFuture
. (I85156) getForegroundInfo
RxWorker pour RxJava 2 renvoieSingle
qui peut être utilisé à la place degetForegroundInfoAsync
qui renvoieListenableFuture
. (I21c91, b/203851459)- RxWorker pour RxJava 3 dispose désormais de
getForegroundInfo
, qui renvoieSingle
et peut être utilisé à la place degetForegroundInfoAsync
qui renvoieListenableFuture
. (I1ca8a) - RxWorker dispose désormais de
setForeground
, qui renvoieCompletable
et qui peut être utilisé à la place desetForegroundInfoAsync
qui renvoieListenableFuture
. (I992a3, b/203851459)
Correction de bugs
- Les annulations dans le
CoroutineScope
sont propagées auListenableFuture
lorsque vous utilisezsuspendCancellableCoroutine
. (I77e63)
Version 2.7
Version 2.7.1
17 novembre 2021
Publication d'androidx.work:work-*:2.7.1
. Liste des commits de la version 2.7.1
Correction de bugs
- Les annulations dans le
CoroutineScope
sont propagées auListenableFuture
lorsque vous utilisezsuspendCancellableCoroutine
. (I77e63) - Une exception est levée dès que les demandes de travail retardées sont marquées comme accélérées. bef1762
Version 2.7.0
13 octobre 2021
Publication d'androidx.work:work-*:2.7.0
. Liste des commits de la version 2.7.0
Modifications importantes depuis la version 2.6.0
WorkManager introduit une nouvelle API
WorkRequest.Builder.setExpedited(...)
pour aider à résoudre les restrictions des services de premier plan dans Android 12.À l'aide de
setExpedited(...)
, WorkManager délègue les tâches accélérées dans JobScheduler à partir d'Android 12, et fournissant une rétrocompatibilité avec les versions précédentes d'Android en les déléguant à un service de premier plan.
Version 2.7.0-rc01
29 septembre 2021
Publication d'androidx.work:work-*:2.7.0-rc01
. Liste des commits de la version 2.7.0-rc01
Cette version est identique à la version androidx.work:work-*:2.7.0-beta01
.
Version 2.7.0-beta01
1er septembre 2021
Publication d'androidx.work:work-*:2.7.0-beta01
. Liste des commits de la version 2.7.0-beta01
Nouvelles fonctionnalités
- Réduction des conflits entre processus multiples lors de l'initialisation de WorkManager.
Modifications apportées à l'API
- Suppression des API
@ExperimentalExpeditedWork
, puisque les API de plate-forme sous-jacentes pour Android 12 (S) sont stables. (aosp/1792806)
Correction de bugs
- Amélioration du message d'erreur pour les workers accélérés qui n'implémentent pas
getForegroundInfoAsync()
. (aosp/1809376)
Version 2.7.0-alpha05
21 juillet 2021
Publication d'androidx.work:work-*:2.7.0-alpha05
. Liste des commits de la version 2.7.0-alpha05
Cette version contient également des corrections de bugs de la version de 2.6.0-beta02
de WorkManager.
Version 2.7.0-alpha04
2 juin 2021
Publication d'androidx.work:work-*:2.7.0-alpha04
.
Cette version contient également les modifications apportées à la version 2.6.0-beta01.
Modifications apportées à l'API
ListenableWorker.setForegroundAsync()
n'est plus obsolète.- Nous vous recommandons d'utiliser l'API
WorkRequest.Builder.setExpedited(...)
dans la mesure du possible. Pour mieux gérer les cas où l'application n'est pas soumise à des restrictions des services de premier plan, les développeurs peuvent utiliser l'APIListenableWorker.setForegroundAsync()
. - Si
ListenableWorker.setForegroundAsync()
est appelé, l'application est soumise à des restrictions des services de premier plan, ce qui génère l'exception ForegroundServiceStartNotAllowedException.
Correction de bugs
- Lorsque des tâches sont accélérées, elles ne le sont plus. Elles deviennent des tâches standards.
Version 2.7.0-alpha03
21 avril 2021
Publication d'androidx.work:work-*:2.7.0-alpha03
. Liste des commits de la version 2.7.0-alpha03
Nouvelles fonctionnalités
À partir de la version
2.6.0-alpha02
de WorkManager : ajout de la prise en charge de workers exécutables dans n'importe quel processus. (Iaf200)À partir de la version
2.6.0-alpha02
de WorkManager : ajout d'uneRemoteCoroutineWorker
, qui est une implémentation deRemoteListenableWorker
qui peut être liée à un processus à distance. (I30578)
Modifications apportées à l'API
- À partir de la version
2.6.0-alpha02
de WorkManager : ajout de la prise en charge de la contrainte de réseauTEMPORARILY_UNMETERED
. (I08d5e) - À partir de la version
2.6.0-alpha02
de WorkManager : compatibilité des workers multiprocessus avecsetProgressAsync()
. (Ib6d08) - Dans la version
2.6.0-alpha02
de WorkManager :WorkManagerInitializer
a été rendu afin que d'autresandroidx.startup.Initializer
puissent l'utiliser en tant que dépendances. (I5ab11)
Version 2.7.0-alpha02
10 mars 2021
Publication d'androidx.work:work-*:2.7.0-alpha02
. Liste des commits de la version 2.7.0-alpha02
Correction de bugs
PendingIntent
est maintenant modifiable, pour corriger un plantage lorsque vous ciblez Android 12. (b/180884673)
Version 2.7.0-alpha01
18 février 2021
Publication d'androidx.work:work-*:2.7.0-alpha01
. Liste des commits de la version 2.7.0-alpha01
Nouvelles fonctionnalités
WorkManager introduit une nouvelle API
WorkRequest.Builder.setExpedited(...)
pour prendre en compte les restrictions des services de premier plan dans Android 12.Les applications ne peuvent plus lancer de service de premier plan lorsqu'elles sont en arrière-plan. Par conséquent, pour mieux gérer les tâches à exécution longue qui étaient auparavant liées au cycle de vie d'un service de premier plan, les applications peuvent marquer les
WorkRequest
comme prioritaires.Cette API remplace les API
setForegroundAsync(...)
/setForeground(...)
, qui sont désormais obsolètes.À l'aide de
setExpedited(...)
, WorkManager délègue les tâches accélérées dansJobScheduler
à partir d'Android 12, et fournissant une rétrocompatibilité avec les versions précédentes d'Android en les déléguant à un service de premier plan.
Modifications apportées à l'API
- Ajout de la compatibilité avec la
WorkRequest
accélérée.
Version 2.6.0
Version 2.6.0
1er septembre 2021
Publication d'androidx.work:work-*:2.6.0
. Liste des commits de la version 2.6.0
Modifications importantes depuis la version 2.5.0
WorkManager utilise désormais
androidx.startup
pour initialiser WorkManager. Si vous utilisieztools:node="remove"
surContentProvider
pour initialiser WorkManager par le passé, vous devez maintenant procéder comme suit.<provider android:name="androidx.startup.InitializationProvider" android:authorities=\"${applicationId}.androidx-startup" android:exported="false" tools:node=\"merge"> <!-- If you are using androidx.startup to initialize other components --> <meta-data android:name="androidx.work.WorkManagerInitializer" android:value="androidx.startup" tools:node="remove" /> </provider>
<!-- If you want to disable android.startup completely. --> <provider android:name="androidx.startup.InitializationProvider" android:authorities="${applicationId}.androidx-startup" tools:node="remove" />
Ajout de la prise en charge des nœuds de calcul qui peuvent être exécutés dans n'importe quel processus. (Iaf200)
Ajout d'un
RemoteCoroutineWorker
qui est une implémentation de RemoteListenableWorker qui peut être liée à un processus à distance. (I30578)
Version 2.6.0-rc01
4 août 2021
Publication d'androidx.work:work-*:2.6.0-rc01
. Liste des commits de la version 2.6.0-rc01
Cette version est identique à la version androidx.work:work-*:2.6.0-beta02
.
Version 2.6.0-beta02
21 juillet 2021
Publication d'androidx.work:work-*:2.6.0-beta02
. Liste des commits de la version 2.6.0-beta02
Correction de bugs
RemoteWorkManager
se débloque désormais correctement deRemoteWorkManagerService
, ce qui permet àRemoteWorkManagerService
de le nettoyer correctement. aosp/1730694RemoteListenableWorker
se débloque désormais correctement deRemoteWorkerService
, ce qui permet àRemoteWorkerService
de le nettoyer correctement. aosp/1743817ForceStopRunnable
s'exécute désormais uniquement dans le processus principal de l'application. Cette optimisation permet d'éviter les conflits de ressources pour les applications qui utilisent plusieurs processus. aosp/1749180, aosp/1761729
Version 2.6.0-beta01
2 juin 2021
Publication d'androidx.work:work-*:2.6.0-beta01
. Liste des commits de la version 2.6.0-beta01
Cette version contient des améliorations mineures de la documentation. La version est en grande partie identique à 2.6.0-alpha02.
Version 2.6.0-alpha02
21 avril 2021
Publication d'androidx.work:work-*:2.6.0-alpha02
. Liste des commits de la version 2.6.0-alpha02
Nouvelles fonctionnalités
Ajout de la prise en charge des nœuds de calcul qui peuvent être exécutés dans n'importe quel processus. (Iaf200)
Ajout d'un
RemoteCoroutineWorker
qui est une implémentation deRemoteListenableWorker
qui peut être liée à un processus à distance. (I30578)
Modifications apportées à l'API
- Ajout de la compatibilité avec la contrainte réseau
TEMPORARILY_UNMETERED
. (I08d5e) - Compatibilité du nœud de calcul multiprocessus avec
setProgressAsync()
. (Ib6d08) WorkManagerInitializer
a été rendu public afin que d'autresandroidx.startup.Initializer
puissent l'utiliser en tant que dépendances. (I5ab11)
Version 2.6.0-alpha01
24 mars 2021
Publication d'androidx.work:work-*:2.6.0-alpha01
. Liste des commits de la version 2.6.0-alpha01.
Nouvelles fonctionnalités
WorkManager
utilise désormaisandroidx.startup
pour initialiser WorkManager. Auparavant, cette initialisation était réalisée parandroidx.work.impl.WorkManagerInitializer
. (aosp/1608813)Si vous utilisiez
tools:node="remove"
surContentProvider
pour initialiser le cycle de vie des processus par le passé, vous devez maintenant procéder comme suit.<provider android:name="androidx.startup.InitializationProvider" android:authorities=\"${applicationId}.androidx-startup" android:exported="false" tools:node=\"merge"> <!-- If you are using androidx.startup to initialize other components --> <meta-data android:name="androidx.work.impl.WorkManagerInitializer" android:value="androidx.startup" tools:node="remove" /> </provider>
(ou)
<!-- If you want to disable android.startup completely. --> <provider android:name="androidx.startup.InitializationProvider" android:authorities="${applicationId}.androidx-startup" tools:node="remove"> </provider>
Modifications apportées à l'API
- Ajout d'une API
Result.getOutputData()
qui renvoie leoutputData
de ListenableWorker. (Ie51e3)
Correction de bugs
- Ajout d'une solution de contournement à un bug OEM qui provoque le renvoi d'une
SecurityException
lors de l'utilisation de l'APIAlarmManager
. (aosp/1587518)
Version 2.5.0
Version 2.5.0
27 janvier 2021
Publication d'androidx.work:work-*:2.5.0
. Liste des commits de la version 2.5.0
Principales modifications depuis la version 2.4.0
- Nouvel artefact
:work:work-multiprocess
pour les applications qui utilisent plusieurs processus. Cela permet d'améliorer les performances en unifiant la planification des demandes de travail en un seul processus.- Pour utiliser
work-multiprocess
, définissez une dépendance sur :implementation "androidx.work:work-multiprocess:2.5.0"
- Désignez un processus principal à l'aide de Configuration.Builder.setDefaultProcessName(String).
- Lorsque vous utilisez
work-multiprocess
, vous devez également utiliser RemoteWorkManager pour gérer vosWorkRequest
. RemoteWorkManager contacte toujours le processus désigné. Le planificateur en cours de traitement s'exécute également dans le processus désigné.
- Pour utiliser
- Parfois,
ActivityManager
ne parvient pas à instancierJobService
pour démarrer une tâche. Cela entraîne la suppression silencieuse de la tâche sous-jacente en raison d'un bug de la plate-forme.WorkManager
s'assure désormais qu'il existe des tâches de remplacement pour chaqueWorkRequest
lorsque le rapprochement des tâches initialise uneApplication
. La fiabilité d'exécution des tâches est considérablement améliorée. (b/172475041, aosp/1489577) WorkManager
limite la croissance de la base de données en réduisant la durée de la mémoire tampon dont le suivi desWorkRequest
est effectué une fois laWorkRequest
terminée. Cette durée était autrefois de7
jours. Elle a été réduite à1
jours + la durée de keepResultsForAtLeast. (aosp/1419708)TestListenableWorkerBuilder
est désormais compatible avec la classe étendue avecListenableWorker
pour faciliter les tests. (aosp/1443299, b/169787349)- WorkManager Inspector est désormais disponible lorsque vous utilisez Android Studio Arctic Fox.
Version 2.5.0-rc01
13 janvier 2021
Publication d'androidx.work:work-*:2.5.0-rc01
. Liste des commits de la version 2.5.0-rc01.
Correction de bugs
- Correction d'un bug qui empêchait
getWorkInfosLiveData
d'être invalidé correctement après la mise à jour des entités lors de l'utilisation de l'API basée surWorkQuery
. (aosp/1540566, b/173769028) - Correction d'un bug qui empêchait les transactions de base de données d'être marquées comme réussies dans certains rares cas. Cela engendrait des problèmes sur certains appareils Motorola. (aosp/1535368, b/175944460)
- Correction d'un bug dans lequel les
NoSuchElementException
étaient ignorées lorsque vous essayiez de les dissocier d'un processus mort. (aosp/1530589) - Amélioration de
ConstraintTrackingWorker
pour n'arrêter unListenableWorker
que s'il n'a pas déjà été arrêté. (aosp/1496844, b/172946965) - Mise à jour des bibliothèques androidx.work pour cibler Java 8. (Ibd2f2)
Version 2.5.0-beta02
2 décembre 2020
Publication d'androidx.work:work-*:2.5.0-beta02
. Liste des commits de la version 2.5.0-beta02
Correction de bugs
- Correction du bug suivant : dans
androidx.work:work-multiprocess
, WorkManager bloquait par inadvertance le thread appelant lors de la liaison au processus désigné. (aosp/1475538) - Correction d'un bug qui empêchait de rapprocher correctement les
PeriodicWorkRequest
. (b/172475041, aosp/1489577) - Ajout d'une solution provisoire pour un bug de plate-forme qui se produisait à l'arrêt du service de premier plan lors de l'utilisation des API
setForeground*
. (b/170924044, aosp/1489901)
Version 2.5.0-beta01
28 octobre 2020
Publication d'androidx.work:work-*:2.5.0-beta01
. Liste des commits de la version 2.5.0-beta01
Nouvelles fonctionnalités
WorkManager
limite automatiquement le nombre deWorkRequest
que le planificateur en cours de traitement peut récupérer. Les requêtes sont toujours exécutées dans l'ordre FIFO. (aosp/1455228)WorkManager
tente de récupérer lorsque le datastore de l'application est dans un état incorrect. (aosp/1463103)
Correction de bugs
- Lorsque les
ListenableWorker
sont interrompus, marquez-les immédiatement commeENQUEUED
afin de pouvoir les reprogrammer par la suite. (aosp/1455618, b/170273988)
Version 2.5.0-alpha03
14 octobre 2020
Publication d'androidx.work:work-*:2.5.0-alpha03
. Liste des commits de la version 2.5.0-alpha03
Modifications apportées à l'API
TestListenableWorkerBuilder
etTestWorkerBuilder
n'utilisent pas de types bruts. (I883ad, b/169787349)
Correction de bugs
- Utilisation de
ApplicationInfo
pour déterminer le nom du processus d'application par défaut. (b/168716641, aosp/1429950) - Correction des règles de visibilité pour
RemoteWorkManager
etRemoteWorkContinuation
. Ces API ne sont plus marquées comme@Restricted
. (aosp/1432091) - Correction des règles ProGuard pour
:work:work-multiprocess
. (aosp/1432091) - Amélioration des cycles de vie des notifications pour les tâches de longue durée associées à un service de premier plan. (b/168502234, aosp/1431331)
Version 2.5.0-alpha02
16 septembre 2020
Publication d'androidx.work:work-*:2.5.0-alpha02
. Liste des commits de la version 2.5.0-alpha02
Nouvelles fonctionnalités
- Ajout d'une API à WorkQuery pour pouvoir utiliser des
id
afin d'interroger desWorkInfo
. (aosp/1412372, b/157335295) - Amélioration de la compatibilité de WorkManager avec les applications qui utilisent plusieurs processus avec un nouvel artefact (
androidx.work:work-multiprocess:*
). Ce nouvel artefact permet de résoudre certains problèmes rencontrés par les applications volumineuses, y compris :- WorkManager doit généralement être initialisé dans chaque processus d'application. Cela n'est pas très pratique, car les conflits entre processus multiples augmentent, ce qui entraîne d'autres problèmes. WorkManager dispose désormais de nouvelles API qui peuvent être utilisées pour désigner un processus d'application principal à l'aide de
Configuration#setDefaultProcessName(processName)
.processName
est un nom de processus complet qui ressemble àpackageName:processName
(p. ex.com.example:remote
). - Ensemble de nouvelles API :
RemoteWorkManager
etRemoteWorkContinuation
pour les requêtes de travailenqueue
,cancel
etquery
. Ces API ne comprennent pas de variantesLiveData
pour éviter les conflits entre processus multiples. Tous les appels àenqueue
,cancel
etquery
sont transférés vers un processus d'applicationprimary
à l'aide d'AIDL et renvoient unListenableFuture
courant. (aosp/1392657, aosp/1411210, aosp/1412215, aosp/1417713)
- WorkManager doit généralement être initialisé dans chaque processus d'application. Cela n'est pas très pratique, car les conflits entre processus multiples augmentent, ce qui entraîne d'autres problèmes. WorkManager dispose désormais de nouvelles API qui peuvent être utilisées pour désigner un processus d'application principal à l'aide de
Modifications apportées à l'API
- WorkManager élimine de manière plus agressive les
WorkRequest
terminés qui n'ont pas de dépendances incomplètes. La durée de la mémoire tampon est passée de7
jours à1
jour. (aosp/1419708)
Correction de bugs
- WorkManager rapproche désormais les tâches de manière proactive, pour que les tâches
WorkRequest
etJobScheduler
se synchronisent lors de l'initialisation deWorkManager
. (aosp/1412794, b/166292069)
Version 2.5.0-alpha01
19 août 2020
Publication d'androidx.work:work-*:2.5.0-alpha01
. Liste des commits de la version 2.5.0-alpha01
Nouvelles fonctionnalités
- Modifications des API internes qui nous permettent de fournir de meilleurs outils avec
WorkManager
à l'avenir. Des informations supplémentaires seront bientôt disponibles.
Correction de bugs
- Gestion des
SecurityException
lorsque vous suivez l'état du réseau sur certains appareils. (aosp/1396969)
Contribution externe
- Correction de la documentation pour
ArrayCreatingInputMerger
par Zac Sweers (github/43).
Version 2.4.0
Version 2.4.0
22 juillet 2020
Publication d'androidx.work:work-*:2.4.0
. Liste des commits de la version 2.4.0
Principales modifications depuis la version 2.3.0
- Le planificateur dans le processus de
WorkManager
est maintenant plus performant. Auparavant, la fonctionScheduler
en cours de traitement ne prenait en compte que l'exécution d'une tâche qui n'était pas retardée et dont les contraintes étaient remplies. Le planificateur en cours de traitement suit lesWorkRequest
qui pourraient être exécutées à l'avenir, y compris les PeriodicWorkRequests. LeScheduler
en cours de traitement n'applique pas de limites de planification (mais reste limité à la taille deExecutor
utilisée par WorkManager). Cela signifie que l'application peut désormais exécuter beaucoup plus de WorkRequests lorsqu'elle est exécutée au premier plan. Pour gérer l'exécution des tâches différées au premier plan,WorkManager
introduit également un nouveauRunnableScheduler
configurable. (aosp/1185778) - WorkManager est désormais compatible avec RxJava 3. Pour utiliser RxJava 3, vous devez inclure la dépendance suivante :
implementation "androidx.work:work-rxjava3:2.4.0"
. (aosp/1277904) - Ajout de la possibilité d'interroger des
WorkInfo
à l'aide d'uneWorkQuery
. Cela est utile lorsque les développeurs souhaitent interroger desWorkInfo
en combinant plusieurs attributs. Pour en savoir plus, consultezWorkQuery.Builder.fromStates(...)
,WorkQuery.Builder. fromTags(...)
ouWorkQuery.Builder.fromUniqueWorkNames(...)
. (aosp/1253230, b/143847546) Ajout de la possibilité de demander des informations de diagnostic à
WorkManager
en utilisant :adb shell am broadcast -a "androidx.work.diagnostics.REQUEST_DIAGNOSTICS" -p "<your_app_package_name>"
Vous y trouverez de nombreuses informations utiles, y compris :
- WorkRequests traitées au cours des dernières 24 heures.
- WorkRequests en cours d'exécution.
- WorkRequests planifiées. (aosp/1235501)
Ajout de
ExistingWorkPolicy.APPEND_OR_REPLACE
, semblable àAPPEND
, mais qui remplace une chaîne qui a été annulée ou qui n'a pas respecté les conditions préalables. (b/134613984, aosp/1199640)Possibilité d'ajouter un
RunnableScheduler
personnalisé pour suivre les WorkRequests qui doivent être exécutées ultérieurement. Utilisé par le planificateur en cours de traitement. (aosp/1203944)Ajout de la prise en charge de l'ajout dynamique de fabriques auxquelles déléguer lorsque vous utilisez une
DelegatingWorkerFactory
. (b/156289105, aosp/1309745)Alignement plus précis du suivi des contraintes
BATTERY_NOT_LOW
avec la plate-forme. (aosp/1312583)Le planificateur en cours de traitement utilise désormais des API plus efficaces pour déterminer le nom du processus. Cette approche est utile pour les applications qui utilisent plusieurs processus. (aosp/1324732)
Voici les nouvelles règles d'analyse lint qui s'appliquent :
- Utilisation du
foregroundServiceType
approprié lorsque vous utilisez les APIsetForegroundAsync()
. (b/147873061, aosp/1215915) - Définition des ID JobScheduler que WorkManager doit utiliser lors de l'utilisation directe des API JobService. aosp/1223567
- Ajout d'une règle d'analyse lint qui garantit que
ListenableWorker
les implémentations sont désormaispublic
lorsque vous utilisez la valeur par défautWorkerFactory
. (aosp/1291262)
- Utilisation du
Les appels à
setForegroundAsync()
qui ne sont pas terminés avant la fin d'unListenableWorker
seront désormais signalés via unIllegalStateException
sur leListenableFuture
renvoyé. (aosp/1262743)Nous avons corrigé un bug qui empêchait l'arrêt de
ForegroundService
après l'interruption d'unWorker
au premier plan. (b/155579898, aosp/1302153)Correction du bug suivant :
WorkManager
tentait d'exécuter plusieurs instances d'unWorker
lié à un service de premier plan. (b/156310133, aosp/1309853)
Version 2.4.0-rc01
24 juin 2020
Publication d'androidx.work:work-*:2.4.0-rc01
. Liste des commits de la version 2.4.0-rc01
Correction de bugs
- Le planificateur en cours de traitement utilise désormais des API plus efficaces pour déterminer le nom du processus. Cette approche est utile pour les applications qui utilisent plusieurs processus. (aosp/1324732)
Version 2.4.0-beta01
20 mai 2020
Publication d'androidx.work:work-gcm:2.4.0-beta01
, androidx.work:work-runtime:2.4.0-beta01
, androidx.work:work-runtime-ktx:2.4.0-beta01
, androidx.work:work-rxjava2:2.4.0-beta01
et androidx.work:work-testing:2.4.0-beta01
. Liste des commits de la version 2.4.0-beta01
Correction de bugs
- Nous avons corrigé un bug qui empêchait l'arrêt de
ForegroundService
après l'interruption d'unWorker
au premier plan. (b/155579898, aosp/1302153) - Correction du bug suivant :
WorkManager
tentait d'exécuter plusieurs instances d'unWorker
lié à un service de premier plan. (b/156310133, aosp/1309853) - Ajout de la prise en charge de l'ajout dynamique de fabriques auxquelles déléguer lorsque vous utilisez une
DelegatingWorkerFactory
. (b/156289105, aosp/1309745) - Alignement plus précis du suivi des contraintes
BATTERY_NOT_LOW
avec la plate-forme. (aosp/1312583)
Version 2.4.0-alpha03
29 avril 2020
Publication d'androidx.work:work-*:2.4.0-alpha03
. Liste des commits de la version 2.4.0-alpha03
Nouvelles fonctionnalités
- WorkManager est désormais compatible avec RxJava 3. Pour utiliser RxJava 3, vous devez inclure la dépendance suivante :
implementation "androidx.work:work-rxjava3:2.4.0-alpha03"
. (aosp/1277904) - Ajout d'une règle d'analyse lint qui garantit que
ListenableWorker
les implémentations sont désormaispublic
lorsque vous utilisez la valeur par défautWorkerFactory
. (aosp/1291262)
Modifications apportées à l'API
- Appeler
setProgressAsync()
après la fin de l'exécution d'unListenableWorker
indique désormais uneException
viaListenableFuture
. (aosp/1285494) WorkQuery.Builder
est désormais marqué commefinal
. (aosp/1275037)- Les méthodes de fabrique de
WorkQuery.Builder
(withStates
,withTags
etwithUniqueWorkNames
) ont été renommées respectivementfromStates
,fromTags
etfromUniqueWorkNames
. (aosp/1280287)
Correction de bugs
- Les
SecurityException
lors du suivi de l'état du réseau d'un appareil sont ignorées. (b/153246136, aosp/1280813)
Version 2.4.0-alpha02
1er avril 2020
Publication d'androidx.work:work-*:2.4.0-alpha02
. Liste des commits de la version 2.4.0-alpha02.
Nouvelles fonctionnalités
- Ajout d'une règle d'analyse lint qui avertit lorsque les
WorkRequest
nécessitent à la foisConstraints.setRequiresCharging(...)
etConstraints.setRequiresDeviceIdle(...)
. Certains appareils ne sont jamais en charge tout en restant inactifs. Ces requêtes s'exécutent donc moins souvent que prévu. (aosp/1253840)
Modifications apportées à l'API
Ajout de la possibilité d'interroger des
WorkInfo
à l'aide d'uneWorkQuery
. Cela est utile lorsque les développeurs souhaitent interroger desWorkInfo
en combinant plusieurs attributs. Pour en savoir plus, consultezWorkQuery.Builder withStates(...)
,WorkQuery.Builder withTags(...)
ouWorkQuery.Builder withUniqueWorkNames(...)
. (aosp/1253230, b/143847546)Les appels à
setForegroundAsync()
qui ne sont pas terminés avant la fin d'unListenableWorker
seront désormais signalés via unIllegalStateException
sur leListenableFuture
renvoyé. (aosp/1262743)
Correction de bugs
- Correction de la règle d'analyse lint qui recherche les durées d'intervalle non valides pour les
PeriodicWorkRequest
. (aosp/1254846, b/152606442)
Version 2.4.0-alpha01
4 mars 2020
Publication d'androidx.work:work-*:2.4.0-alpha01
. Liste des commits de la version 2.4.0-alpha01
Nouvelles fonctionnalités
Le planificateur dans le processus de
WorkManager
est maintenant plus performant. Auparavant, le planificateur en cours de traitement ne prenait en compte que l'exécution d'une tâche qui n'était pas retardée et dont les contraintes étaient remplies. Le planificateur en cours de traitement suit lesWorkRequest
qui pourraient être exécutées à l'avenir, y compris lesPeriodicWorkRequest
. De plus, le planificateur en cours de traitement n'applique pas les limites de planification (mais reste limité à la taille deExecutor
utilisée par WorkManager). Cela signifie que l'application peut désormais exécuter beaucoup plus deWorkRequest
lorsqu'elle est exécutée au premier plan. (aosp/1185778)Ajout de la possibilité de demander des informations de diagnostic à WorkManager à l'aide de
adb shell am broadcast -a "androidx.work.diagnostics.REQUEST_DIAGNOSTICS" -p "<your_app_package_name>"
. Vous y trouverez de nombreuses informations utiles, y compris :- WorkRequests traitées au cours des dernières 24 heures.
- WorkRequests en cours d'exécution.
- WorkRequests planifiées. (aosp/1235501)
Voici les nouvelles règles d'analyse lint qui s'appliquent :
- Utilisation du
foregroundServiceType
approprié lorsque vous utilisez les APIsetForegroundAsync()
. (b/147873061, aosp/1215915) - Spécification des ID
JobScheduler
queWorkManager
doit utiliser lors de l'utilisation directe des APIJobService
. (aosp/1223567)
- Utilisation du
Modifications apportées à l'API
Ajout de
ExistingWorkPolicy.APPEND_OR_REPLACE
, semblable àAPPEND
, mais qui remplace une chaîne qui a été annulée ou qui n'a pas respecté les conditions préalables. (b/134613984, aosp/1199640)Possibilité d'ajouter un
RunnableScheduler
personnalisé pour suivre lesWorkRequest
qui doivent être exécutées ultérieurement. Utilisé par le planificateur en cours de traitement. (aosp/1203944)
Correction de bugs
setProgress()
a été retiré deRxWorker
, car il renvoyait précédemment unSingle<Void>
, qui est un type impossible. Ajout d'une nouvelle APIsetCompletableProgress()
qui renvoie unCompletable
. Ajout de nouvelles règles Lint pour faciliter la migration vers les nouvelles API. (b/150080946, aosp/1242665)
Version 2.3.4
Version 2.3.4
18 mars 2020
Publication d'androidx.work:work-*:2.3.4
. Liste des commits de la version 2.3.4
Correction de bugs
- Correction d'un bug qui entraînait l'exécution de plusieurs instances d'une
Worker
de longue durée après un délai de 10 minutes. (aosp/1247484, b/150553353) - Correction de l'erreur lint
IssueRegistry
de WorkManager. Merci à @ZacSweers de Slack pour sa contribution. (aosp/1217923)
Version 2.3.3
Version 2.3.3
4 mars 2020
Publication d'androidx.work:work-*:2.3.3
. Liste des commits de la version 2.3.3
Correction de bugs
- Correction d'un bug qui empêchait la replanification d'un
Worker
si celui-ci était interrompu (b/150325687, aosp/1246571)
Version 2.3.2
Version 2.3.2
19 février 2020
Publication d'androidx.work:work-*:2.3.2
. Liste des commits de la version 2.3.2
Correction de bugs
- Correction d'un problème qui empêchait WorkManager de dépasser la limite de 100 tâches dans JobScheduler dans de rares cas. (aosp/1226859, b/149092520)
- Correction d'une condition de concurrence dans ConstraintControllers. (aosp/1220100)
- Amélioration de la gestion du cycle de vie du service de premier plan pour les nœuds de calcul de longue durée. (aosp/1226295)
- Amélioration de la gestion de l'annulation des notifications pour les nœuds de calcul de longue durée en cas d'annulation d'un nœud de calcul. (aosp/1228346)
Version 2.3.1
Version 2.3.1
5 février 2020
Publication d'androidx.work:work-*:2.3.1
. Liste des commits de la version 2.3.1
Correction de bugs
- Amélioration de la gestion du cycle de vie des
Notification
pour lesWorker
de longue durée qui s'exécutent lorsqu'unService
de premier plan est actif. (aosp/1218539, b/147249312) WorkManager
dépend désormais deandroidx.sqlite:sqlite-framework:2.1.0
(version stable). (aosp/1217729)- Ajout de règles d'analyse lint pour garantir la définition d'une
foregroundServiceType
dans leAndroidManifest.xml
lors de l'utilisation deforegroundServiceType
dansForegroundInfo
. (aosp/1214207, b/147873061)
Version 2.3.0
Version 2.3.0
22 janvier 2020
Publication d'androidx.work:work-*:2.3.0
sans aucune modification par rapport à la version 2.3.0-rc01
. Liste des commits de la version 2.3.0
Changements importants depuis la version 2.2.0
- Prise en charge des tâches de longue durée ou importantes via
ListenableWorker#setForegroundAsync()
. - Prise en charge de la progression des nœuds de calcul via
ListenableWorker#setProgressAsync()
. - WorkManager intègre désormais des règles d'analyse lint supplémentaires dans la bibliothèque, ce qui permet de détecter plus rapidement les bugs.
Version 2.3.0-rc01
8 janvier 2020
Publication d'androidx.work:work-*:2.3.0-rc01
. Liste des commits de la version 2.3.0-rc01.
Cette version est identique à la version 2.3.0-beta02
.
Correction de bugs
- L'artefact
work-testing
définit désormais une dépendanceapi
surwork-runtime-ktx
. (aosp/1194410)
Version 2.3.0-beta02
18 décembre 2019
Publication d'androidx.work:work-*:2.3.0-beta02
. Liste des commits de la version 2.3.0-beta02.
Nouvelles fonctionnalités
- Ajout d'un message d'erreur amélioré pour les exceptions SQLite non récupérables. (aosp/1185777)
- Ajout d'une règle d'analyse lint qui garantit que le fournisseur de contenu
androidx.work.impl.WorkManagerInitializer
est supprimé deAndroidManifest.xml
lors de l'utilisation de l'initialisation à la demande. (aosp/1167007) - Ajout d'un avertissement d'analyse lint lorsque
enqueue()
est utilisé pourPeriodicWorkRequest
au lieu deenqueueUniquePeriodicWork()
. (aosp/1166032)
Modifications apportées à l'API
ForegroundInfo
exige désormais que vous indiquiez lenotificationId
à utiliser avecListenableWorker.setForegroundAsync()
. Il s'agit d'une modification destructive. Cela vous permet d'exécuter plusieursWorker
de longue durée en parallèle.WorkManager
gère également mieux les durées de vie desNotification
fournis. (b/145473554, aosp/1181208, asop/1181216, asop/1183577)
Correction de bugs
- Correction d'un bug dans l'implémentation d'AlarmManager qui entraînait un nettoyage incorrect des alarmes. (aosp/1156444)
- Correction d'un bug qui provoquait la création d'une chaîne
WorkContinuation
incorrecte en cas de liste vide deWorkRequest
. (b/142835274, aosp/1157051)
Modifications de la dépendance
- WorkManager utilise désormais la version 2.2.2 de Room.
Version 2.3.0-beta01
20 novembre 2019
Publication d'androidx.work:work-*:2.3.0-beta01
. Liste des commits de la version 2.3.0-beta01
Nouvelles fonctionnalités
- Ajout d'une règle d'analyse lint qui empêche les erreurs de développement causées par une implémentation incorrecte de
androidx.work.Configuration.Provider
lors de l'initialisation à la demande. aosp/1164559
Version 2.3.0-alpha03
23 octobre 2019
Publication d'androidx.work:work-*:2.3.0-alpha03
. Liste des commits de la version 2.3.0-alpha03
Nouvelles fonctionnalités
- Ajout de l'API
WorkManager.createCancelPendingIntent()
, qui permet d'annuler facilement desWorkRequest
sans avoir à enregistrer un autre composant dans leAndroidManifest.xml
. En particulier, cette API facilite l'annulation deWorkRequest
depuisNotification
. Elle devrait être associée aux nouvelles API au premier plan dans la version 2.3.0. - WorkManager dépend désormais de la version stable de
androidx.room:*:2.2.0
.
Modifications apportées à l'API
- Changement de nom :
ForegroundInfo.getNotificationType()
devientForegroundInfo.getForegroundServiceType()
, pour être cohérent avec les API de la plate-forme sous-jacente. (b/142729893, aosp/1143316)
Correction de bugs
- Correction d'un bug causé par un appel inutile à
setTransactionSuccessful()
en dehors d'une transaction. Cela se produit pour les migrations rares. (b/142580433, aosp/1141737)
Version 2.3.0-alpha02
9 octobre 2019
Publication d'androidx.work:work-*:2.3.0-alpha02
. Liste des commits de la version 2.3.0-alpha02
Nouvelles fonctionnalités
- WorkManager permet désormais d'exécuter des tâches de longue durée ou importantes qui doivent être maintenues actives par l'OS. Pour en savoir plus, consultez
ListenableWorker#setForegroundAsync()
(ouCoroutineWorker#setForeground()
pour Kotlin). (aosp/1133636)
Modifications apportées à l'API
- Changement de nom : l'API
containsKey
dansData
devienthasKeyWithValueOfType
. La méthode d'extension correspondante dans la bibliothèquektx
a également été renommée. (b/141916545)
Correction de bugs
- Les planifications de WorkManager fonctionnent de façon équitable lorsque le nombre de
WorkRequest
en file d'attente approche des limites de planification. (aosp/1105766) - WorkManager n'appelle
ListenableWorker#onStopped()
que si le travail n'est pas déjà terminé. (b/140055777) - WorkManager supprime désormais les informations de progression lorsqu'un nœud de calcul est interrompu ou atteint son état final. (aosp/1114572)
Data
dispose désormais d'une représentationtoString()
bien plus utile. (b/140945323)Data
propose désormais une méthodeequals()
plus efficace. Il accepte égalementdeepEquals
pour les typesArray
. (b/140922528)- WorkManager stocke désormais sa base de données interne et ses fichiers de préférences dans un répertoire sans sauvegarde. (b/114808216)
Version 2.3.0-alpha01
22 août 2019
Publication d'androidx.work:work-*:2.3.September 5, 20190-alpha01
. Les commits inclus dans cette version sont disponibles sur cette page.
Nouvelles fonctionnalités
- Les
ListenableWorker
peuvent désormais définir leur progression à l'aide de l'APIsetProgressAsync()
. Ajout d'une APIsetProgress
suspend
correspondante dansCoroutineWorker
et d'unesetProgress
dansRxWorker
qui renvoie unSingle<Void>
. Avec ces nouvelles API, les workers peuvent transmettre des informations de progression viaWorkInfo
, qui dispose d'une APIgetProgress
correspondante. (b/79481554) Data
dispose d'une APIcontainsKey()
qui permet de vérifier que les données d'entrée pourWorker
comportent des clés avec le type attendu. (b/117136838)Data
peut désormais être sérialisé à l'aide deData.toByteArray()
etData.fromByteArray()
. Notez qu'il n'existe aucune garantie quant à la gestion des versions avecData
. Vous ne devez donc pas les conserver ni les utiliser pour la communication inter-processus entre les applications. Ils ne peuvent être utilisés qu'entre plusieurs processus de la même application.- Ajout de la possibilité de définir un
InputMergerFactory
viaConfiguration.setInputMergerFactory
. (b/133273159)
Modifications apportées à l'API
- WorkManager génère une instance de
IllegalStateException
siWorkerFactory
renvoie une instance deListenableWorker
précédemment appelée. (b/139554406) - Modifications apportées à la documentation sur l'annulation de
ListenableFuture
et au rappelonStopped()
dansListenableWorker
. (b/138413671)
Correction de bugs
- Le planificateur en cours de traitement ignore maintenant les
WorkRequest
avec la contrainteidle
. Ces requêtes ne sont désormais récupérées parJobScheduler
que lorsque l'appareil estidle
. (aosp/1089779) TestScheduler
utilise désormais correctement leExecutor
spécifié pour son exécuteur de tâches interne lors des tests. (aosp/1090749)
Version 2.2.0
Version 2.2.0
15 août 2019
Publication d'androidx.work:work-*:2.2.0
. Les commits inclus dans cette version sont disponibles sur cette page.
Cette version est identique à la version androidx.work:work-*:2.2.0-rc01
.
Changements importants apportés à la version 2.1.0 dans la version 2.2.0
androidx.work:work-gcm:2.2.0
est un nouvel artefact Maven qui permet d'utiliser GCMNetworkManager en tant que planificateur lorsque les services Google Play sont disponibles pour les niveaux d'API 22 ou inférieurs. Cette dépendance facultative permet d'améliorer la fiabilité du traitement en arrière-plan et les performances sur les anciennes versions de l'API. Si votre application fait appel aux services Google Play, ajoutez cette dépendance à votre fichier Gradle pour obtenir automatiquement la prise en charge de GCMNetworkManager. Si les Services Play ne sont pas disponibles, WorkManager continuera à utiliser AlarmManager sur les anciens appareils.
Version 2.2.0-rc01
30 juillet 2019
Publication d'androidx.work:work-*:2.2.0-rc01
. Les commits inclus dans cette version sont disponibles sur cette page.
Correction de bugs
- Correction d'un bug dans l'implémentation d'AlarmManager qui entraînait l'arrêt prématuré du service et entraînait une
RejectedExecutionException
dans de rares cas. (aosp/1092374) (b/138238197). - Ajout d'une solution provisoire pour un
NullPointerException
si vous utilisez les APIJobScheduler
sur certains appareils. (aosp/1091020) (b/138364061), (b/138441699)
Version 2.2.0-beta02
19 juillet 2019
Publication d'androidx.work:work-*:2.2.0-beta02
. Les commits inclus dans cette version sont disponibles sur cette page.
Correction de bugs
- Suppression de la dépendance JaCoCo non intentionnelle introduite dans
2.2.0-beta01
.
Version 2.2.0-beta01
17 juillet 2019
Publication d'androidx.work:work-*:2.2.0-beta01
. Les commits inclus dans cette version sont disponibles sur cette page.
Nouvelles fonctionnalités
androidx.work:work-gcm:2.2.0-beta01
est un nouvel artefact Maven qui permet d'utiliser GCMNetworkManager en tant que planificateur lorsque les services Google Play sont disponibles pour les niveaux d'API 22 ou inférieurs. Cette dépendance facultative permet d'améliorer la fiabilité du traitement en arrière-plan et les performances sur les anciennes versions de l'API. Si votre application fait appel aux services Google Play, ajoutez cette dépendance à votre fichier Gradle pour obtenir automatiquement la prise en charge de GCMNetworkManager. Si les Services Play ne sont pas disponibles, WorkManager continuera à utiliser AlarmManager sur les anciens appareils.
Correction de bugs
- Correction de
IllegalArgumentException
lors du suivi de l'état du réseau sur les tablettes Nvidia Shield K1. (aosp/1010188)
Version 2.1.0
Version 2.1.0
11 juillet 2019
Publication d'androidx.work:work-*:2.1.0
. Cette version est identique à la version androidx.work:work-*:2.1.0-rc01
.
Changements importants depuis la version 2.0.1
work-runtime-ktx
nécessite désormais Java 8. Si vous rencontrez des problèmes, vous pouvez ajouter ce qui suit à votrebuild.gradle
:kotlinOptions { jvmTarget = "1.8" }
- Ajout d'une initialisation à la demande pour WorkManager, qui ne crée WorkManager que lorsqu'il est référencé. b/127497100 Pour configurer l'initialisation à la demande pour votre projet :
- Désactivez l'initialiseur automatique.
- Implémentez
Configuration.Provider
sur votre objetApplication
personnalisé. - Remplacez toutes les références à
WorkManager.getInstance()
parWorkManager.getInstance(Context)
. Dans le cadre de changement, nous avons suppriméWorkManager.getInstance()
. Il est toujours plus sûr d'appeler le nouveau remplacementWorkManager.getInstance(Context)
, même si vous n'effectuez pas d'initialisation à la demande.
- Les
PeriodicWorkRequest
sont désormais compatibles avec les délais initiaux. Vous pouvez utiliser la méthodesetInitialDelay
surPeriodicWorkRequest.Builder
pour définir un délai initial. b/111404867 - Ajout de la possibilité de déléguer à un ou plusieurs
WorkerFactory
enregistrés à l'aide deDelegatingWorkerFactory
. b/131435993 - Ajout de la possibilité de personnaliser le
Executor
utilisé par WorkManager pour toutes les opérations de tenue de registres internes viaConfiguration.Builder.setTaskExecutor
. - Ajout de la possibilité de créer des classes
Worker
etListenableWorker
pouvant être testées par unité en utilisantTestWorkerBuilder
etTestListenableWorkerBuilder
dans l'artefactwork-testing
.- Notez que
work-testing
utilise désormais Kotlin en tant que dépendance et inclut plusieurs extensions Kotlin par défaut.
- Notez que
- Ajout à
WorkInfo
du nombre de tentatives d'exécution. b/127290461 - Les types
Data
peuvent désormais stocker et récupérer des octets et des tableaux d'octets. Cela ne modifie PAS la taille maximale des objetsData
. - WorkManager dépend désormais de
Room 2.1.0
, ce qui devrait résoudre certains problèmes liés à la base de données.
Version 2.1.0-rc01
27 juin 2019
Publication d'androidx.work:work-*:2.1.0-rc01
. Les commits inclus dans cette version sont disponibles sur cette page.
Correction de bugs
- Correction d'un bug qui provoquait le plantage de l'application lors de l'exécution de tâches avec
JobScheduler
alors qu'une sauvegarde était en cours. b/135858602.
Version 2.1.0-beta02
20 juin 2019
Publication d'androidx.work:work-*:2.1.0-beta02
. Les commits inclus dans cette version sont disponibles sur cette page.
Correction de bugs
TestListenableWorkerBuilder
utilise désormais leWorkerFactory
approprié lors de la création d'instances deListenableWorker
. b/135275844- Correction d'un bug qui entraînait des dérives dans les fenêtres d'exécution pour
WorkRequest
en raison de l'arrêt du processus. b/135272196
Version 2.1.0-beta01
13 juin 2019
Publication d'androidx.work:work-*:2.1.0-beta01
. Les commits inclus dans cette version sont disponibles sur cette page.
Correction de bugs
- WorkManager dépend désormais de
Room 2.1.0
, ce qui devrait résoudre certains problèmes liés à la base de données. - Suppression de certaines entrées/sorties de disque de démarrage sur le thread principal.
- Blocage potentiel du suivi des contraintes. b/134361006
- Annulation des tâches non valides attribuées par erreur à WorkManager. b/134058261
- Ajout d'appels défensifs aux API JobScheduler pour les appareils défaillants.
Version 2.1.0-alpha03
5 juin 2019
Publication d'androidx.work:*:2.1.0-alpha03
.
Correction de bugs
- Amélioration de la documentation sur les
PeriodicWorkRequest
. WorkManagerTestInitHelper
utilise désormais l'exécuteur approprié pour les tests.- Correction des problèmes liés à SQLite lors du traitement de transactions importantes sur certains appareils. (b/130182503)
- Les dépendances de WorkManager sont désormais plus précises. (b/133169148).
- Résolution des bugs spécifiques au fabricant OEM dans l'implémentation de
JobScheduler
lors de la planification des tâches à l'aide de WorkManager. - Améliorations apportées au planificateur basé sur AlarmManager concernant les durées de service qui entraînaient auparavant quelques rares plantages. (b/133313734)
Version 2.1.0-alpha02
16 mai 2019
Publication de la version 2.1.0-alpha02 de WorkManager. Cette version contient plusieurs nouvelles API.
Modifications apportées à l'API
Les
PeriodicWorkRequest
sont désormais compatibles avec les délais initiaux. Vous pouvez utiliser la méthodesetInitialDelay
surPeriodicWorkRequest.Builder
pour définir un délai initial. b/111404867Ajout de la possibilité de déléguer à un ou plusieurs
WorkerFactory
enregistrés à l'aide deDelegatingWorkerFactory
. b/131435993Ajout de la possibilité de personnaliser le
Executor
utilisé par WorkManager pour toutes les opérations de tenue de registres internes viaConfiguration.Builder.setTaskExecutor
.Amélioration de la documentation concernant
WorkRequest.keepResultsForAtLeast
(b/130638001), l'initialisation à la demande etPeriodicWorkRequest.Builder
(b/131711394).
Version 2.1.0-alpha01
24 avril 2019
Publication de la version 2.1.0-alpha01 de WorkManager. Cette version contient plusieurs nouvelles API. Notez qu'à partir de cette version, de nouvelles fonctionnalités ne seront pas rétroportées dans la version 1.x. Nous vous recommandons de passer à la version 2.x.
Modifications apportées à l'API
- Ajout d'une initialisation à la demande pour WorkManager, qui ne crée WorkManager que lorsqu'il est référencé. b/127497100 Pour configurer l'initialisation à la demande pour votre projet :
- Désactivez l'initialiseur automatique.
- Implémentez
Configuration.Provider
sur votre objetApplication
personnalisé. - Remplacez toutes les références à
WorkManager.getInstance()
parWorkManager.getInstance(Context)
. Dans le cadre de changement, nous avons suppriméWorkManager.getInstance()
. Il est toujours plus sûr d'appeler le nouveau remplacementWorkManager.getInstance(Context)
, même si vous n'effectuez pas d'initialisation à la demande.
- Ajout de la possibilité de créer des classes
Worker
etListenableWorker
pouvant être testées par unité en utilisantTestWorkerBuilder
etTestListenableWorkerBuilder
dans l'artefactwork-testing
.- Notez que
work-testing
utilise désormais Kotlin en tant que dépendance et inclut plusieurs extensions Kotlin par défaut.
- Notez que
- Ajout à
WorkInfo
du nombre de tentatives d'exécution. b/127290461 - Les types
Data
peuvent désormais stocker et récupérer des octets et des tableaux d'octets. Cela ne modifie PAS la taille maximale des objetsData
. - Abandon de
CoroutineWorker.coroutineContext
. Ce champ a été marqué commeCoroutineDispatcher
par erreur. Vous ne devriez plus en avoir besoin, car vous pouvez accéder vous-même au paramètre coroutineContext souhaité dans le corps de la fonction de suspension. RxWorker.createWork()
etRxWorker.getBackgroundScheduler()
sont désormais annotés avec les types@NonNull
renvoyés.
Version 2.0.1
Version 2.0.1
9 avril 2019
La version 2.0.1 de WorkManager est disponible. Cette version est identique à 2.0.1-rc01.
Version 2.0.1-rc01
3 avril 2019
Publication de la version 2.0.1-rc01 de WorkManager. Cette version contient des corrections de bugs. Pour les utilisateurs de l'ancienne version 1.x, certaines de ces modifications apparaissent également dans la version 1.0.1-rc01.
Correction de bugs
- Les tests Robolectric fonctionnent désormais correctement avec WorkManager. b/122553577
- Correction d'un cas particulier dans lequel le suivi des contraintes n'était pas nettoyé pour les APIs pré-JobScheduler. b/129226383
- Correction d'une erreur
StackOverflowError
liée aux longues chaînes de travail. b/129091233 - Mise à jour de la documentation sur les
PeriodicWorkRequest
pour indiquer que l'heure flexible n'est pas compatible avec l'API 23. - Correction de certains liens non fonctionnels dans la documentation Kotlin.
Version 2.0.0
Version 2.0.0
20 mars 2019
Publication de la version 2.0.0 de WorkManager. Cette version est identique à la version 2.0.0-rc01 et correspond à la version AndroidX 1.0.0 stable comportant des dépendances AndroidX. Nous vous recommandons de cibler cette version plutôt que les anciennes versions 1.x. Tous les développements en cours cibleront les versions 2.x, et les versions 1.x ne recevront les corrections de bugs critiques que pendant une durée limitée.
Version 2.0.0-rc01
7 mars 2019
Publication de la version 2.0.0-rc01 de WorkManager. Cette version est identique à la version 1.0.0 stable, mais comporte des dépendances AndroidX. Une fois la version 2.0.0 stable, vous devez inclure cette version. Les anciennes versions 1.x ne recevront que certaines corrections de bugs critiques. Tous les développements en cours cibleront la version 2.x.
Dépendances antérieures à AndroidX
Documents de référence : Java
Groovy
dependencies { def work_version = "1.0.1" // (Java only) implementation "android.arch.work:work-runtime:$work_version" // Kotlin + coroutines implementation "android.arch.work:work-runtime-ktx:$work_version" // optional - RxJava2 support implementation "android.arch.work:work-rxjava2:$work_version" // optional - Test helpers androidTestImplementation "android.arch.work:work-testing:$work_version" }
Kotlin
dependencies { val work_version = "1.0.1" // (Java only) implementation("android.arch.work:work-runtime:$work_version") // Kotlin + coroutines implementation("android.arch.work:work-runtime-ktx:$work_version") // optional - RxJava2 support implementation("android.arch.work:work-rxjava2:$work_version") // optional - Test helpers androidTestImplementation("android.arch.work:work-testing:$work_version") }
Version 1.0.1
Version 1.0.1
9 avril 2019
La version 1.0.1 de WorkManager est disponible. Cette version est identique à 1.0.1-rc01.
Nous encourageons fortement les utilisateurs à effectuer la mise à jour vers WorkManager 2.x, car très peu de mises à jour de la branche 1.x seront désormais effectuées. Aucune nouvelle API ne sera publiée pour la bibliothèque 1.x.
Version 1.0.1-rc01
2 avril 2019
Publication de la version 1.0.1-rc01 de WorkManager. Cette version contient des corrections de bugs.
Correction de bugs
- Les tests Robolectric fonctionnent désormais correctement avec WorkManager. b/122553577
- Correction d'un cas particulier dans lequel le suivi des contraintes n'était pas nettoyé pour les APIs pré-JobScheduler. b/129226383
- Correction d'une erreur
StackOverflowError
liée aux longues chaînes de travail. b/129091233
Version 1.0.0
Version 1.0.0
5 mars 2019
Il s'agit de la version stable 1.0.0 de WorkManager. Cette version de WorkManager est identique à 1.0.0-rc02.
Version 1.0.0-rc02
21 février 2019
Il s'agit de la deuxième version finale pour la version stable de WorkManager 1.0.0. Cette version contient deux corrections de bugs.
Correction de bugs
Les
Worker
sont désormais correctement planifiés après un plantage de l'application. b/124546316Les
Worker
qui renvoient uneException
décochée sont maintenant correctement marqués commeFAILED
et ne plantent plus le processus de l'application.
Version 1.0.0-rc01
14 février 2019
Il s'agit d'une version finale de la version stable de WorkManager 1.0.0. Cette version contient un correctif.
Correction de bugs
- L'implémentation basée sur AlarmManager respecte désormais correctement les fenêtres
flex
pour les PeriodicWorkRequests. b/124274584
Version 1.0.0-beta05
6 février 2019
Cette version contient des corrections de bugs.
Correction de bugs
- Correction d'un problème lié à l'utilisation de
JobScheduler.getPendingJob(...)
sur l'API 23. b/123893059 - Correction d'une
NullPointerException
sur les appareils équipés d'Android 5.1 (niveau d'API 22) ou version antérieure. b/123835104
Version 1.0.0-beta04
4 février 2019
Cette version contient des corrections de bugs.
Correction de bugs
- Amélioration de la planification de PeriodicWork pour l'implémentation basée sur AlarmManager.
- Correction du problème suivant : WorkManager ne parvenait pas à suivre correctement les contraintes lors de l'utilisation de l'implémentation basée sur AlarmManager. b/123379508
- Correction d'un problème qui empêchait WorkManager de relancer la tâche lors de l'arrêt du processus lors de l'utilisation d'AlarmManager. b/123329850
- Correction d'un problème qui provoquait la fuite de wakelocks avec WorkManager lors de l'utilisation d'AlarmManager.
Version 1.0.0-beta03
25 janvier 2019
Cette version contient des corrections de bugs.
Correction de bugs
- Nous avons introduit une régression
1.0.0-beta02
qui entraînait un dysfonctionnement d'une tâche dans certaines situations. b/123211993 - Correction d'un cas où la tâche ne respectait pas correctement l'intervalle entre les tentatives. b/122881597
- Correction d'une
ConcurrentModificationException
sur les appareils équipés d'Android 5.1 (API ou version antérieure). Ceci fait suite au correctif de la version1.0.0-beta02
. b/121345393 - Ajout de
exported=false
à certains composants de notre fichier manifeste ne comportant pas cette annotation. - Ajout d'informations sur l'interaction de WorkManager avec l'OS dans la documentation au niveau du package.
Version 1.0.0-beta02
15 janvier 2019
Cette version contient des corrections de bugs.
Correction de bugs
- Correction d'un cas extrême où le travail périodique pouvait s'exécuter plusieurs fois par intervalle sur des appareils équipés d'Android 6.0 (niveau d'API 23). b/121998363
- Correction d'une
ConcurrentModificationException
sur les appareils équipés d'Android 5.1 (niveau d'API 22) ou version antérieure. b/121345393 - Correction de l'exécution erronée d'un travail qui se produisait lorsque les contraintes n'étaient pas respectées sur les appareils équipés d'Android 5.1 (niveau d'API 22) ou version antérieure. b/122578012
- Optimisation de la gestion de l'achèvement du travail pour accélérer le processus dans certains cas extrêmes. b/122358129
- Modification permettant de répondre aux conditions de concurrence potentielles dans plusieurs instances de
LiveData
utilisées par WorkManager. - Adoption de la dépendance
1.1.1
deRoom
au lieu de1.1.1-rc01
. Ces versions sont identiques. b/122578011
Version 1.0.0-beta01
19 décembre 2018
Cette version ne contient aucune modification de l'API. À l'avenir, WorkManager devrait conserver l'API stable jusqu'à la prochaine version, sauf en cas de problème critique. Cette version contient des corrections de bugs.
Correction de bugs
- Les enfants précédemment annulés des travaux parents terminés ne seront plus exécutés. b/120811767
- Classes de journalisation correctement initialisées (principalement exposées lors des tests).
Version 1.0.0-alpha13
12 décembre 2018
Cette version contient une modification mineure de l'API qui sera utile pour certains utilisateurs de Kotlin.
Modifications apportées à l'API
androidx.work.Result
a été déplacé vers une classe interne deListenableWorker
. Cela permet d'éviter les conflits de refactorisation avec la classeResult
de niveau supérieur de Kotlin. Il s'agit d'une modification destructive de l'API. b/120564418
Modifications destructives de l'API
androidx.work.Result
a été déplacé vers une classe interne deListenableWorker
.
Version 1.0.0-alpha12
5 décembre 2018
Cette version contient des modifications destructives apportées à l'API. Veuillez consulter la section Modifications destructives de l'API ci-dessous. Cette version sera probablement notre première version bêta. La version alpha12
contient également des mises à jour importantes de la documentation.
Modifications apportées à l'API
- Un nouvel artefact,
work-rxjava2
, introduitRxWorker
. Il s'agit d'unListenableWorker
qui attend uneSingle<Payload>
. - Suppression de la compatibilité avec Firebase JobDispatcher en raison de son abandon imminent. Par conséquent, l'artefact
work-firebase
ne sera plus mis à jour lorsque nous passerons à la version bêta. Nous envisageons d'ajouter une alternative à l'avenir. - Intégration de
Payload
àResult
.Result
est désormais une "classe scellée" avec trois implémentations concrètes, que vous pouvez obtenir viaResult.success()
(ouResult.success(Data)
),Result.failure()
(ouResult.failure(Data)
) etResult.retry()
. VosListenableFuture
génèrent désormais unResult
au lieu d'unePayload
. LesWorker
n'ont pas de méthodes "getter" et "setter" pour lesData
de sortie. Il s'agit d'une modification destructive. - Ajout de
Constraints.Builder.setTriggerContentMaxDelay(long, TimeUnit)
, deConstraints.Builder.setTriggerContentUpdateDelay(long, TimeUnit)
et de variantes pour permettre une meilleure compatibilité avec les URI de contenu à déclenchement lent. b/119919774 - Ajout de la variante
WorkRequest.Builder.setBackoffCriteria(BackoffPolicy, Duration)
. Cette méthode nécessite le niveau d'API 26. - Ajout des méthodes d'extension Kotlin
Operation.await()
etListenableFuture.await()
. - Changement de nom :
Operation.getException()
devientOperation.getThrowable()
. Il s'agit d'une modification destructive. - La classe
ContentUriTriggers
et les méthodes qui y font référence ne sont plus disponibles pour une utilisation publique. Il s'agit d'une modification destructive. - Suppression des autres méthodes de varargs dans
WorkManager
,WorkContinuation
etOneTimeWorkRequest
afin de simplifier l'API. Vous pouvez encapsuler vos varargs existants avecArrays.asList(...)
pour corriger les problèmes de compilation. Nous incluons toujours les versions à argument unique de chaque méthode. Il s'agit d'une modification destructive. - Suppression des variantes
WorkContinuation.combine(OneTimeWorkRequest, *)
. Elles présentaient une API qui prêtait à confusion. Les méthodescombine
existantes sont plus faciles à comprendre. Il s'agit d'une modification destructive.
Correction de bugs
- Les implémentations antérieures à Marshmallow sont désormais plus fiables lors de la récupération de la fin du processus d'une tâche déjà en cours d'exécution.
LiveData
est observé parobserveForever
et suivi par WorkManager. Il s'agit d'un rétroportage d'une correction de la bibliothèque Room. b/74477406Data.Builder.build()
génère désormais une exception si l'objet sérialisé dépasse sa taille maximale. Auparavant, cette opération ne se produisait que sur un thread d'arrière-plan qui empêchait une gestion correcte.- Plus grande distinction entre les travaux arrêtés et annulés.
getWorkInfoById()
renvoieWorkInfo
avec leState
CANCELLED
pendantListenableWorker.onStopped()
. - Traitement des
Result
null
comme des échecs dansListenableWorker
. b/120362353 - Correction potentielle pour les tablettes Shield exécutant le niveau d'API 24, qui génère parfois une
IllegalArgumentException
. b/119484416
Modifications destructives de l'API
- Suppression de la compatibilité avec Firebase JobDispatcher en raison de son abandon imminent. Par conséquent, l'artefact
work-firebase
ne sera plus mis à jour lorsque nous passerons à la version bêta. Nous envisageons d'ajouter une alternative à l'avenir. - Intégration de
Payload
àResult
.Result
est désormais une "classe scellée" avec trois implémentations concrètes, que vous pouvez obtenir viaResult.success()
(ouResult.success(Data)
),Result.failure()
(ouResult.failure(Data)
) etResult.retry()
. VosListenableFuture
génèrent désormais unResult
au lieu d'unePayload
. LesWorker
n'ont pas de méthodes "getter" et "setter" pour lesData
de sortie. - Ajout des méthodes d'extension Kotlin
Operation.await()
etListenableFuture.await()
. - Changement de nom :
Operation.getException()
devientOperation.getThrowable()
. - La classe
ContentUriTriggers
et les méthodes qui y font référence ne sont plus disponibles pour une utilisation publique. - Suppression des autres méthodes de varargs dans
WorkManager
,WorkContinuation
etOneTimeWorkRequest
afin de simplifier l'API. Vous pouvez encapsuler vos varargs existants avecArrays.asList(...)
pour corriger les problèmes de compilation. Nous incluons toujours les versions à argument unique de chaque méthode. - Suppression des variantes
WorkContinuation.combine(OneTimeWorkRequest, *)
. Elles présentaient une API qui prêtait à confusion. Les méthodescombine
existantes sont plus faciles à comprendre.
Version 1.0.0-alpha11
8 novembre 2018
Cette version contient de nombreuses modifications qui permettront d'obtenir une API stable en version beta
.
Cette version comprend des modifications destructives apportées à l'API. Veuillez consulter la section Modifications destructives de l'API ci-dessous.
Modifications apportées à l'API
work-runtime-ktx
introduit un nouveauCoroutineWorker
.WorkStatus
a été renomméWorkInfo
. Toutes les variantes correspondantes de la méthodegetStatus
ont été renommées en variantes correspondantes degetWorkInfo
. Il s'agit d'une modification destructive.ListenableWorker.onStopped()
n'accepte plus l'argument booléen indiquant siWorkRequest
a été annulé.WorkManager
ne fait plus cette distinction. Il s'agit d'une modification destructive.- Le package
androidx.work.test
a été renomméandroidx.work.testing
. Il s'agit d'une modification destructive. - Les méthodes "setter" de
Constraints
ne font plus partie de l'API publique. Il s'agit d'une modification destructive. - Auparavant,
WorkerParameters.getTriggeredContentUris()
etWorkerParameters.getTriggeredContentAuthorities()
renvoyaient des tableaux. Ces méthodes renvoient maintenant des collections. Il s'agit d'une modification destructive. ListenableWorker.onStartWork()
a été renomméListenableWorker.startWork()
. Il s'agit d'une modification destructive.- Le constructeur de
WorkStatus
ne fait plus partie de l'API publique. Il s'agit d'une modification destructive. Configuration.getMaxJobSchedulerID()
etConfiguration.getMinJobSchedulerID()
sont renommésConfiguration.getMinJobSchedulerId()
etConfiguration.getMaxJobSchedulerId()
, respectivement. Il s'agit d'une modification destructive.- Ajout de nombreuses annotations
@NonNull
à l'API publique pour améliorer son ergonomie. - Ajout de l'API
WorkManager.enqueueUniqueWork()
pour placer desOneTimeWorkRequest
uniques en file d'attente sans avoir à créer deWorkContinuation
. - Toutes les variantes des méthodes
enqueue
etcancel
surWorkManager
renvoient désormais un nouveau typeOperation
. Il s'agit d'une modification destructive. - Toutes les variantes de
enqueue
n'acceptent plus les varargs pourWorkRequest
. Il s'agit d'une modification destructive. Utilisez plutôt des collections. Vous pouvez utiliserArrays.asList()
pour modifier le code existant. Nous avons apporté cette modification pour réduire le nombre de méthodes et la surface de l'API. - Désormais, les tentatives de
initialize
WorkManager
répétées plus d'une fois par processus entraîneront uneIllegalStateException
. Il s'agit d'une modification destructive.
Correction de bugs
- Les
WorkRequest.Builder
de l'artefactwork-runtime-ktx
utilisent désormais desListenableWorker
. Corrections b/117666259 - Assurez-vous que la prochaine exécution de
PeriodicWork
se déroule dans le futur. Corrections b/118204399 - Suppression des E/S de disque potentielles lors de l'utilisation de WorkManager au démarrage de l'application. Corrections b/117796731
- Correction d'une condition de concurrence dans
WorkConstraintsTracker
. Corrections android-workmanager/issues/56
Modifications destructives de l'API
WorkStatus
a été renomméWorkInfo
. Toutes les variantes correspondantes de la méthodegetStatus
ont été renommées en variantes correspondantes degetWorkInfo
.ListenableWorker.onStopped()
n'accepte plus l'argument booléen indiquant siWorkRequest
a été annulé.WorkManager
ne fait plus cette distinction.- Le package
androidx.work.test
a été renomméandroidx.work.testing
. - Les méthodes "setter" de
Constraints
ne font plus partie de l'API publique. - Auparavant,
WorkerParameters.getTriggeredContentUris()
etWorkerParameters.getTriggeredContentAuthorities()
renvoyaient des tableaux. Ces méthodes renvoient maintenant des collections. ListenableWorker.onStartWork()
a été renomméListenableWorker.startWork()
.- Le constructeur de
WorkStatus
ne fait plus partie de l'API publique. Configuration.getMaxJobSchedulerID()
etConfiguration.getMinJobSchedulerID()
sont renommésConfiguration.getMinJobSchedulerId()
etConfiguration.getMaxJobSchedulerId()
, respectivement.- Toutes les variantes des méthodes
enqueue
etcancel
surWorkManager
renvoient désormais un nouveau type d'Operation
. - Toutes les variantes de
enqueue
n'acceptent plus les varargs pourWorkRequest
. - Désormais, les tentatives de
initialize
WorkManager
répétées plus d'une fois par processus entraîneront uneIllegalStateException
.
Version 1.0.0-alpha10
11 octobre 2018
Cette version prend en charge le travail asynchrone contrôlé par les développeurs. Cette version comprend des modifications destructives apportées à l'API. Veuillez consulter la section Modifications destructives de l'API ci-dessous.
Nous pensons que WorkManager entre dans les phases finales de sa période alpha. La version bêta devrait être stable au niveau de l'API. Nous vous invitons donc à nous faire part de vos commentaires sur notre Issue Tracker.
Modifications apportées à l'API
- Suppression de toutes les classes et méthodes précédemment
deprecated
, en particulier le constructeurWorker
par défaut. Il s'agit d'une modification destructive de l'API. NonBlockingWorker
a été renomméListenableWorker
, qui est maintenant une classe publique non masquée et prête à l'emploi.ListenableWorker
permet d'accéder à une méthode abstraite,ListenableFuture<Payload> onStartWork()
, qui est appelée sur le thread principal. Il vous appartient de commencer et de traiter le travail de manière asynchrone. Lorsque vous avez terminé, mettez à jour leListenableFuture
de manière appropriée. Les implémentations de référence desListenableFuture
sont fournies dans le packageFutures
de la versionalpha02
(voir la sectionWorkManager
ci-dessous).Worker
étendListenableWorker
et fonctionne comme avant, avec une méthodeResult doWork()
abstraite.- Passage de certaines méthodes et de certains membres de
Worker
àListenableWorker
. - Nous fournirons bientôt des implémentations de référence pour les
ListenableWorker
utilisant des coroutines Kotlin (une fois les versions stables publiées) et RxJava2.
- L'interface
WorkerFactory
et l'implémentation concrèteDefaultWorkerFactory
ont été fusionnées dans une classe abstraite appeléeWorkerFactory
. L'implémentation garantit que le comportement par défaut basé sur la réflexion est appelé en dernier recours pour toutes les instancesWorkerFactory
créées par l'utilisateur. Il s'agit d'une modification destructive. - Suppression de
WorkManager.synchronous()
, deWorkContinuation.synchronous()
et de toutes les méthodes associées. Ajout deListenableFuture<Void>
comme type renvoyé de nombreuses méthodes dans l'API. Il s'agit d'une modification destructive de l'API.- Vous pouvez désormais utiliser
ListenableFuture
pour obtenir et observer de manière synchrone. Par exemple,WorkManager.enqueue()
permet de renvoyervoid
. Il renvoie désormais unListenableFuture<Void>
. Une fois l'opération terminée, vous pouvez appelerListenableFuture.addListener(Runnable, Executor)
ouListenableFuture.get()
pour exécuter le code. - Notez que ces
ListenableFuture
ne vous indiquent pas la réussite ou l'échec de l'opération, mais seulement qu'elle est terminée. Vous devrez toujours associer les méthodes WorkManager pour obtenir ces informations. - Nous ignorons les appels
cancel()
sur ces objets, car ils sont source de confusion et difficiles à justifier (vous annulez l'opération ou son résultat ?). Cela est prévu dans le contratFuture
. - Pour conserver la parité avec les méthodes
getStatus*
synchrones, nous avons fourni des variantesListenableFuture
et renommé les méthodes existantes renvoyantLiveData
afin d'inclure explicitement "LiveData" dans le nom (par exemple,getStatusesByIdLiveData(UUID)
). Il s'agit d'une modification destructive de l'API.
- Vous pouvez désormais utiliser
Correction de bugs
- Correction du problème connu de la version alpha09 concernant les fichiers
androidx-annotations.pro
en double. Vous pouvez supprimer la solution de contournement des notes de version précédentes en supprimantexclude 'META-INF/proguard/androidx-annotations.pro'
de votre fichier Gradle. - Ajout de configurations ProGuard pour conserver le nouveau constructeur
Worker
. b/116296569 - Correction d'une
NullPointerException
potentielle dans une condition de concurrence où le travail étaitREPLACE
. b/116253486 et b/116677275 WorkContinuation.combine()
accepte désormais une ou plusieursWorkContinuation
au lieu de deux ou plus. b/117266752
Modifications destructives de l'API
- Suppression de toutes les classes et méthodes précédemment
deprecated
, en particulier le constructeurWorker
par défaut. - L'interface
WorkerFactory
et l'implémentation concrèteDefaultWorkerFactory
ont été fusionnées dans une classe abstraite appeléeWorkerFactory
. - Suppression de
WorkManager.synchronous()
et deWorkContinuation.synchronous()
. - Les méthodes
WorkManager.getStatus*()
renvoient désormaisListenableFuture
.WorkManager.getStatus*LiveData()
renvoieLiveData
.
Version 1.0.0-alpha09
19 septembre 2018
Problème connu
Si le problème suivant s'affiche : "Plusieurs fichiers ayant le chemin d'accès indépendant 'META-INF/proguard/androidx-annotations.pro' ont été trouvés dans le système d'exploitation", veuillez utiliser la solution de contournement temporaire suivante dans votre fichier Gradle pendant que nous corrigeons le problème dans la version alpha10 :
Groovy
android { packagingOptions { exclude 'META-INF/proguard/androidx-annotations.pro' } }
Kotlin
android { packagingOptions { exclude("META-INF/proguard/androidx-annotations.pro") } }
Correction de bugs
- Ajout d'une autre correction nécessaire pour l'erreur "100 tâches". b/115560696
- Ajout de corrections pour les erreurs de contraintes de clés étrangères en raison des conditions de concurrence. b/114705286
- Délégation des appels
ConstraintTrackingWorker.onStopped(boolean)
auWorker
sous-jacent. b/114125093 - Application d'un délai minimal correct d'intervalle entre les tentatives pour Firebase JobDispatcher. b/113304626
- Amélioration des garanties de threads internes de la bibliothèque.
- Correction de problèmes potentiels d'élimination des doublons de
LiveData
en interne.
Modifications apportées à l'API
- Vous pouvez maintenant créer vos propres instances
Worker
au moment de l'exécution en spécifiant uneWorkerFactory
dans leWorkManager.Configuration
. La fabrique de remplacement estDefaultWorkerFactory
, ce qui correspond au comportement des versions précédentes de WorkManager.- Les constructeurs par défaut pour
Worker
etNonBlockingWorker
sont désormais marqués comme obsolètes. Veuillez utiliser le nouveau constructeur (Worker(Context, WorkerParameters)
) et appelersuper(Context, WorkerParameters)
. Les futures versions de WorkManager supprimeront le constructeur par défaut.
- Les constructeurs par défaut pour
- Nous avons commencé à utiliser le nouvel artefact
ListenableFuture
en interne (sans dépendances Guava). Nous intégrerons "ListenableFutures" à l'API dans les prochaines versions. Cette modification permettra l'affichage final deNonBlockingWorker
. - Ajout de la possibilité de déclencher des travaux programmés dans
TestDriver
viaTestDriver.setInitialDelayMet(UUID)
etTestDriver.setPeriodDelayMet(UUID)
. b/113360060
Modifications destructives
- Les constructeurs
Worker
etNonBlockingWorker
par défaut sont obsolètes. Veuillez migrer vers le nouveau constructeur dès que possible. Les futures versions supprimeront le constructeur par défaut.
Version 1.0.0-alpha08
27 août 2018
Correction de bugs
- Les composants de WorkManager sont explicitement libellés comme étant incompatibles avec le démarrage direct. Ils ne se déclenchent donc pas pendant le démarrage direct. À l'avenir, nous fournirons une version de WorkManager compatible avec le démarrage direct. b/112665532
- Correction d'un problème empêchant l'exécution de nouvelles tentatives. b/112604021
- Correction du problème empêchant l'exécution répétée du travail périodique (lié au problème ci-dessus). b/112859683
- Respect des règles d'intervalle entre les tentatives lorsque le processus de l'application est déjà en cours d'exécution.
- Correction des messages d'exception dans
Data
pour indiquer que la limite correspond à 10 Ko. - Diminution de la valeur maximale de
Configuration.setMaxSchedulerLimit(int)
à 50 pour tenir compte de la latence pendant le traitement deJobScheduler
. b/112817355
Version 1.0.0-alpha07
16 août 2018
Correction de bugs
- Correction d'une potentielle requête SQL avec des limites négatives pouvant renvoyer un nombre illimité de résultats.
- Désormais, un travail dont l'exécution est terminée annule correctement toutes les copies en attente de ce travail dans d'autres planificateurs. Cela a entraîné le dépassement de la limite de tâches de
JobScheduler
. b/111569265 - Correction d'une
ConcurrentModificationException
dansConstraintTracker
. b/112272753 - Remplacement des annotations du type renvoyé de
Data.getBooleanArray(String)
etData.getIntArray(String)
par@Nullable
au lieu de@NonNull
. b/112275229
Modifications apportées à l'API
Worker
étend désormais une nouvelle classe,NonBlockingWorker
. Cela n'affecte pas l'utilisation actuelle. À l'avenir,NonBlockingWorker
deviendra une entité entièrement compatible avec les solutions de threads personnalisés.- Remplacement des annotations du type renvoyé de
Data.getBooleanArray(String)
etData.getIntArray(String)
par@Nullable
au lieu de@NonNull
. b/112275229 - Extensions de Kotlin : abandon de
Map.toWorkData()
et ajout d'unworkDataOf(vararg Pair<String, Any?>)
de niveau supérieur pour plus de cohérence avec les API existantes.
Version 1.0.0-alpha06
1er août 2018
Correction de bugs
- Prévention du verrouillage des bases de données lors de la programmation du travail. b/111801342
- Correction d'un bug empêchant
PeriodicWork
de s'exécuter comme programmé en mode Sommeil. b/111469837 - Correction d'une condition de concurrence lors du suivi des contraintes entraînant le plantage de
WorkManager
. googlecodelabs/android-workmanager/issues/56 - Création de
WorkRequest
uniques lors de l'utilisation deWorkRequest.Builder#build()
. b/111408337 - Activation de l'utilisation de
RescheduleReceiver
uniquement lorsque nécessaire pour lesWorkRequest
. b/111765853
Version 1.0.0-alpha05
24 juillet 2018
Modifications apportées à l'API
WorkManager.getInstance()
est désormais annoté avec@NonNull
au lieu de@Nullable
. En revanche, si le Singleton n'est pas correctement initialisé en cas d'initialisation manuelle, la méthode renvoie uneIllegalStateException
. Il s'agit d'une modification destructive de l'API.- Ajout d'une nouvelle API,
Configuration.Builder.setMinimumLoggingLevel(int)
, qui permet de contrôler le niveau de verbosité de WorkManager. Par défaut, WorkManager enregistreLog.INFO
et les versions ultérieures. - Modification de la signature de
Data.getString()
pour qu'elle ne prenne plus de valeur par défaut (implicitementnull
). Il s'agit d'une modification destructive de l'API. - Marquage de certaines méthodes comme uniquement réservées à une utilisation interne comme
@hide
. Cela inclut le constructeurConstraints
,Data.toByteArray()
etData.fromByteArray(byte[])
. Il s'agit d'une modification destructive de l'API.
Correction de bugs
- WorkManager n'exécute plus le travail dans les cas connus de sauvegarde automatique. Cela pourrait provoquer un plantage. b/110564377
- Correction de la double programmation de
PeriodicWorkRequest
lors de l'utilisation deJobScheduler
. b/110798652 - Correction d'un problème avec les
PeriodicWorkRequest
qui ne s'exécutent pas correctement après l'activation de la fonction Sommeil sur l'appareil. b/111469837 - Correction d'un problème avec les retards initiaux lors de l'utilisation de Firebase JobDispatcher. b/111141023
- Correction de certains problèmes temporels et de conditions de concurrence potentiels.
- Libération correcte de
BroadcastReceiver
devenus inutiles. - Optimisation des performances de la reprogrammation lors du redémarrage des applications après une fermeture forcée.
- Autorisation de l'appel de
TestScheduler.setAllConstraintsMet(UUID)
avant ou après la mise en file d'attente de laWorkRequest
donnée. b/111238024
Modifications destructives
WorkManager.getInstance()
est désormais annoté avec@NonNull
au lieu de@Nullable
.- Modification de la signature de
Data.getString()
pour qu'elle ne prenne plus de valeur par défaut (implicitementnull
). - Marquage de certaines méthodes comme uniquement réservées à une utilisation interne comme
@hide
. Cela inclut le constructeurConstraints
,Data.toByteArray()
etData.fromByteArray(byte[])
.
Version 1.0.0-alpha04
26 juin 2018
Correction de bugs
- Les
PeriodicWorkRequest
sont désormais correctement reprogrammés lorsque vous utilisez l'implémentation basée surAlarmManager
. - Correction d'une erreur ANR potentielle lors de la reprogrammation de tous les nœuds de calcul après un arrêt forcé ou un redémarrage. b/110507716
- Ajout d'annotations de possibilité de valeur nulle à différentes API WorkManager. b/110344065
- Journalisation des exceptions non détectées pendant l'exécution du nœud de calcul. b/109900862
- Autorisation des migrations de bases de données destructives si vous décidez d'effectuer un rollback vers une ancienne version de WorkManager. b/74633270
- Correction d'un problème de migration en cas de création de balises implicites en double. Il s'agit d'un problème très rare qui ne se produit que si vous utilisez vous-même le même format de balise implicite.
Version 1.0.0-alpha03
19 juin 2018
Correction de bugs
Correction d'une condition de concurrence dans l'implémentation basée sur
AlarmManager
. b/80346526Correction des tâches en double lors de l'utilisation de
JobScheduler
après un redémarrage de l'appareil.Les tâches comportant des déclencheurs d'URI de contenu sont maintenant conservées lors des redémarrages. b/80234744
Mises à jour de la documentation. b/109827628, b/109758949, b/80230748
Correction d'un plantage lors de la nouvelle mise en file d'attente d'une
WorkRequest
. b/109572353Correction des avertissements du compilateur Kotlin lors de l'utilisation de la dépendance
work-runtime-ktx
.WorkManager utilise désormais la version
1.1.1-rc1
deRoom
.
Modifications apportées à l'API
- Ajout de
getStatusesSync()
, la version synchrone deWorkContinuation.getStatuses()
. Worker
permet de faire la distinction entre l'annulation déclenchée par l'utilisateur et l'arrêt temporaire demandé par l'OS.Worker.isStopped()
renvoietrue
si un type d'arrêt a été demandé.Worker.isCancelled()
renvoietrue
lorsque le travail a été explicitement annulé. b/79632247- Ajout de la prise en charge de JobParameters#getNetwork() dans le niveau d'API 28. Cela est exposé via
Worker.getNetwork()
. - Ajout de
Configuration.Builder.setMaxSchedulerLimit(int maxSchedulerLimit)
afin que vous puissiez forcer le nombre de tâches pouvant être envoyées àJobScheduler
ouAlarmManager
. Cela permet d'éviter queWorkManager
n'occupe tous les emplacements disponibles deJobScheduler
. - Ajout de
Configuration.setJobSchedulerJobIdRange(int minJobSchedulerId, int maxJobSchedulerId)
, qui permet de définir une plage d'ID de tâchesJobScheduler
queWorkManager
peut utiliser de manière sûre. b/79996760 Worker.getRunAttemptCount()
renvoie le nombre d'exécutions actuel pour unWorker
donné. b/79716516WorkManager.enqueueUniquePeriodicWork(String uniqueWorkName, ExistingPeriodicWorkPolicy existingPeriodicWorkPolicy, PeriodicWorkRequest periodicWork)
vous permet de placer desPeriodicWorkRequest
uniques en file d'attente. b/79600647WorkManager.cancelAllWork()
annule tous lesWorker
. Les bibliothèques qui dépendent deWorkManager
peuvent vérifier quand cette méthode a été appelée pour la dernière fois en utilisantWorkManager.getLastCancelAllTimeMillis()
pour nettoyer davantage l'état interne.- Ajout de
WorkManager.pruneWork()
pour supprimer les tâches terminées de la base de données interne. b/79950952, b/109710758
Nouveaux comportements
- Ajout d'une balise implicite pour tous les
WorkRequest
, qui correspond au nom de classe complet duWorker
. Cela permet de supprimer desWorkRequest
sanstag
ou lorsque l'id
n'est pas disponible. b/109572351
Modifications destructives
- Changement de nom :
Worker.WorkerResult
devientWorker.Result
. Worker.onStopped
comporte désormais un paramètreisCancelled
supplémentaire défini surtrue
lorsque leWorker
a été explicitement annulé.
Version 1.0.0-alpha02
24 mai 2018
Correction de bugs
- Correction d'une
NullPointerException
dansState.isFinished()
. b/79550068 - Correction d'un problème provoquant la reprogrammation de
Worker
dansApplication.onCreate()
. b/79660657 - Correction d'un problème qui entraînait la programmation d'une quantité de travail supérieure à celle autorisée par le système d'exploitation. b/79497378
- Déplacement du nettoyage des "wakelocks" associés à
Worker
vers le thread d'arrière-plan. - L'implémentation de
AlarmManager
est désormais correctement nettoyée une fois le travail en attente terminé. - Correction des requêtes SQL de nettoyage affectant les langues autres que l'anglais. b/80065360
- Ajout de la prise en charge des
float
dansData
. b/79443878 Data.Builder.putAll()
renvoie maintenant une instance deBuilder
. b/79699162- Documentation contenant davantage de Javadoc et de corrections. b/79691663
Modifications apportées à l'API
- Les
Worker
peuvent réagir à un arrêt.Worker.isStopped()
permet de vérifier si unWorker
a été arrêté.Worker.onStopped()
peut être utilisé pour effectuer des opérations de nettoyage légères. - L'API
Worker.getTags()
renvoie unSet
de balises associées auWorker
. - Ajout de surcharges
javax.time.Duration
pour les API qui combinent une durée et desTimeUnit
. Cela est protégé par@RequiresApi(26)
. - Déplacement des extensions
WorkManager
du packageandroidx.work.ktx
vers le packageandroidx.work
. Abandon et suppression des anciennes extensions dans une prochaine version. - Abandon de
Configuration.withExecutor()
. UtilisezConfiguration.setExecutor()
à la place.
Version 1.0.0-alpha01
8 mai 2018
WorkManager simplifie la programmation et l'exécution du travail en arrière-plan garanti et compatible avec les contraintes. Cette version initiale est la version 1.0.0-alpha01
.