Fixed
Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
After creating the issue I've noticed that I mixed up a few terms, sorry about that. JobService should be JobScheduler. When referring to jobs in the description, those are classes extending Worker.
la...@gmail.com <la...@gmail.com> #3
We have a large set of users seeing this same issue... I can confirm that it seems to only effect users using Android OS 4.4 - 5.1. We are also using WorkManager 2.0.0
ja...@gmail.com <ja...@gmail.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019
Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.
Fixes: b/129226383
Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
https://android-review.googlesource.com/933140
https://goto.google.com/android-sha1/098c163581a360c32baa6e4c215227f0efd10889
Branch: androidx-master-dev
commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019
Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.
Fixes:
Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #5
Great to see such a quick fix. Do you have any estimate when a new version that includes this change will be released?
ap...@google.com <ap...@google.com> #6
It should be available in the next 2.x.x version.
ja...@gmail.com <ja...@gmail.com> #8
Hi, we have implemented a new big feature using WorkManager and got the same issue. We have been considering third party alternatives because we need to deliver this ASAP. But if you confirm that we will have that version within next few days we can wait for it.
Description
Version used: 1.0.0-rc01
Devices/Android versions reproduced on: 7.0, 9.0 (Emulators)
According to
if a destination is opened with IMPLICIT deeplink and WITHOUT Intent.FLAG_ACTIVITY_NEW_TASK flag, then the destination is opened in the same task. After that if user clicks UP, then the actual parent should be recreated in a separate task, but it doesn't work. The UP button in this case does nothing, as well as manual navigateUp() method call.
I tried to modify the code to check both Toolbar and ActionBar approaches and also tried to create the NavHostFragment via xml and code. In all this cases, the behavior of UP button remained the same.
I attached a simple project that shows this situation. It contains 2 modules:
- app - an app with 2 fragments (root and child). The child fragment's destination supports a deeplink.
- deeplinkstarter - one button app, that starts an implicit deeplink to the child fragment of the 'app'.
I consider this as major defect because the library doesn't behave as it is explicitly said in the documentation.
Please, improve.