Fixed
Status Update
No update yet.
Comments
ra...@google.com
One more detail here.
The body of navigateUp() method of NavController class (1.0.0-rc01) looks like this:
if (mBackStack.size() == 1) {
// If there's only one entry, then we've deep linked into a specific destination
// on another task so we need to find the parent and start our task from there
...
} else {
return popBackStack();
}
If I put a breakpoint on the very first line of that code and invoke this method anyhow, I can see that the size of mBackStack is actually 2 (with both root and child fragments).
So, the code doesn't consider the current case a deeplink case, but as a regular opening of the child destination.
The body of navigateUp() method of NavController class (1.0.0-rc01) looks like this:
if (mBackStack.size() == 1) {
// If there's only one entry, then we've deep linked into a specific destination
// on another task so we need to find the parent and start our task from there
...
} else {
return popBackStack();
}
If I put a breakpoint on the very first line of that code and invoke this method anyhow, I can see that the size of mBackStack is actually 2 (with both root and child fragments).
So, the code doesn't consider the current case a deeplink case, but as a regular opening of the child destination.
ar...@gmail.com
Partially agree, but my case doesn't use nested graphs at all, so my issue is just simpler.
However, the actual problem seems to be the same: the library treats absence of Intent.FLAG_ACTIVITY_NEW_TASK as it is actually set, because all 'start destinations' are still added before the actual deeplink destination (as it is explained in the documentation where the flag is set).
However, the actual problem seems to be the same: the library treats absence of Intent.FLAG_ACTIVITY_NEW_TASK as it is actually set, because all 'start destinations' are still added before the actual deeplink destination (as it is explained in the documentation where the flag is set).
ra...@google.com
This is a regression caused by https://android-review.googlesource.com/833717 where the NavGraph destinations would always be added to the back stack (it isn't both the root and child fragments, but the root graph and the child fragment) to avoid IllegalArgumentExceptions. Unfortunately, that broke the navigateUp() behavior, which is something we'll fix :)
en...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date: Mon Feb 25 15:38:23 2019
Fix navigateUp() logic when on another app's task
When using deep linking on another app's task,
only the final destination is created, ensuring that
hitting the system back button goes back to the
other app. The Up button, via navigateUp(), should
take users to your own task on the parent destination.
Recent changes made it so that we always add the
parent NavGraphs to the back stack, meaning the simple
check of back stack size == 1 does not properly handle
this change in behavior so instead we need to check for
the number of non-NavGraph destinations on the back
stack.
Test: new NavControllerActivityTest
BUG: 126082008
Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88
M navigation/runtime/src/androidTest/AndroidManifest.xml
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/912258
https://goto.google.com/android-sha1/781d0178da33d84f615b409b17975c8ba290401c
Branch: androidx-master-dev
commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date: Mon Feb 25 15:38:23 2019
Fix navigateUp() logic when on another app's task
When using deep linking on another app's task,
only the final destination is created, ensuring that
hitting the system back button goes back to the
other app. The Up button, via navigateUp(), should
take users to your own task on the parent destination.
Recent changes made it so that we always add the
parent NavGraphs to the back stack, meaning the simple
check of back stack size == 1 does not properly handle
this change in behavior so instead we need to check for
the number of non-NavGraph destinations on the back
stack.
Test: new NavControllerActivityTest
BUG: 126082008
Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88
M navigation/runtime/src/androidTest/AndroidManifest.xml
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
ra...@google.com
A fix will be available in Navigation 1.0.0-rc02. Thanks for reporting it and the great sample app!
en...@gmail.com
Thanks, Ian.
ra...@google.com
Can you please turn on verbose logging and send us all the logs ? I am going to try and reproduce this on my end.
You will need to initialize WorkManager with a custom configuration for that.
* Remove the default WorkManager initializer using:
<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove"/>
* Initialize WorkManager in your own content provider or Application#onCreate() with a custom configuration
WorkManager.initialize(
applicationContext,
new Configuration.Builder().setMinimumLoggingLevel(Log.VERBOSE).build());
You will see a lot more WorkManager logs now.
You will need to initialize WorkManager with a custom configuration for that.
* Remove the default WorkManager initializer using:
<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove"/>
* Initialize WorkManager in your own content provider or Application#onCreate() with a custom configuration
WorkManager.initialize(
applicationContext,
new Configuration.Builder().setMinimumLoggingLevel(Log.VERBOSE).build());
You will see a lot more WorkManager logs now.
ra...@google.com
I think I know what is going on. There are 2 competing schedulers that can pick up work. When the in-process scheduler picks up work and the process gets killed there is nothing else that can wake up to reschedule that Worker until the application is launched again.
en...@gmail.com
Thanks for looking into this more.
I've attached the logs I captured when reproducing the problem as follows:
1. Create a brand new Nexus 7 (2012) API 22 emulator to make sure the system does not have any old state that affects behavior, and start it, and let it boot up and rest a bit. Double-check that in Settings -> Storage, it doesn't say "running out of storage". If it does say that, reboot the emulator. That should get rid of the message. If you try to install the app when the device is in its strange "running out of storage state", you will get "stale dex" errors when installing the app. I'm using the x86 emulator on a 2018 MacBook Pro.
2. Start log capturing with this command: adb -s emulator-5554 logcat -T 0 -v threadtime -s '*:V' | tee ~/log-workmanager-repro-verbose-3.txt
3. Start the app, and after ~10 seconds, close it (I've increased sleep to 20 s)
4. Wait for a long enough time to convince yourself of that the Worker will never be scheduled again (I waited for > 10 minutes)
5. Stop logging.
For your convenience, I have inlined the log filtered with: grep -e Repro -e WM- -e Killing.*workmanager ~/log-workmanager-repro-verbose-3.txt
at the end of the mail. For full logs, see attached file.
The last line with 'Killing' is from me swiping away the app in the App Switcher.
Note that the logs have this line:
WM-SystemAlarmService: All commands completed in dispatcher
So it looks like even though SystemAlarmService was used to dispatch the Worker, the bug happened. ("All commands completed in dispatcher" means SystemAlarmService is about to do Service.stopSelf() as you probably know.)
Let me know if I can help you in any other way.
BR Martin
01-30 09:42:31.954 3613 3613 D WM-Schedulers: Created SystemAlarmScheduler
01-30 09:42:31.960 3613 3613 D WM-PackageManagerHelper: androidx.work.impl.background.systemalarm.SystemAlarmService enabled
01-30 09:42:31.970 3613 3632 D WM-ForceStopRunnable: Application was force-stopped, rescheduling.
01-30 09:42:31.993 3613 3613 E Repro : Calling enqueueUniqueWork(1548837751988, ...)
01-30 09:42:32.040 3613 3632 D WM-PackageManagerHelper: androidx.work.impl.background.systemalarm.RescheduleReceiver enabled
01-30 09:42:32.043 3613 3632 D WM-SystemAlarmScheduler: Scheduling work with workSpecId 576d2452-a559-4c85-b217-c954c6905d7e
01-30 09:42:32.046 3613 3632 D WM-Processor: Processor: processing 576d2452-a559-4c85-b217-c954c6905d7e
01-30 09:42:32.054 3613 3613 D WM-SystemAlarmDispatche: Adding command Intent { act=ACTION_SCHEDULE_WORK cmp=com.github.enselic.workmanagerfailedscheduling/androidx.work.impl.background.systemalarm.SystemAlarmService (has extras) } (1)
01-30 09:42:32.055 3613 3632 D WM-SystemAlarmDispatche: Processing command Intent { act=ACTION_SCHEDULE_WORK cmp=com.github.enselic.workmanagerfailedscheduling/androidx.work.impl.background.systemalarm.SystemAlarmService (has extras) }, 1
01-30 09:42:32.055 3613 3632 D WM-SystemAlarmDispatche: Acquiring operation wake lock (ACTION_SCHEDULE_WORK) WakeLock{4e8f358 held=false, refCount=0}
01-30 09:42:32.055 3613 3632 D WM-CommandHandler: Handling schedule work for 576d2452-a559-4c85-b217-c954c6905d7e
01-30 09:42:32.056 3613 3637 E Repro : doWork() called. Now swipe away app in App Switcher. Tags: [com.github.enselic.workmanagerfailedscheduling.LogPrinter, 1548837751988]
01-30 09:42:32.056 3613 3632 W WM-CommandHandler: Skipping scheduling 576d2452-a559-4c85-b217-c954c6905d7e because it is no longer enqueued
01-30 09:42:32.056 3613 3632 D WM-SystemAlarmDispatche: Releasing operation wake lock (ACTION_SCHEDULE_WORK) WakeLock{4e8f358 held=true, refCount=1}
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmDispatche: Checking if commands are complete.
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmDispatche: Removing command Intent { act=ACTION_SCHEDULE_WORK cmp=com.github.enselic.workmanagerfailedscheduling/androidx.work.impl.background.systemalarm.SystemAlarmService (has extras) }
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmDispatche: No more commands & intents.
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmService: All commands completed in dispatcher
01-30 09:42:43.607 1647 2397 I ActivityManager: Killing 3613:com.github.enselic.workmanagerfailedscheduling/u0a58 (adj 9): remove task
I've attached the logs I captured when reproducing the problem as follows:
1. Create a brand new Nexus 7 (2012) API 22 emulator to make sure the system does not have any old state that affects behavior, and start it, and let it boot up and rest a bit. Double-check that in Settings -> Storage, it doesn't say "running out of storage". If it does say that, reboot the emulator. That should get rid of the message. If you try to install the app when the device is in its strange "running out of storage state", you will get "stale dex" errors when installing the app. I'm using the x86 emulator on a 2018 MacBook Pro.
2. Start log capturing with this command: adb -s emulator-5554 logcat -T 0 -v threadtime -s '*:V' | tee ~/log-workmanager-repro-verbose-3.txt
3. Start the app, and after ~10 seconds, close it (I've increased sleep to 20 s)
4. Wait for a long enough time to convince yourself of that the Worker will never be scheduled again (I waited for > 10 minutes)
5. Stop logging.
For your convenience, I have inlined the log filtered with: grep -e Repro -e WM- -e Killing.*workmanager ~/log-workmanager-repro-verbose-3.txt
at the end of the mail. For full logs, see attached file.
The last line with 'Killing' is from me swiping away the app in the App Switcher.
Note that the logs have this line:
WM-SystemAlarmService: All commands completed in dispatcher
So it looks like even though SystemAlarmService was used to dispatch the Worker, the bug happened. ("All commands completed in dispatcher" means SystemAlarmService is about to do Service.stopSelf() as you probably know.)
Let me know if I can help you in any other way.
BR Martin
01-30 09:42:31.954 3613 3613 D WM-Schedulers: Created SystemAlarmScheduler
01-30 09:42:31.960 3613 3613 D WM-PackageManagerHelper: androidx.work.impl.background.systemalarm.SystemAlarmService enabled
01-30 09:42:31.970 3613 3632 D WM-ForceStopRunnable: Application was force-stopped, rescheduling.
01-30 09:42:31.993 3613 3613 E Repro : Calling enqueueUniqueWork(1548837751988, ...)
01-30 09:42:32.040 3613 3632 D WM-PackageManagerHelper: androidx.work.impl.background.systemalarm.RescheduleReceiver enabled
01-30 09:42:32.043 3613 3632 D WM-SystemAlarmScheduler: Scheduling work with workSpecId 576d2452-a559-4c85-b217-c954c6905d7e
01-30 09:42:32.046 3613 3632 D WM-Processor: Processor: processing 576d2452-a559-4c85-b217-c954c6905d7e
01-30 09:42:32.054 3613 3613 D WM-SystemAlarmDispatche: Adding command Intent { act=ACTION_SCHEDULE_WORK cmp=com.github.enselic.workmanagerfailedscheduling/androidx.work.impl.background.systemalarm.SystemAlarmService (has extras) } (1)
01-30 09:42:32.055 3613 3632 D WM-SystemAlarmDispatche: Processing command Intent { act=ACTION_SCHEDULE_WORK cmp=com.github.enselic.workmanagerfailedscheduling/androidx.work.impl.background.systemalarm.SystemAlarmService (has extras) }, 1
01-30 09:42:32.055 3613 3632 D WM-SystemAlarmDispatche: Acquiring operation wake lock (ACTION_SCHEDULE_WORK) WakeLock{4e8f358 held=false, refCount=0}
01-30 09:42:32.055 3613 3632 D WM-CommandHandler: Handling schedule work for 576d2452-a559-4c85-b217-c954c6905d7e
01-30 09:42:32.056 3613 3637 E Repro : doWork() called. Now swipe away app in App Switcher. Tags: [com.github.enselic.workmanagerfailedscheduling.LogPrinter, 1548837751988]
01-30 09:42:32.056 3613 3632 W WM-CommandHandler: Skipping scheduling 576d2452-a559-4c85-b217-c954c6905d7e because it is no longer enqueued
01-30 09:42:32.056 3613 3632 D WM-SystemAlarmDispatche: Releasing operation wake lock (ACTION_SCHEDULE_WORK) WakeLock{4e8f358 held=true, refCount=1}
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmDispatche: Checking if commands are complete.
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmDispatche: Removing command Intent { act=ACTION_SCHEDULE_WORK cmp=com.github.enselic.workmanagerfailedscheduling/androidx.work.impl.background.systemalarm.SystemAlarmService (has extras) }
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmDispatche: No more commands & intents.
01-30 09:42:32.096 3613 3613 D WM-SystemAlarmService: All commands completed in dispatcher
01-30 09:42:43.607 1647 2397 I ActivityManager: Killing 3613:com.github.enselic.workmanagerfailedscheduling/u0a58 (adj 9): remove task
ra...@google.com
Thanks for providing more information.. This is in line with a fix that I am working on. This should be fixed in the next beta.
https://android-review.googlesource.com/c/platform/frameworks/support/+/889837
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit ebb4f87d732f66d01d1a4cf362bb11a815e80b74
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Jan 29 16:16:17 2019
Correctly retry work on process death when using AlarmManager based implementation.
* AlarmManager now schedules a Worker unless the WorkSpec#isFinished() is true.
* When AlarmManager gets worken up by ActivityManager to resume processing, we
correctly execute the Worker after a backoff period.
* We now correctly handle rescheduling in DelayMetCommandHandler. Previously the
only reason why this worked before was the call to Schedulers.schedule() in
WorkerWrapper inside the onWorkFinished() method.
* When delaying execution of Workers in WorkerWrapper we always reschedule givem
SystemJobScheduler does not schedule jobs where JobScheduler is already aware
of the jobId.
* Added a lot more logging in GreedyScheduler, SystemJobScheduler and SystemAlarmScheduler
to make debugging easier.
* Ran a lot of integration tests on API 22, 23 (double scheduling) and 28.
Look athttps://paste.googleplex.com/5709211287683072?raw
for more information. I also ran integration tests that cancel
workers to sanity check.
Fixes:
Test: Added additional test cases in SystemAlarmDispatcherTest.
Change-Id: I1bcff1ebf5f60928a02e3e94e2e6ccaed0de47b1
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
A work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RetryWorker.java
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M work/integration-tests/testapp/src/main/res/values/strings.xml
M work/workmanager/src/androidTest/java/androidx/work/impl/WorkerWrapperTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/WorkerWrapper.java
M work/workmanager/src/main/java/androidx/work/impl/background/greedy/GreedyScheduler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/CommandHandler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobScheduler.java
https://android-review.googlesource.com/889837
https://goto.google.com/android-sha1/ebb4f87d732f66d01d1a4cf362bb11a815e80b74
Branch: androidx-master-dev
commit ebb4f87d732f66d01d1a4cf362bb11a815e80b74
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Jan 29 16:16:17 2019
Correctly retry work on process death when using AlarmManager based implementation.
* AlarmManager now schedules a Worker unless the WorkSpec#isFinished() is true.
* When AlarmManager gets worken up by ActivityManager to resume processing, we
correctly execute the Worker after a backoff period.
* We now correctly handle rescheduling in DelayMetCommandHandler. Previously the
only reason why this worked before was the call to Schedulers.schedule() in
WorkerWrapper inside the onWorkFinished() method.
* When delaying execution of Workers in WorkerWrapper we always reschedule givem
SystemJobScheduler does not schedule jobs where JobScheduler is already aware
of the jobId.
* Added a lot more logging in GreedyScheduler, SystemJobScheduler and SystemAlarmScheduler
to make debugging easier.
* Ran a lot of integration tests on API 22, 23 (double scheduling) and 28.
Look at
for more information. I also ran integration tests that cancel
workers to sanity check.
Fixes:
Test: Added additional test cases in SystemAlarmDispatcherTest.
Change-Id: I1bcff1ebf5f60928a02e3e94e2e6ccaed0de47b1
M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
A work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RetryWorker.java
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M work/integration-tests/testapp/src/main/res/values/strings.xml
M work/workmanager/src/androidTest/java/androidx/work/impl/WorkerWrapperTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/WorkerWrapper.java
M work/workmanager/src/main/java/androidx/work/impl/background/greedy/GreedyScheduler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/CommandHandler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobScheduler.java
Description
Version used: 1.0.0-beta02
Devices/Android versions reproduced on: Pixel/Pie, Pixel2/Pie, Pixel3/Pie, Motorola Moto-G/Lollipop
Steps to reproduce:
Create a OneTimeWorkRequest like below, while it's running, close the app from app drawer. The first assumption that the enqueued task will run in background even when the app is closed is not true (Task is not started again even after an hour). Also the enqueued OneTimeWorkRequest won't start again on next app launch and stays in ENQUEUED state indefinitely.
private void startTestWork() {
Constraints testConstraints = new Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.setRequiresBatteryNotLow(true)
.build();
isMyWorkerRunning(TEST_WORKER_TAG);
OneTimeWorkRequest testOneTimeWorkRequest = new OneTimeWorkRequest
.Builder(TestWorker.class)
.addTag(TEST_WORKER_TAG)
.setInitialDelay(0, TimeUnit.SECONDS)
.setConstraints(testConstraints)
.build();
WorkManager.getInstance().enqueueUniqueWork(TEST_WORKER_TAG, ExistingWorkPolicy.KEEP,
testOneTimeWorkRequest);
}